孙玲的空间“校园文具销售系统”这个题目，第一次听会觉得它就是个普普通通的商城系统。商品换成笔，订单走一样的流程，套个模板改改首页文案就能交差。但我把这个题目从开题报告一路做到最终实现，才发现真正难的地方根本不在页面，而在需求边界、库存处理和订单状态流转。这篇文章会完整拆解我是怎么把“校园文具销售系统的设计与实现”这个开题题目落地成真实系统的，包含需求分析、技术选型、表结构、核心代码、测试用例和一批实测踩坑记录，适合正在准备毕业设计开题、课程设计，或者想拿一个完整 Java Web 项目练手的开发者参考。
1. 项目定位：先别急着写代码
1.1 开题报告真正要回答的问题
“校园文具销售系统的设计与实现”这类题目在选题池里出现频率极高，高到很多同学第一反应就是从网上找一个 ECShop 或者淘淘商城那种大型电商开源项目改个壳。但我必须提醒一句：开题报告不是写一篇电商行业综述，它真正要回答的问题只有四个：系统给谁用、解决什么具体问题、功能边界在哪里、凭什么判断最终做成功了。
我见过不少开题报告，前三分之一在介绍互联网购物趋势，中间三分之一在抄某个教程项目的功能列表，最后三分之一是一句“本系统采用 Java 技术完成”。这种开题报告在答辩时特别容易被追问，因为老师一眼就能看出你还没想清楚系统边界。
正确的做法是，在写开题报告之前先假设自己就是那个文具店管理员。你需要记录下来的不是“展示商品、下单”这种网上抄来的功能，而是更具体的流程：学生怎么注册登录，怎么浏览分类，加了商品后库存在哪里扣，订单生成之后是一个什么样的状态，管理员从哪里看到新订单，是安排配送还是到店自取。这串流程走通了，开题报告的“可行性分析”和“功能模块”自然就有血有肉。
1.2 校园场景和普通商城的差异
既然题目强调“校园”，它就不只是一个技术练习，还会明显受校园业务约束。首先，用户角色只有学生和管理员两类，学生的身份可以用学号做唯一标识，管理员通常就是校内便利店或学生会负责人，不复杂。其次，用户规模不会很大，并发压力集中在课间、午休或开学季这种特定时段。但文具具有价格低、频次高的特点，订单量不大，但下单动作密集，这对库存一致性是有考验的。
真正影响设计的差异点有三个：一是取货方式，校园内通常不会走快递物流，常见的是到店自取或者送到宿舍楼，所以订单状态里要设计“待自取”这类节点，不能照搬普通 B2C 的“待发货—已发货—已签收”；二是支付方式，毕设项目一般不需要真正接入微信支付宝，有些学校允许做模拟支付，有些最多接入沙箱，所以支付模块要设计成可替换，避免答辩现场因为支付失败直接翻车；三是系统使用者的技术水平，管理员不太可能懂数据库，所以后台操作必须做到可视化，哪怕只是简单的增删改查页面。
如果你在开题阶段就想清楚这几个业务差异，后面做数据库和接口设计时会特别顺，基本等于提前排掉一多半需求变更。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 需求分析：把“卖文具”翻译成功能模块
2.1 角色与权限划分
校园文具销售系统的角色不需要过度设计，两级权限完全足够：普通用户和管理员。普通用户就是在校学生，负责浏览、搜索、加购物车、下单、支付、查看订单和取消订单。管理员负责商品上下架、分类维护、库存调整、订单处理和销售统计。再多出来的角色，比如供应商、店长、配货员，对一个课程设计性质的项目来说都属于过度设计，只会增加代码量，并不会给答辩加分。
这里有个容易踩的坑：很多人在开题报告里写“系统拥有完善的权限管理”，然后真去实现 RBAC 或者 Spring Security 完整权限模型。实际上在这个规模下，一张 user 表加一个 role 字段，配合拦截器判断角色，足够解决绝大部分问题。真要在答辩时被问到“权限安全怎么做”，你可以说在此基础上预留了扩展点，将来可以接入 Spring Security，而不是在毫无压力的场景里提前发明需求。
角色与功能可以整理成一张模块划分表，这在开题报告里非常加分，也方便后面安排开发顺序：
| 功能模块 | 子功能 | 使用角色 | 说明 |
|---|---|---|---|
| 注册登录 | 账号注册、登录、修改密码 | 学生 | 以学号作为唯一账号 |
| 商品浏览 | 分类浏览、搜索、商品详情 | 游客、学生 | 游客可浏览不可下单 |
| 购物车 | 加入、修改数量、勾选、删除 | 学生 | 购物车按数据库存储 |
| 订单管理 | 下单、支付模拟、取消、确认 | 学生 | 核心模块 |
| 后台管理 | 商品、分类、库存、订单、公告 | 管理员 | 管理员专属 |
| 数据统计 | 销售额、热销商品、订单趋势 | 管理员 | 展示给答辩加分 |
2.2 核心业务流程梳理
需求分析做得好不好，看业务流程图就能判断。这个项目的主流程可以拆成六步：注册登录、浏览商品、加入购物车、生成订单、支付或取消、管理员跟进。每一步之间要有明确的状态承接关系，尤其是订单，必须定义清楚状态机：0 待支付、1 已支付待备货、2 待自取/配送中、3 已完成、4 已取消。
这里我特意没有按普通电商那样把“待发货”和“配送中”拆得很细，而是合并成待自取，因为校园场景里学生可能上午下单中午就去店里拿，状态太多反而让管理员操作繁琐。订单状态转换还要考虑异常分支，比如待支付超过 30 分钟自动取消，库存不足时整单取消，用户未支付前可以手动取消。这些分支在开题报告的“可行性分析”里不需要写太细，但到了数据库设计和接口设计阶段，它们会直接影响状态字段的取值和业务代码的判断逻辑。
2.3 非功能需求别忽略
有些开题报告只写功能需求，完全不考虑性能、安全、兼容性，结果开发完成之后被老师一句“并发下单会不会超卖”就问倒了。这个问题要在项目里提前设计好，库存扣减必须使用“乐观锁”方式，也就是更新 stock 时同时判断 stock >= 购买数量，受影响行数为 0 就抛出库存不足。另外密码不能明文存储，至少用 BCrypt 或 MD5 加盐，数据库统一使用 utf8mb4，防止特殊字符乱码。
非功能需求里还有一条容易被忽视，就是日志记录。管理员下架商品、修改库存、关闭订单这些敏感操作，最好记录到一张操作日志表里，答辩时展示“系统具备操作审计能力”会非常加分。前端页面则要尽量兼容 Chrom