快递e栈JavaWeb实战：Servlet+Filter+Session实现取件入库通知查询全链路

简介这份资源是面向JavaWeb初学者与进阶练习者的综合实战项目「快递e栈」以Servlet、Filter、Session与MVC分层为核心串联HTML、CSS、JavaScript、jQuery、Bootstrap、Layui、Ajax、MySQL、Tomcat、JSP、Listener等前后端知识点适合用于课程设计、毕业设计参考或系统性巩固Web开发流程。压缩包共831个文件约17.23MB包含52个Java源文件与109个class文件对应控制层与DAO实现58个HTML页面、38个CSS与72个JS文件支撑前端界面与交互另有36个jar包、11个XML配置及图片、字体等静态素材目录结构完整、便于按模块查阅。目前已有890人学习下载。项目涵盖用户与快递员管理、快递信息增删改查等业务场景读者可从中理解过滤器与监听器的实际用法、Session会话管理及MVC分层组织方式并借助公有云服务器部署思路完成从编码到上线的完整实践是查漏补缺与二次开发的实用参考。1. 快递e栈这类JavaWeb综合项目到底在练什么快递e栈这个题目很多人第一眼会当成“又一个增删改查”。真动手才发现难点不在写一个 Servlet而在于把取件、入库、通知、查询这几条业务线用 Servlet Filter Session 串成一条能跑通、能演示、能答辩的链路。它适合两类人一是要交 JavaWeb 课程设计或毕设初稿的学生二是想用一个小而完整的系统把 MVC 分层、会话管理和过滤器链讲清楚的开发者。这套方案要解决的核心问题很具体——让快递从“到站登记”到“用户取件”的每一步都有明确的责任模块而不是所有逻辑堆在一个 Servlet 里。下面按需求、设计、实现、避坑、验收的顺序展开结构可以直接照着搭。2. 需求与总体设计四条业务线与三层MVC的职责划分先把业务说清楚再谈技术。快递e栈的本质是一个“站点侧管理 用户侧查询”的双端系统站点侧负责入库、上架、通知、出库用户侧负责凭取件码查件和确认取件。需求如果只写“管理快递”后面设计一定散我一般会把它拆成四条业务线每条线对应一组明确的输入输出这样 MVC 分层才有依据。2.1 四条业务线的输入输出定义第一条是入库线站点工作人员录入快递单号、收件人手机号、快递公司、货架号系统生成一条待取件记录并分配取件码。输入是表单字段输出是入库成功后的记录主键和取件码。第二条是通知线入库完成后按手机号触发一次取件通知通知内容包含取件码和站点信息通知方式在课程设计里通常做成“记录通知日志 页面提示”不接真实短信网关避免引入外部依赖。第三条是查询线用户输入手机号或取件码查到自己的待取件列表这条线只读但必须做数据隔离不能让人随便输个手机号就看到别人的件。第四条是出库线用户到站出示取件码工作人员核销记录状态从“待取件”变为“已取件”同时写入取件时间。这四条线决定了系统的边界。入库和出库是写操作必须登录且带角色校验查询是读操作允许匿名但要做手机号与取件码的双因子匹配通知是副作用放在入库成功之后异步或同步触发都行课程设计里同步记录日志更简单可控。把输入输出写清楚之后后面每个模块该放什么、不该放什么就没有争议了。2.2 三层MVC的职责边界分层不是把包名改成 controller、service、dao 就完事关键是每一层只做自己该做的事。表现层Servlet只负责三件事收参数、调服务、选视图转发或重定向。它不写 SQL不拼业务规则也不直接操作 Session 里的业务数据。服务层Service承载业务规则比如“取件码必须六位且当天唯一”“出库前必须校验状态是待取件”这些判断放在这里Servlet 才能保持薄。数据访问层DAO只做一件事把对象和表记录互相转换SQL 写在这一层事务边界也尽量在这一层或服务层统一控制。这里有个容易被忽略的点MVC 里的 Model 不等于实体类。实体类只是数据载体真正的 Model 是“服务层返回给视图的视图模型”比如查询线返回的不只是快递记录还要带上“是否已过期”“可取的件数”这类派生信息。把这些派生字段在服务层算好JSP 里就只做展示不写判断逻辑。职责边界一旦定死后面加功能就是加一个服务方法加一个 Servlet 映射而不是到处改。2.3 技术选型与目录结构技术栈按题目给的关键词来Servlet 做控制器Filter 做横切Session 做会话JSP 做视图JDBC 做持久化。不引入 Spring 不是能力问题而是课程设计要展示“请求怎么进来、会话怎么维持、过滤器怎么拦截”这些底层机制框架会把这些藏起来。目录结构我一般这样组织src/main/java com.example.express controller/ # 各业务线 Servlet service/ # 业务规则 dao/ # JDBC 访问 model/ # 实体与视图模型 filter/ # 编码、登录、权限过滤器 util/ # 连接池、取件码生成、日期工具 src/main/webapp WEB-INF/views/ # JSP 视图禁止直接访问 static/ # css/js WEB-INF/web.xml # 过滤器与 Servlet 映射视图放在 WEB-INF 下是硬要求这样用户不能直接敲 URL 绕过控制器访问 JSP。web.xml 里过滤器顺序也有讲究编码过滤器在最前登录和权限过滤器在后顺序错了会出现“中文乱码还没解决就被拦去登录页”的玄学问题。2.4 数据表与关键字段设计表不用多四张就够撑起整个演示用户表、快递记录表、货架表、通知日志表。关键是字段要能支撑前面四条业务线而不是事后补字段。表名关键字段设计说明t_userid, phone, password_hash, rolerole 区分站点人员和普通用户登录过滤器据此判权限t_packageid, tracking_no, receiver_phone, company, shelf_no, pickup_code, status, created_at, picked_atstatus 用枚举值 0 待取件 / 1 已取件 / 2 已过期pickup_code 建唯一索引t_shelfid, shelf_no, capacity, used入库时校验容量避免货架号随便填t_notify_logid, package_id, phone, content, sent_at通知线留痕答辩时能证明“通知确实触发了”pickup_code 建唯一索引这条是血泪经验不建索引并发入库时可能生成重复取件码用户拿同一个码取到两个件演示现场直接翻车。status 用整型枚举而不是字符串查询和统计都省事。created_at 和 picked_at 用 datetime出库时写入后面算“平均取件时长”这类指标直接能查。3. 核心模块实现Servlet、Filter、Session三件套怎么落地设计定完落到代码。这一章按“请求进来—会话维持—横切拦截—数据落库”的顺序写每个模块给关键代码和参数说明能直接对照改。3.1 入库Servlet参数校验与取件码生成入库是写操作的入口Servlet 要薄校验和生成逻辑放服务层。下面这段是控制器的典型写法WebServlet(/station/inbound) public class InboundServlet extends HttpServlet { private final PackageService packageService new PackageService(); Override protected void doPost(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException { // 1. 收参数统一转成字符串再交给服务层校验 String trackingNo req.getParameter(trackingNo); String phone req.getParameter(receiverPhone); String company req.getParameter(company); String shelfNo req.getParameter(shelfNo); try { // 2. 服务层完成校验、生成取件码、落库、写通知日志 Package pkg packageService.inbound(trackingNo, phone, company, shelfNo); req.setAttribute(pkg, pkg); req.getRequestDispatcher(/WEB-INF/views/inbound_success.jsp) .forward(req, resp); } catch (BizException e) { // 3. 业务异常回填表单不抛 500 req.setAttribute(error, e.getMessage()); req.getRequestDispatcher(/WEB-INF/views/inbound.jsp) .forward(req, resp); } } }这段代码的关键在异常处理业务校验失败手机号格式不对、货架已满走 BizException回填表单让用户改只有系统异常才让它冒到容器。取件码生成放在服务层通常的做法是“六位数字 当天已用码集合去重”生成后立刻在唯一索引上兜底两层保险。参数说明上trackingNo 和 phone 必填company 和 shelfNo 允许为空但为空时给默认值避免空指针。3.2 登录与Session会话建立、续期与销毁Session 是这套系统的会话黑匣子登录成功后写入用户标识和角色后续过滤器都从这里取。写法上要注意三件事登录成功先 invalidate 旧会话再建新的防止会话固定攻击设置合理的超时时间登出时显式销毁。WebServlet(/login) public class LoginServlet extends HttpServlet { private final UserService userService new UserService(); Override protected void doPost(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException { String phone req.getParameter(phone); String password req.getParameter(password); User user userService.authenticate(phone, password); if (user null) { req.setAttribute(error, 手机号或密码不正确); req.getRequestDispatcher(/WEB-INF/views/login.jsp).forward(req, resp); return; } // 登录成功废弃旧会话防止会话固定 HttpSession old req.getSession(false); if (old ! null) old.invalidate(); HttpSession session req.getSession(true); session.setMaxInactiveInterval(30 * 60); // 30 分钟 session.setAttribute(loginUser, user); session.setAttribute(role, user.getRole()); resp.sendRedirect(req.getContextPath() /station/home); } }setMaxInactiveInterval 的单位是秒30 分钟对课程演示够用太短演示中途掉线太长又体现不出会话管理。role 单独存一份而不是每次从用户对象取是为了过滤器里少一次对象判空。注意 sendRedirect 而不是 forward登录成功后要换 URL避免刷新重复提交。3.3 过滤器链编码、登录、权限三道闸Filter 是这套系统里最能体现“横切关注点”的地方。三道闸按顺序排编码过滤器解决中文乱码登录过滤器拦未登录访问站点侧权限过滤器拦角色不符的请求。顺序在 web.xml 里写死filter filter-nameencodingFilter/filter-name filter-classcom.example.express.filter.EncodingFilter/filter-class /filter filter-mapping filter-nameencodingFilter/filter-name url-pattern/*/url-pattern /filter-mapping filter filter-nameauthFilter/filter-name filter-classcom.example.express.filter.AuthFilter/filter-class /filter filter-mapping filter-nameauthFilter/filter-name url-pattern/station/*/url-pattern /filter-mapping编码过滤器里做两件事request.setCharacterEncoding(UTF-8) 和 response.setContentType(text/html;charsetUTF-8)。注意只对 POST 有效GET 参数编码取决于容器配置所以表单一律用 POST。登录过滤器判断 session 里有没有 loginUser没有就重定向到登录页并且要把原始请求 URL 存进 session登录后跳回去这个细节答辩时很加分。权限过滤器只放行 role 匹配的路径比如 /station/* 只允许站点人员普通用户访问直接 403。3.4 查询与出库状态机与并发控制查询线要防越权用户输入手机号后服务层必须再校验一次“当前会话用户是否就是这个手机号的主人”或者要求同时输入取件码。课程设计里更稳妥的做法是双因子——手机号 取件码都匹配才返回记录。出库线本质是一个状态迁移待取件 → 已取件必须用带条件的 UPDATE 防止重复核销。UPDATE t_package SET status 1, picked_at NOW() WHERE pickup_code ? AND status 0;这条 SQL 的返回值是受影响行数等于 1 才算核销成功等于 0 说明码不对或已被取走服务层据此抛业务异常。不要先 SELECT 再 UPDATE两步之间会有并发窗口两个人同时核销同一个码后一个会把前一个覆盖掉。用条件更新一条语句解决是这类系统最省事的并发控制。出库成功后同步写一条通知日志记录“已取件”方便对账。4. 避坑与排查这类项目最容易翻车的五个点代码能跑不等于能演示下面五个点是我带项目时反复见到的翻车现场按“现象 → 原因 → 解决”写照着排查能省不少时间。4.1 中文乱码POST 正常 GET 乱码现象是表单提交的中文正常但地址栏带参数跳转后页面显示问号。原因是编码过滤器只设了 request 的字符集GET 参数由容器按默认编码解析过滤器管不到。解决办法是统一用 POST 提交查询条件或者在容器连接器上配置 URI 编码两者选其一不要指望在 Servlet 里对 GET 参数重新解码那是治标。我一般直接在项目规范里写死“所有带中文的请求走 POST”从源头掐掉。4.2 过滤器顺序错登录页自己被拦现象是访问登录页也被重定向到登录页无限循环。原因是登录过滤器的 url-pattern 写成了 /*把登录页和静态资源也拦了。解决是把登录页、登录接口、静态资源加入白名单过滤器里先判断路径前缀再决定是否校验会话。顺序上编码过滤器必须在最前否则白名单判断里取到的参数本身就是乱码判断会失效。4.3 取件码重复并发入库撞码现象是演示时两个件生成了同一个取件码用户取件取错。原因是生成逻辑是“查最大码加一”两个请求同时查到同一个最大值。解决是数据库唯一索引兜底插入失败就重试生成重试次数设个上限比如三次超过就返回“系统繁忙”。唯一索引不是可选项是这类系统的后悔药建表时就加上。4.4 Session 丢失重启后登录态全没现象是演示中途重启了应用所有人被踢回登录页。原因是 Session 存在内存里进程一重启就没了。课程设计阶段这不算 bug但答辩前要提前说明“会话存内存生产环境会换集中存储”别等老师问。如果一定要演示重启不掉线可以把登录态做成签名 Cookie但这会引入新的安全考量课程设计里不推荐讲清楚取舍比硬做更加分。4.5 视图直连绕过控制器改数据现象是有人直接访问 /WEB-INF/views 下的 JSP 之外的路径或者把表单 action 改成别的接口绕过了权限校验。原因是视图没放 WEB-INF或者接口没做服务端二次校验。解决是视图一律放 WEB-INF所有写接口在服务层再校验一次角色和数据归属不能只靠前端隐藏按钮。前端校验是体验服务端校验才是安全这条在答辩时被问到的概率很高。5. 验收与答辩怎么证明这套系统真的跑通了验收不是把页面点一遍就完事要按业务线走场景每条线准备一个“正常路径 一个异常路径”现场演示时先讲预期再操作。我一般会准备一张验收清单答辩前自己先走一遍走不通的当场修别留到台上。验收项操作步骤通过标准入库正常站点人员登录录入完整信息提交生成记录取件码六位且不重复通知日志有记录入库异常手机号格式错误提交停留表单页提示具体错误不产生脏数据查询越权用户A用用户B的手机号查询返回空或提示无权限不泄露B的记录出库核销用正确取件码核销状态变已取件picked_at 有值重复核销被拒会话失效登录后等待超时再操作重定向登录页登录后跳回原页面权限拦截普通用户访问 /station/*返回 403 或跳转提示页不进入站点功能答辩时老师最爱问的三个问题提前准备好答案一是“你的 MVC 分层边界在哪”答的时候指着目录结构说清 Servlet 不写 SQL、Service 不碰 request二是“Session 和 Cookie 什么关系”答 Session 靠 Cookie 里的会话 ID 关联登录后换了新会话 ID 是为了防固定攻击三是“过滤器顺序为什么这么排”答编码在前保证后续判断拿到的参数是对的登录在权限前保证未登录直接拦掉不做无用功。演示节奏上先跑一条完整业务线建立信任再挑一个异常路径展示健壮性最后打开数据库表给老师看落库结果比讲十页 PPT 都管用。从那以后我每次带这类综合项目验收前都强制自己按清单走一遍异常路径因为正常路径谁都会点翻车永远翻在边界上。希望这套结构能帮你把快递e栈从“能跑”做到“能讲清楚、能验收”需要完整工程和建表脚本的话按项目里的资源清单取用即可。本文还有配套的精品资源点击获取