校园文具销售系统开发实战：从需求分析到核心实现

“校园文具销售系统”这个题目，第一次听会觉得它就是个普普通通的商城系统。商品换成笔，订单走一样的流程，套个模板改改首页文案就能交差。但我把这个题目从开题报告一路做到最终实现，才发现真正难的地方根本不在页面，而在需求边界、库存处理和订单状态流转。这篇文章会完整拆解我是怎么把“校园文具销售系统的设计与实现”这个开题题目落地成真实系统的，包含需求分析、技术选型、表结构、核心代码、测试用例和一批实测踩坑记录，适合正在准备毕业设计开题、课程设计，或者想拿一个完整 Java Web 项目练手的开发者参考。

1. 项目定位：先别急着写代码

1.1 开题报告真正要回答的问题

“校园文具销售系统的设计与实现”这类题目在选题池里出现频率极高，高到很多同学第一反应就是从网上找一个 ECShop 或者淘淘商城那种大型电商开源项目改个壳。但我必须提醒一句：开题报告不是写一篇电商行业综述，它真正要回答的问题只有四个：系统给谁用、解决什么具体问题、功能边界在哪里、凭什么判断最终做成功了。

我见过不少开题报告，前三分之一在介绍互联网购物趋势，中间三分之一在抄某个教程项目的功能列表，最后三分之一是一句“本系统采用 Java 技术完成”。这种开题报告在答辩时特别容易被追问，因为老师一眼就能看出你还没想清楚系统边界。

正确的做法是，在写开题报告之前先假设自己就是那个文具店管理员。你需要记录下来的不是“展示商品、下单”这种网上抄来的功能，而是更具体的流程：学生怎么注册登录，怎么浏览分类，加了商品后库存在哪里扣，订单生成之后是一个什么样的状态，管理员从哪里看到新订单，是安排配送还是到店自取。这串流程走通了，开题报告的“可行性分析”和“功能模块”自然就有血有肉。

1.2 校园场景和普通商城的差异

既然题目强调“校园”，它就不只是一个技术练习，还会明显受校园业务约束。首先，用户角色只有学生和管理员两类，学生的身份可以用学号做唯一标识，管理员通常就是校内便利店或学生会负责人，不复杂。其次，用户规模不会很大，并发压力集中在课间、午休或开学季这种特定时段。但文具具有价格低、频次高的特点，订单量不大，但下单动作密集，这对库存一致性是有考验的。

真正影响设计的差异点有三个：一是取货方式，校园内通常不会走快递物流，常见的是到店自取或者送到宿舍楼，所以订单状态里要设计“待自取”这类节点，不能照搬普通 B2C 的“待发货—已发货—已签收”；二是支付方式，毕设项目一般不需要真正接入微信支付宝，有些学校允许做模拟支付，有些最多接入沙箱，所以支付模块要设计成可替换，避免答辩现场因为支付失败直接翻车；三是系统使用者的技术水平，管理员不太可能懂数据库，所以后台操作必须做到可视化，哪怕只是简单的增删改查页面。

如果你在开题阶段就想清楚这几个业务差异，后面做数据库和接口设计时会特别顺，基本等于提前排掉一多半需求变更。

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，防止特殊字符乱码。

非功能需求里还有一条容易被忽视，就是日志记录。管理员下架商品、修改库存、关闭订单这些敏感操作，最好记录到一张操作日志表里，答辩时展示“系统具备操作审计能力”会非常加分。前端页面则要尽量兼容 Chrome 和手机浏览器，因为学生可能用手机访问，页面布局如果不能自适应，演示效果会打折扣。

3. 技术选型与数据库设计：减少返工的关键一步

3.1 技术栈怎么选

这个题目可选的技术方案很多，但不同方案的开发成本和答辩表现差距很大。我基于常见实践列出三种主流组合，你可以按自己学校的要求来：

我自己最推荐的是 Spring Boot 3 + MyBatis-Plus + MySQL 8 + Vue 3 + Element Plus。原因很简单，Spring Boot 把复杂的配置都自动化了，MyBatis-Plus 连基础增删改查都不用手写 SQL，Vue 配合 Element Plus 可以快速搭出像样的后台管理界面，而且这套技术栈在答辩时说出来老师基本没有异议，也符合近几年主流的毕业设计技术路线。

如果你担心前后端分离会增加复杂度，还有一个折中方案：Spring Boot + Thymeleaf 模板引擎，复用 Bootstrap 做页面，不用单独部署前端项目。开题报告里建议写一种主选方案，再留一段“备选方案对比”，说明为什么不用 JSP，这种“有对比、有取舍”的表述比单纯罗列技术要专业得多。

3.2 数据库表结构设计

数据库是整个系统最核心的部分，表设计得不好，后面写代码会非常痛苦。我的方案是 8 张表：用户表、分类表、商品表、购物车表、订单表、订单明细表、库存变动表、操作日志表。如果还想加公告功能，可以再加一张公告表。这 8 张表覆盖了基本业务闭环，同时不会让人觉得很臃肿。

用户表字段可以这样规划：user_id 主键，学号 username 唯一，password 存加密后的密文，nickname 昵称，phone 手机号，role 角色，status 是否禁用。商品表关键字段是 product_id、category_id、product_name、description、price、stock、image、status，其中 status 表示上下架状态。我用一张商品表同时支撑前台展示和后台管理，没有单独做库存表，而是在商品表里直接存 stock，配合库存变动表记录流水，这样既简单又能实现审计。

订单表和订单明细表是典型的一对多关系。orders 表存 order_id、order_no、user_id、total_amount、status、create_time、pay_time、cancel_time、finish_time，order_no 用时间戳加用户 ID 生成唯一编号。order_item 表存 item_id、order_id、product_id、product_name、product_image、price、quantity、subtotal，这些冗余字段就是为了在商品被删除或改名后，订单历史依然能正确展示。价格也要单独冗余到明细表里，不能每次去查商品表，否则历史订单金额会跟着商品改价而变，这是电商项目里很经典的坑。

3.3 接口设计要点

数据库设计好后，接口设计建议按模块拆成 RESTful 风格。我列一份实际项目里可以直接照用的接口清单：

这些接口在开题报告里不需要全部给出，但列一个接口清单会让老师觉得你已经考虑得很细。接口设计要注意统一返回体，我用的是 {code, message, data} 这个格式，code=200 表示成功，其他码表示业务异常。不要直接用 HTTP 状态码来传达业务错误，因为后端返回 500 时前端不好统一处理，统一返回体会让前端的判断逻辑简单很多。

4. 核心功能实现：从登录到下单

4.1 登录鉴权与角色权限控制

登录模块看起来简单，但它决定了整个系统的安全基调。前后端分离方案下，我建议使用 Token 机制而不是 Session，因为前端部署在静态服务器上，后端是独立服务，用 Session 需要处理跨域携带 Cookie 的问题，麻烦且容易出错。Token 方案简单直接：登录成功后返回一个加密的 token，前端存在 localStorage 里，后续每个请求都放在 Authorization 请求头里。

后端用拦截器统一校验 token。我写了一个 AuthInterceptor，在 preHandle 里读取 token 并解析用户 ID，填充到 ThreadLocal 中，这样后续业务代码直接通过 UserContext 拿到当前用户，不用每次从数据库重新查。下面是一段核心代码，我从实际项目里精简过，思路可以直接套用：

java复制@Component
public class AuthInterceptor implements HandlerInterceptor {

    @Override
    public boolean preHandle(HttpServletRequest request,
                             HttpServletResponse response,
                             Object handler) throws Exception {
        // 放行预检请求
        if (HttpMethod.OPTIONS.matches(request.getMethod())) {
            return true;
        }
        String token = request.getHeader("Authorization");
        if (token == null || token.isEmpty()) {
            response.setStatus(401);
            return false;
        }
        UserToken userToken = tokenService.parseToken(token);
        if (userToken == null) {
            response.setStatus(401);
            return false;
        }
        UserContext.set(userToken);
        return true;
    }

    @Override
    public void afterCompletion(HttpServletRequest request,
                                HttpServletResponse response,
                                Object handler, Exception ex) {
        UserContext.clear();
    }
}

拦截器注册时要有一个白名单配置，比如“/api/user/login”“/api/user/register”“/api/product/**”这些接口不需要登录就能访问。后台管理接口还要判断角色，可以在拦截器里检查 userToken.getRole() 是否管理员，不是就直接返回 403。

4.2 商品管理与图片上传

商品管理模块里最容易出问题的是图片上传。项目规模不需要引入对象存储服务，本地磁盘保存就够用，但要注意两个点：一是数据库里存的是相对路径，比如 /upload/product/xxxx.jpg；二是后端必须配置静态资源映射，让 /upload/** 能映射到实际保存目录。这个配置在 Spring Boot 里几行代码就能完成：

java复制@Configuration
public class WebConfig implements WebMvcConfigurer {
    @Override
    public void addResourceHandlers(ResourceHandlerRegistry registry) {
        String uploadPath = fileProperties.getPath(); // e.g. /home/app/upload/
        registry.addResourceHandler("/upload/**")
                .addResourceLocations("file:" + uploadPath);
    }
}

图片上传还要限制大小和格式。我在 application.yml 里配置了 spring.servlet.multipart.max-file-size: 5MB 和 max-request-size: 10MB，然后后端强制校验图片后缀是 jpg、png、jpeg、webp。别只依赖前端校验，因为通过 Postman 直接请求接口是可以绕过页面的。

4.3 购物车的实现选型

购物车有两种实现思路，一种存浏览器 localStorage，一种存数据库。我坚持用数据库，理由是跨端同步方便，也能支撑后台分析。反观 localStorage 方案，学生换个电脑或浏览器购物车就丢了，而且无法做购物车数据分析，要额外写大量同步逻辑。

购物车表设计成 user_id 和 product_id 联合唯一，加商品时如果已存在就增加数量，否则插入新记录。这里要留意一个细节：数量增加前要先查商品当前库存，要是库存剩余 3 个，用户加购 10 个，应该直接拦下来，而不是等到下订单时才报错。提前在购物车环节做库存校验，用户体验会好很多。

代码实现上，购物车接口的入参只需要 productId 和 quantity，后端根据当前登录用户 ID 去处理数据。批量删除时用 foreach 传 id 列表，但千万要拼接自己的用户 ID，防止用户通过篡改请求来删别人的购物车数据，这是基础越权漏洞，答辩时被问到你有没有考虑数据隔离，这就是一个很好的回答点。

4.4 下单、扣库存与事务控制

下订单是整个系统的核心链路，涉及购物车校验、库存扣减、订单生成、明细生成、购物车清理五步，必须放在同一个事务里。我用 @Transactional(rollbackFor = Exception.class) 控制，同时把库存扣减写成一条带条件的 update 语句，避免在代码里先查库存再更新，那种“先查再改”的方式在并发场景下很容易超卖。

核心库存扣减 SQL 是这样：

sql复制UPDATE product
SET stock = stock - #{quantity}
WHERE product_id = #{productId}
  AND stock >= #{quantity}

注意这个 SQL 的关键点在 stock >= #{quantity}，它确保了只有库存足够时才扣减成功。MyBatis 的 update 返回值表示影响行数，如果返回 0，说明库存不够或者商品被下架了，这时候抛出业务异常，整个事务回滚，订单不会创建。我在订单服务里也加入了循环扣减库存的逻辑，防止购物车里多个商品有一个库存不足时，前面的商品被白白扣减：

java复制@Service
@Slf4j
public class OrderServiceImpl implements OrderService {

    @Transactional(rollbackFor = Exception.class)
    @Override
    public Long createOrder(OrderCreateDTO dto) {
        Long userId = UserContext.getUserId();
        List<CartItem> cartList = cartMapper.selectCheckedItems(userId);
        if (cartList == null || cartList.isEmpty()) {
            throw new BusinessException("没有勾选的商品");
        }
        BigDecimal total = BigDecimal.ZERO;
        for (CartItem item : cartList) {
            int rows = productMapper.deductStock(item.getProductId(), item.getQuantity());
            if (rows == 0) {
                throw new BusinessException("商品库存不足：" + item.getProductName());
            }
            total = total.add(item.getPrice().multiply(BigDecimal.valueOf(item.getQuantity())));
        }
        Order order = buildOrder(userId, total);
        orderMapper.insert(order);
        for (CartItem item : cartList) {
            orderItemMapper.insert(buildOrderItem(order.getOrderId(), item));
        }
        cartMapper.deleteCheckedItems(userId);
        return order.getOrderId();
    }
}

这段代码看起来简单，但每行都有讲究。事务保证五个步骤要么全部成功要么全部回滚，如果中途抛出库存不足异常，前面已经扣掉的库存也会跟着回滚。BigDecimal 用来计算金额而不是 double 或 float，这是金融领域最基本的规范，就是为了避免浮点数精度误差导致少收用户一分钱。订单号单独生成，我用的格式是 yyyyMMddHHmmss 加用户 ID 加随机数，保证并发不重复。

4.5 订单状态流转与自动关闭

订单状态是系统的骨架，建议在启动类里定义好状态枚举，而不是让业务代码里到处是魔法数字。我用 0、1、2、3、4 五个状态分别对应待支付、已支付待备货、待自取、已完成、已取消，并用一个状态流转表来限制合法跳转。比如已取消的订单不允许再支付，已完成的订单不允许再取消，这样能避免业务逻辑失控。

超时取消采用定时任务实现，我使用 Spring 的 @Scheduled 注解，每 5 分钟扫描一次待支付且创建时间超过 30 分钟的订单，把它们更新为已取消，同时把扣掉的库存回补回去。这一步非常关键，如果只关单不回补库存，那些恶意下单选了 50 支笔的人会把库存占光，影响正常用户购买。回补库存的 SQL 也要用条件更新，在 order_status=0 的前提下执行，防止重复回补。

4.6 后台统计与图表展示

后台统计是演示时的亮点模块，实现起来却不复杂。销售额可以用 SUM 函数按天聚合，低端商品用 GROUP BY product_id 排个序，订单趋势按 create_time 分组。统计逻辑我分成了概览和趋势两块：概览给管理员展示今日订单数、今日销售额、累计用户数、总库存数，趋势展示最近 7 天的订单量和销售额。

热门商品排行 SQL 需要考虑订单状态，已取消的订单不应该计入。我是把 orders 表 join order_item 表，同时过滤掉 status=4 的订单：

java复制SELECT p.product_name, SUM(oi.quantity) AS sales_quantity
FROM order_item oi
JOIN product p ON oi.product_id = p.product_id
JOIN orders o ON oi.order_id = o.order_id AND o.status IN (1, 2, 3)
GROUP BY oi.product_id
ORDER BY sales_quantity DESC
LIMIT 10;

前端用 ECharts 或者 Element Plus 自带的统计组件展示折线图和柱状图，效果非常直观。这里需要注意，后端只负责把数据查出来封装成 list，前端直接引用即可，不要在 SQL 里做太复杂的多级嵌套查询，能拆就拆，越简单越容易维护。

5. 上线前测试与高频排坑

5.1 设计一套像样的测试用例

谈测试，很多自学项目就直接走一遍 UI 点一点就完事了。但好的项目至少要覆盖核心业务链路和异常分支，手工测试用例我一般按场景编号记录，方便排查问题。下面是我在这个项目里实际用过的用例表，你可以照这个思路去补：

5.2 高频 Bug 排解实录

我在开发和答疑过程中遇到频率最高的几个问题，基本可以覆盖大多数同类项目。第一个是 MySQL 8 数据库连接报时区错误或者驱动类找不到，解决方法是连接串加上 serverTimezone=Asia/Shanghai，驱动用 com.mysql.cj.jdbc.Driver，同时确认 MySQL 的隔离级别和 utf8mb4 配置。

第二个是图片上传成功后页面不显示。常见原因就是静态资源映射没配，或者数据库存的路径和实际请求路径不一致。我建议统一规则：数据库存 /upload/product/xxxx.jpg，前端请求时直接拼域名，不要存 localhost:8080 这种绝对地址，否则部署到服务器上又要改。

第三个是 @Transactional 不生效。如果你发现前面扣了库存，后面订单插入失败，库存居然没有回滚，多半是这个原因。最常见的是在同一个类里用 this.createOrder() 直接调方法，导致事务代理失效。解决方法是注入自身 Bean 或拆成两个类调用。

第四个是 MyBatis 动态 SQL 出现列名无法识别问题。写 SQL 时尽量用 product_name 这种下划线风格，在 resultMap 里做好映射，不要依赖 MyBatis-Plus 的驼峰自动转换到一半又手动拼接 SQL。如果查询结果一直是 null，优先检查实体类字段名和数据表列名是否对得上。

第五个是跨域问题。前后端分离部署时，前端过 API 请求很容易被浏览器的同源策略拦住。在 Spring Boot 里加一个全局 CORS 配置就能解决：

java复制@Configuration
public class CorsConfig implements WebMvcConfigurer {
    @Override
    public void addCorsMappings(CorsRegistry registry) {
        registry.addMapping("/**")
                .allowedOriginPatterns("*")
                .allowedMethods("GET", "POST", "PUT", "DELETE", "OPTIONS")
                .allowedHeaders("*")
                .allowCredentials(true)
                .maxAge(3600);
    }
}

第六个是页面响应慢。这个系统数据量不大，慢往往是因为 SQL 没走索引。建议给订单表的 user_id、order_no，购物车表的 user_id 和 product_id，商品表的 category_id 建索引。索引建好之后，大部分查询都能在几十毫秒内返回。

还有一个容易被问到的点，就是部署。别在答辩前才临时把 IDEA 里的项目导成 jar 包，一定要提前试一次 mvn clean package 并在本地用 java -jar 跑起来，确认静态资源路径、数据库连接、前端打包产物都正常。很多项目在 IDEA 里运行没事，一打包就出图片路径或配置问题，提前踩一遍坑能救命。

6. 关于这个项目的几点真实经验

准备这门课或者毕业设计时，我最大的经验是：真正拉开差距的从来不是用了多精尖的技术，而是能不能把一条业务链路完整走通。从开题报告到最终答辩，我反复打磨的不是首页样式，而是“登录—浏览—加购—下单—扣库存—支付—管理员处理—订单完成”这个闭环。只要愿意在这里花心思，答辩时你甚至不用背稿，讲这段流程的细节就能讲满十分钟。

如果让我给刚开始动手的人提一条建议，那一定是先做“最小可用版本”：先让普通用户能注册登录、浏览商品、下单成功，管理员能修改商品状态、看到新订单。把这条链路跑通了，再考虑加搜索、统计、公告、图片上传。反过来从上而下做，很容易前面几周都在折腾路由和页面框架，最后核心业务却没时间打磨。我给其他同学做过几轮代码走查，凡是进度失控的，基本都是没有守住这个优先级。

最后分享一个来自实际交付的小技巧：演示的时候准备一台备用浏览器，登录好一个管理员账号、一个学生账号，提前造好一批带真实图片的文具数据。不要在现场边注册边填商品，也不要指望校园网一定顺畅，所有操作先用录屏走一遍，把可能出现的问题都暴露掉再上台。这个习惯救了我无数次，也希望它能同样帮到你。