Lullaby Lee1. 为什么2025年了，纯Servlet商城依然是毕业设计的常青树
先别急着质疑——我知道你心里在想什么：都什么年代了，毕业设计还在用Servlet？Spring Boot都出到3.x了，微服务都快被淘汰了，谁还写web.xml？
但现实情况恰恰相反。五年内我带过的、见过的、评审过的计算机专业毕设项目里，Servlet相关的选题从来就没断过。原因其实很实在：大多数本科院校的Java Web课程，讲的就是Servlet + JSP + MySQL这条线。你课堂上学的、期末实验做的、教材上写的，全是这套东西。到了做毕设的时候，选题要求和课程体系要对齐，技术栈跨度太大反而容易出问题。
再有一个现实考量：毕设的核心不是炫技，而是让老师看到"你理解了这个系统的完整生命周期"——需求分析、数据库设计、编码实现、测试部署。Servlet和JSP这套技术路线，把HTTP请求、会话管理、数据库连接、前后端交互这些Java Web底层的东西全部暴露在明面上，没有任何框架帮你封装。老师一问"你Filter是怎么配的""Session是怎么维持的"，你能原原本本答上来，这个优势是直接写Spring Boot的人不具备的。
所以这篇内容如果被推到你这儿，大概率你也正在纠结选题，或者手里已经攥着一个"servlet网上水果商城系统"的项目不知道该从哪儿下手。那我直接把话说透：这个选题的价值，不在于技术有多新，而在于它是一个典型的、完整的、能落地的B2C电商系统，麻雀虽小五脏俱全。把它的每一个模块掰开揉碎搞明白，你收获的不止是一个毕设，而是对整个Java Web开发路径的完整认知。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 一个"能过答辩"的水果商城，功能上到底要有什么
系统功能设计是答辩老师第一眼看的东西。别小看这一步，我见过太多人上来就写代码，最后功能零零散散，连基本的购物流程都没走通。网上水果商城系统，核心是"商城"两个字，那商城的完整链路就不能缺。
2.1 前台用户端：顾客能干什么
前台面向的是普通消费者，最核心的诉求就是**"看到水果——挑水果——下单买水果"**这一整条链路。按照这个逻辑，前台功能分成几块：
- 用户注册与登录：这个不用多解释，商城必须要有的基础能力。要注意的点是，用户密码不能明文存储，至少做一层MD5加盐处理。答辩的时候老师如果问"你这样存密码安全吗"，你直接甩出"我做了加盐哈希处理"，水平立马不一样。
- 水果商品浏览：列表展示和分类筛选。注意，这里不是简单把所有商品堆到页面上，而是要有分类维度——按水果种类分（苹果类、柑橘类、热带水果类），按销量排序，按价格区间筛选。搜索功能同样需要，别整那种模糊匹配所有字段的粗暴实现，至少按商品名称搜，再做分页展示。
- 商品详情：点进单个水果，要有大图、价格、库存、销量、商品描述。库存这个点容易被忽略，但实际做的时候一定要体现——如果库存为0，你就不能让人家加购物车。
- 购物车管理：加购、改数量、删除、清空、勾选结算。购物车的实现方案后面会细说，但功能上先保证这五个动作全的。
- 订单提交与支付模拟：用户在购物车勾选商品后结算，生成订单。这里不需要接真实支付，但要有"模拟支付"的流程——比如生成订单后状态是"待支付"，点击支付后变"已支付"。这个状态流转一定要清晰。
- 个人中心：查看我的订单列表、订单状态（待发货、已发货、已完成），以及修改个人信息、修改密码。
- 购物评价：收到货之后可以对商品进行评价。这个一般毕设很少做，但做了就是加分项，因为它体现了电商系统的互动闭环。
2.2 后台管理端：管理员要管什么
后台是给系统运营人员用的，别做一堆花里胡哨的统计图表，核心就是把数据管起来：
- 管理员登录：和普通用户登录分开，单独一张管理员表，权限独立。
- 水果商品管理：商品的增删改查。上架新水果、修改价格、调整库存、删除下架。
- 分类管理：商品分类的维护，新增分类、修改名字、删除分类。
- 订单管理：查看所有用户订单，按状态筛选。核心操作是"发货"——把订单状态从"已付款"改成"已发货"。再细一点可以做"查看订单详情"，看这个订单里有哪些商品、多少钱、收货人是谁。
- 用户管理：查看注册用户列表，禁用/启用账号。别小看这个功能，有用户体系就必然需要账号管理能力。
2.3 功能边界的建议：别给自己挖坑
很多同学做毕设恨不得把所有功能都往上报，什么优惠券系统、积分体系、多人拼团、直播带货，全列上去。听我一句劝：毕设的功能复杂度，一定要和你的时间和能力匹配。
功能太多，意味着表结构更复杂、代码量成倍增长、联调成本指数级上升。而且答辩的时候，老师会挑你最薄弱的功能深挖——你做了个优惠券，但优惠券叠加规则没想清楚，被问住反而丢分。
比较稳妥的功能矩阵是：前台做全购物主链路（注册登录→浏览搜索→购物车→下单支付→订单管理→评价），后台做全数据管理链路（商品→分类→订单→用户）。 这套功能做完，系统完整性已经很高了，老师挑不出明显的短板。
3. 数据库设计：五张核心表撑起整个商城
数据库设计是毕设的基础工程，也是老师稳拿的第一张图纸。网上水果商城的表不用刻意设计得很花哨，但一定要满足基本范式，并且表和表之间的关联关系要严谨。
3.1 核心数据表清单
我按实际开发习惯给你列出最核心的几张表，你可以照着这个思路去建模：
| 表名 | 功能 | 关键字段 |
|---|---|---|
t_user |
前台用户表 | id（主键自增）、username、password（加盐密文）、nickname、phone、address、avatar、create_time、status |
t_admin |
后台管理员表 | id、username、password、real_name、create_time |
t_category |
水果分类表 | id、name、sort_order、create_time |
t_fruit |
水果商品表 | id、category_id（关联分类）、name、image、price、stock、sales、description、status（上架/下架）、create_time |
t_cart_item |
购物车表 | id、user_id（关联用户）、fruit_id（关联商品）、quantity、checked、create_time |
t_order |
订单主表 | id、order_no（订单编号）、user_id、total_amount、status（待支付/已付款/已发货/已完成/已取消）、receiver_name、receiver_phone、receiver_address、create_time、pay_time |
t_order_item |
订单明细表 | id、order_id（关联主表）、fruit_id、fruit_name（冗余快照）、price（快照）、quantity |
3.2 设计逻辑说明：为什么要冗余这些字段
这里我要特意讲两个容易被忽略但答辩高频问到的设计细节。
第一个，t_order_item里为什么要有fruit_name和price这个冗余字段？ 因为订单一旦生成，商品