企业官网建设流程全解析

1. 项目剖析：一个SSM种子商店到底在做什么

先把这个项目看透彻。基于SSM框架的种子商店网站，本质上是一个标准的B2C电商系统，不过商品换成了种子——蔬菜种子、花卉种子、粮食作物种子这类农业物资。业务链条和京东、淘宝上任何一个店铺后台的结构没有本质区别：前台用户浏览商品、加购物车、下单支付，后台管理员维护商品、处理订单、管理用户。

这也正是这个毕设项目最聪明的地方。它没有去碰那些高不可攀的复杂场景，而是把一套经典的电商业务模型，用SSM这种最传统也最稳妥的技术栈完整落地。你可以把SSM理解成Java Web开发领域的“老三样”：Spring管对象、SpringMVC管请求分发、MyBatis管数据库读写。这三者组合在一起，再加上MySQL存储数据、JSP渲染页面，就构成了绝大多数高校毕设项目的技术底座。

选择SSM而不是Spring Boot，绝不是因为技术落后。从教学角度看，SSM框架的配置全部显式暴露，你可以看到每个Bean是怎么注册的、每个Mapper接口是如何绑定XML的、每个拦截器是如何拦截请求的。这种“看得见摸得着”的学习路径，对理解Java Web底层原理反而更有帮助。而在实际毕业设计中，SSM项目也意味着你可以在答辩时把框架源码层面、配置层面、请求流转层面的原理讲得清清楚楚，这在评委眼中是有分量的。

这个项目涉及的角色有三种：游客或普通用户、后台管理员、系统本身。用户侧解决的是“我要买种子但要挑得明白、买得方便”的问题，管理侧解决的是“商品要能上架、订单要能处理、用户要能管理”的问题。一个完整交付的SSM种子商店，绝不是几个零散的增删改查页面拼凑出来的玩具，而是一套能跑通全流程、能讲出设计逻辑、能应对答辩追问的完整系统。

这个项目适合谁来参考？如果你正在准备Java方向的毕业设计，或者你在培训班学完SSM但对“怎么把这些框架组装成一个完整的项目”没有头绪，再或者你后续想往电商方向做扩展，这套代码和文档都值得你沉下心过一遍。它既是课程学习成果的综合检验，也是从“写练习题”到“做一个系统”的分水岭式项目。

2. 整体设计思路：业务模型、角色权限与模块边界

任何一个项目在动手写代码之前，首要任务是把业务边界划清楚。种子商店网站的业务模型并不复杂，但恰恰因为看似简单，很多人在设计阶段就容易漏掉关键细节。

2.1 角色权限体系：三类用户的边界划分

系统涉及的角色必须从数据库设计阶段就明确下来。用户表里用字段区分角色是一种常见做法。我建议用role字段（int类型）来标识用户身份：1代表普通用户，2代表管理员。但这里要注意一个实操问题，SSM项目的后台管理系统和前台商城，在代码组织上需要做物理隔离。

最合理的做法是：前台用户端访问/index这类路径，后台管理端访问/admin/前缀的路径。通过SpringMVC的拦截器（HandlerInterceptor）对/admin/路径做登录校验和角色校验，未登录直接重定向到管理员登录页，已登录但role不是2的一律拒绝。这套拦截逻辑要写在SpringMVC配置里。

<mvc:interceptors> <mvc:interceptor> <mvc:mapping path="/admin/**"/> <bean class="com.shop.interceptor.AdminInterceptor"/> </mvc:interceptor> </mvc:interceptors>

拦截器的preHandle方法里，从Session中取出登录用户对象，判断是否存在以及角色是否为管理员。这里有个非常容易被忽视的坑：如果你的静态资源路径也用了/admin/开头，拦截器会把CSS、JS文件也拦住，导致后台页面样式全部丢失。解决方式是给静态资源单独设置路径前缀，比如/static/admin/，并放行静态资源。

2.2 模块划分：前台展示与后台管理两个子系统

从功能模块的粒度看，种子商店网站可以拆成两个子系统。

前台用户子系统，核心模块包括：

• 用户注册与登录（MD5加密存储密码、Session会话管理）
• 种子商品展示（首页轮播图、商品分类导航、商品列表分页、商品详情）
• 搜索与筛选（按名称模糊查询、按分类筛选、按价格区间查询）
• 购物车管理（加入购物车、修改数量、删除商品、结算跳转）
• 订单管理（订单创建、订单状态查询、取消订单、确认收货）
• 个人中心（基本信息修改、收货地址管理、密码修改）

后台管理子系统，核心模块包括：

• 管理员登录与权限校验
• 商品管理（分类增删改查、种子信息增删改查、上架下架、图片上传、库存管理）
• 订单管理（订单列表、订单状态更新：发货处理，通过状态机流转）
• 用户管理（用户列表、用户禁用/启用、重置密码）
• 数据统计（基于时间维度的订单数量统计、商品销量统计，用ECharts图表呈现曲线）

模块边界清楚了，工作量和分工也就清楚了。很多人做毕设时喜欢一上来就写代码，这个顺序反了。我遇到过不少同学，项目写到一半才发现某个功能没地方放，或者表结构不支持某个业务操作，最后只能推倒重来。

2.3 为什么选这种设计：答辩时怎么把话讲圆

评委在答辩时问得最多的问题就是：“你这个系统为什么要这么设计？”你要能给出站得住脚的理由。

为什么用SSM而不是Spring Boot？因为SSM让你理解每个框架的职责边界，而且课程内容通常就是围绕SSM展开的。为什么前台和后台要分离？为了保证权限隔离，防止普通用户直接访问管理接口。为什么购物车用Session存储而不是存数据库？因为购物车是临时性数据，存Session减少数据库压力，用户关闭浏览器后购物车清空也符合实际场景（未登录用户没有持久化购物车的要求）。为什么订单状态用状态字段而不是直接删记录？因为电商系统需要保留完整的生命周期记录，这是审计与追踪的基础。

把这些设计理由准备充分，答辩时基本能做到对答如流。

3. 数据库设计：种子商品与订单表的字段级拆解

数据库是SSM项目的灵魂。说实话，我见过太多毕设项目因为表结构设计不合理，导致后期功能实现时各种别扭。种子商店的表结构设计，我建议按下面这套来落地。

3.1 核心表结构：字段设计与关联关系

第一张表是用户表，字段包括：id（自增主键）、username（用户名，唯一索引）、password（MD5加密后的密码）、real_name（真实姓名）、phone（手机号）、email（邮箱）、role（角色标识，1用户2管理员）、status（账号状态，0正常1禁用）、create_time（注册时间）。特别提醒：密码字段长度至少要设64位，因为MD5加密后的结果本身就是32位或64位十六进制字符串，设短了数据根本存不进去。

第二张表是种子分类表，字段包括：id、category_name（分类名称，如叶菜类、茄果类、花卉类）、category_desc（分类描述）、sort_order（排序权重）。这张表的结构特别简单，但它决定了前台导航栏的分类展示顺序。

第三张表是种子商品表，字段要精心设计：

• id：商品ID
• category_id：关联分类表的外键
• seed_name：种子名称
• seed_desc：商品详细描述（富文本内容）
• price：单价（用DECIMAL(10,2)类型，不能用FLOAT或DOUBLE，避免浮点精度问题）
• stock：库存数量（int类型）
• image：商品主图路径（存相对路径，不要存完整的HTTP链接）
• sales：销量（int类型，有用户购买时累加）
• status：上下架状态（1上架0下架）
• create_time：上架时间

这里有个容易忽略的点：图片路径应该采用/static/upload/xxx.jpg这种相对路径，而不能写死http://localhost:8080/...。否则项目部署到其他服务器时，图片全部因为绝对路径写死而加载不出来。项目交付时，图片路径逻辑必须用request.getContextPath()动态拼接，或者页面上用${pageContext.request.contextPath}前缀处理。

第四张表是购物车表。如果你打算把购物车数据持久化，那么表结构建议这样设计：id、user_id、seed_id、quantity、create_time。但更常见的毕设做法是直接用Session保存购物车数据，因为这样可以省去一张表、减少联表查询。我的建议是：前台用户购物车用Session，但购物车数据模型仍然用一个独立的实体类CartItem来管理。

第五张表是订单表，这是整个系统里最关键也最复杂的表：

• id：订单ID
• order_no：订单编号（用时间戳+随机数生成，保证全局唯一）
• user_id：下单用户ID
• total_price：订单总金额
• status：订单状态（0待付款 1已付款待发货 2已发货 3已收货 4已取消 5退款售后）
• receiver_name：收货人姓名
• receiver_phone：收货人电话
• receiver_address：收货地址
• create_time：下单时间
• pay_time：付款时间
• deliver_time：发货时间

第六张表是订单明细表（也可以合并到订单表，但不推荐）：id、order_id（关联订单主表）、seed_id、seed_name（商品名称快照）、seed_image（图片快照）、price（下单时单价快照）、quantity。为什么要做快照？如果用户下单后你把商品改了名或者改了价格，历史订单上的信息也会跟着变，这在实际业务中是不允许的。快照字段保证了订单的不可变性，这一招在答辩时讲出来是加分的。

3.2 表和表之间怎么关联：外键与索引设计

数据库表的三范式（3NF）在毕设项目中当然要遵守，但也不要生搬硬套。种子商品表和分类表之间是“多对一”关系，用一个category_id外键关联即可。订单表和订单明细表是“一对多”关系，通过order_id关联。用户表和订单表是“一对多”关系，通过user_id关联。

索引方面，order_no要建唯一索引，因为订单号不能重复。seed_name建议建普通索引，前台搜索会按名称模糊查询。user_id和category_id作为外键列，默认会建索引，MySQL会自动处理，不用额外操心。

CREATE TABLE `seed_product` ( `id` INT(11) NOT NULL AUTO_INCREMENT, `category_id` INT(11) DEFAULT NULL, `seed_name` VARCHAR(100) NOT NULL, `seed_desc` TEXT, `price` DECIMAL(10,2) NOT NULL, `stock` INT(11) NOT NULL DEFAULT 0, `image` VARCHAR(255) DEFAULT NULL, `sales` INT(11) NOT NULL DEFAULT 0, `status` TINYINT(4) NOT NULL DEFAULT 1, `create_time` DATETIME DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `idx_category` (`category_id`), KEY `idx_seed_name` (`seed_name`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

用utf8mb4而不是utf8，因为utf8mb4能完整支持中文及特殊字符（比如某些生僻字和emoji符号），这是现在MySQL的标配字符集。如果项目已经建了表且数据为utf8，建议尽早改过来。

4. 核心功能实现详解：从商品搜索到订单状态流转

功能层面的实现，是整个项目中编码量最大、也最容易出错的部分。下面挑最核心的几个功能点逐个拆解。

4.1 商品分页查询与多条件搜索

种子商品列表页，必然要支持分页展示和搜索筛选。SSM项目中最推荐的做法是使用PageHelper这个分页插件。加依赖、配插件，然后在Service层直接调用PageHelper.startPage(pageNum, pageSize)，紧接着的查询就是分页查询：

@Override public PageInfo<SeedProduct> searchProducts(String keyword, Integer categoryId, Integer pageNum, Integer pageSize) { PageHelper.startPage(pageNum, pageSize); List<SeedProduct> products = seedProductMapper.searchByCondition(keyword, categoryId); return new PageInfo<>(products); }

对应的Mapper XML中，用动态SQL处理可选的筛选条件：

<select id="searchByCondition" resultType="com.shop.entity.SeedProduct"> SELECT * FROM seed_product <where> <if test="keyword != null and keyword != ''"> AND seed_name LIKE CONCAT('%', #{keyword}, '%') </if> <if test="categoryId != null"> AND category_id = #{categoryId} </if> AND status = 1 </where> ORDER BY create_time DESC </select>

这里要强调一个实战经验：模糊查询不要直接写LIKE '%${keyword}%'，这种字符串拼接方式存在SQL注入风险，还可能因为中文编码问题导致查询失败。用CONCAT('%', #{keyword}, '%')配合#{}占位符，可以完全避免注入风险。

4.2 购物车实现：Session存储的逻辑细节

购物车这个功能，我在带项目时反复强调过：别把简单问题复杂化，但也不能把复杂问题简单化。基于Session的购物车逻辑大概是这样的：

public class Cart { private Map<Integer, CartItem> items = new HashMap<>(); public void addItem(SeedProduct product, int quantity) { CartItem item = items.get(product.getId()); if (item == null) { item = new CartItem(product, quantity); items.put(product.getId(), item); } else { item.setQuantity(item.getQuantity() + quantity); } } public double getTotalPrice() { double total = 0; for (CartItem item : items.values()) { total += item.getPrice() * item.getQuantity(); } return total; } }

购物车数据结构用Map而不是List，好处是去重非常方便：同一件商品加两次，直接在已有条目上修改数量，不需要遍历整个列表判断是否已存在。

加入购物车的Controller层代码要处理一个细节：用户未登录时能否加购物车？我的建议是：允许加，但结算时必须登录。所以在/cart/add这个请求中，不需要强制要求用户登录；但在点击“去结算”按钮时，必须检查Session中是否存在用户对象，否则跳转到登录页并携带回跳地址。如果没有这个设计，用户好不容易挑了五样东西，因为没登录被强制清空，体验会非常糟糕。

购物车页面展示时，结算金额不要用Double累积计算，金额计算建议一律以分为单位用整数运算（例如10.50元存为1050分），避免浮点误差。如果项目比较小、金额也简单，可以用BigDecimal来保证精度，这也是答辩时可以讲的亮点。

4.3 订单创建与状态流转：事务与并发处理

创建订单是整个系统中最核心的业务操作。用户从购物车点击“提交订单”，后端要做这几件事：

1. 从Session取出购物车数据，校验购物车是否为空
2. 遍历购物车商品，校验库存是否充足（SELECT stock FROM seed_product WHERE id = #{id} FOR UPDATE）
3. 计算订单总金额
4. 生成唯一订单号
5. 插入订单主表记录，返回自增ID
6. 批量插入订单明细记录
7. 扣减库存（UPDATE seed_product SET stock = stock - #{quantity} WHERE id = #{id} AND stock >= #{quantity}）
8. 清空购物车

这八步操作必须在一个事务中完成。任何一步失败，前面所有操作都需要回滚。SSM中通过注解@Transactional声明事务：

@Transactional(rollbackFor = Exception.class) public Order createOrder(Integer userId, Cart cart, Address address) { // 上述8步逻辑 }

rollbackFor = Exception.class这个属性必须写上。Spring默认只回滚RuntimeException，如果你在业务代码里抛了检查异常（比如库存不足自定义了CheckedException），不加这个属性事务不会回滚，就会留下库存扣减了但订单没创建的脏数据。这是无数人踩过的坑。

并发问题也要考虑。两个人同时买最后一件商品，如果查询库存和扣减库存不是原子操作，就会超卖。上面的更新语句stock >= #{quantity}做了条件校验，配合数据库的行锁，可以防止这种超卖情况。解释清楚这一点，答辩时评委对你的印象分会明显提高。

订单状态流转用状态机思想来管理。合法状态迁移路径是：待付款（0）→ 已付款（1）→ 已发货（2）→ 已收货（3），任何状态下可申请取消（4）。每个状态变更接口里，都要先判断当前状态是否处于合法迁移的起点，比如只有待付款状态才能付款，只有已付款状态才能发货。不加状态校验，就可能出现订单从待收货直接跳到已完成，甚至从已取消状态又被置为已付款的混乱局面。

4.4 图片上传与文件存储

后台管理添加或编辑种子商品时，需要上传种子图片。SSM中文件上传的Controller处理方法：

@PostMapping("/admin/product/save") public String saveProduct(@RequestParam("file") MultipartFile file, SeedProduct product, HttpServletRequest request) throws IOException { if (file != null && !file.isEmpty()) { // 按日期分目录存储，如 /static/upload/202405/xxx.jpg String realPath = request.getServletContext().getRealPath("/static/upload"); String dateDir = new SimpleDateFormat("yyyyMM").format(new Date()); File dir = new File(realPath, dateDir); if (!dir.exists()) dir.mkdirs(); String originalFilename = file.getOriginalFilename(); String ext = originalFilename.substring(originalFilename.lastIndexOf(".")); String newFilename = System.currentTimeMillis() + "_" + new Random().nextInt(1000) + ext; file.transferTo(new File(dir, newFilename)); product.setImage("/static/upload/" + dateDir + "/" + newFilename); } productService.saveOrUpdate(product); return "redirect:/admin/product/list"; }

这里文件名一定不能使用用户上传时的原始文件名，因为同名文件可能互相覆盖，而且中文文件名在URL访问时会产生编码问题。用时间戳加随机数重新生成文件名，是最稳妥的做法。

文件上传需要在Spring配置中设置最大上传大小：

<bean id="multipartResolver" class="org.springframework.web.multipart.commons.CommonsMultipartResolver"> <property name="maxUploadSize" value="5242880"/> <property name="defaultEncoding" value="UTF-8"/> </bean>

5MB的限制，超过会抛异常，需要全局异常处理器捕获并给用户提示。

5. 环境搭建、代码部署与讲解调试的完整过程

一个SSM项目从拿到源码到本地跑起来，中间会经过环境配置、数据库导入、项目导入、启动调试四个阶段。每个阶段都有固定的坑，我按顺序把过程和注意事项说清楚。

5.1 环境准备：JDK、Tomcat、Maven与IDEA的搭配

SSM项目对版本组合比较敏感，尤其是Java版本和Tomcat版本必须匹配。推荐一套稳妥的搭配。

项目导入IDEA时，选择File -> New -> Project from Existing Sources，然后选择项目的pom.xml文件，IDEA会自动识别Maven项目结构。第一次导入会下载大量依赖，这一步需要耐心等待，不要中断网络。如果下载特别慢，给Maven配置阿里云镜像仓库，在settings.xml中加入：

<mirror> <id>aliyunmaven</id> <mirrorOf>central</mirrorOf> <name>阿里云公共仓库</name> <url>https://maven.aliyun.com/repository/public</url> </mirror>

5.2 数据库初始化与配置文件的修改

项目通常会附带一个seed_shop.sql文件，这是已经建好的数据库脚本。用Navicat或命令行执行：

mysql -u root -p source /你的路径/seed_shop.sql

执行完成后，检查数据库中是否包含了用户表、分类表、商品表、订单表等核心表，并确认表内有初始数据（比如管理员账号admin/admin123）。管理员账号是硬编码在SQL文件里的，密码字段默认是MD5加密后的值。

然后是修改数据库连接配置，在jdbc.properties中：

jdbc.driver=com.mysql.jdbc.Driver jdbc.url=jdbc:mysql://localhost:3306/seed_shop?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai jdbc.username=root jdbc.password=你的数据库密码

如果用的是MySQL 8.0，驱动类名要改为com.mysql.cj.jdbc.Driver，并在pom.xml把mysql-connector-java的版本升级到8.x。不然后续访问数据库会报Loading class 'com.mysql.jdbc.Driver' ...的例外或者数据库驱动不匹配。

5.3 启动Tomcat与常见运行报错分析

配置好Tomcat后启动项目，浏览器访问http://localhost:8080/seed_shop/。项目访问路径取决于Artifact的名称和部署时的上下文路径。

启动过程中最常见的三类报错：

第一类，端口被占用。Port 8080 was already in use，解决方法是把Tomcat的端口改成其他值或在任务管理器中结束占用8080的进程。

第二类，找不到数据库驱动或连接失败。ClassNotFoundException: com.mysql.jdbc.Driver，检查pom.xml中是否引入了mysql-connector-java依赖，检查jdbc.properties的驱动类名是否匹配当前MySQL版本。

第三类，Spring容器初始化失败。报错信息里如果出现BeanCreationException，重点看是哪个Bean创建失败，大多数情况下是Mapper扫描路径配置错误导致的MyBatis接口代理对象创建不成功，或者因为表结构和实体类字段对不上导致的映射异常。把实体类字段名、数据库列名、Mapper XML中的resultMap三者对照着看，通常就能定位问题。

调试运行环节，建议在关键Service实现类中加日志输出。用logger.info()打印订单创建过程中的每一步参数，用DEBUG模式单步跟踪，能非常直观地看到数据流在Controller、Service、Mapper三层之间是怎么流转的。

5.4 定制扩展的切入口：给项目增加差异化功能

毕设答辩时，如果所有人都是一套纯电商模板，评委看多了也会疲劳。我建议在基础功能上做1-2个有特色又不太难实现的定制扩展。

比较推荐的定制方向有这几个：

第一，增加种子种植指南模块。种子商店和普通商品商店的区别在于，用户购买种子后还需要知道怎么种、什么时候种、什么时候浇水施肥。给每种种子关联一份PDF种植指南或图文说明，前台商品详情页增加“种植指南下载”入口，后台增加种植指南管理。这个功能在数据模型上只需要增加一张种植指南表，在商品表中增加一个指南关联ID，实现成本低，但业务逻辑非常贴合种子的属性。

第二，增加简单的销量统计报表。用ECharts在前台或后台渲染一个近七天的销量折线图和商品分类占比饼图，后台统计接口用SQL的GROUP BY DATE(create_time)聚合查询，三天就能完成开发。

第三，增加收藏功能。用户可以对心仪的种子商品点收藏，个人中心展示收藏列表。表结构只需要加一张收藏表（user_id、seed_id、create_time），前台加一个收藏按钮，点击后异步请求。这个功能老少通吃，大多数评委都会认可它的完整性和实用性。

6. 常见坑点与排查技巧实录

写代码时踩过的坑比读书看过的知识点值钱得多。下面这些是我在实际调试SSM种子商店项目时反复遇到、也帮别人排查过的问题，整理成速查表，每个都是真实场景。

6.1 查询结果与页面显示：中文乱码和空数据

中文乱码是SSM项目最普遍的问题。表现有两种：一种是从数据库查出来的中文变成问号或乱码，另一种是页面显示中文正常但写入数据库后又乱码。

排查顺序：第一步检查数据库表字符集是否是utf8mb4，第二步检查jdbc.url是否带了characterEncoding=utf8，第三步检查web.xml的CharacterEncodingFilter是否配置了encoding参数值，第四步检查JSP页面是否在顶部声明了pageEncoding="UTF-8"。这四层任何一环断了都会乱码。

<filter> <filter-name>encodingFilter</filter-name> <filter-class>org.springframework.web.filter.CharacterEncodingFilter</filter-class> <init-param> <param-name>encoding</param-name> <param-value>UTF-8</param-value> </init-param> </filter> <filter-mapping> <filter-name>encodingFilter</filter-name> <url-pattern>/*</url-pattern> </filter-mapping>

空数据问题排查思路：前端列表页面没有数据，先SQL控制台直接执行Mapper中对应的语句看是否有结果，如果有，再看页面遍历时拿到的字段名和实体类getter是否对应。很多MyBatis查询结果字段为null，是因为数据库列名create_time与实体字段createTime没做驼峰映射，需要在MyBatis配置中开启：

<settings> <setting name="mapUnderscoreToCamelCase" value="true"/> </settings>

6.2 前端交互问题：路径、请求与异步

页面404或资源加载失败，最高频的原因是路径写错。SSM项目页面里引用CSS和JS，必须加上上下文路径前缀。例如：

<link rel="stylesheet" href="${pageContext.request.contextPath}/static/css/style.css">

只要少写这个前缀，部署到Tomcat后所有静态资源都会404。这个坑几乎每个SSM新手都会踩一次。

Ajax请求返回JSON数据，也是容易出问题的点。如果项目用的是SpringMVC并配置了Jackson，那么在pom.xml中加入jackson-databind依赖，然后方法上标注@ResponseBody即可自动序列化。但如果返回的数据里有Date类型字段，前端接收到的可能是时间戳而不是格式化好的字符串，需要在Date上配置@JsonFormat(pattern = "yyyy-MM-dd HH:mm:ss", timezone = "GMT+8")注解来格式化。

6.3 事务回滚不生效与脏数据问题排查

前面提到过事务回滚失效的坑，实际排查时可以这样验证：在Service方法中模拟一个抛出异常的步骤（比如在插入订单明细后int i = 1 / 0），然后执行下单操作，看订单主表是否存在记录。如果订单记录已插入但明细没有插入，说明事务没有生效。排除原因的顺序：第一步检查Service类上面是否加了@Transactional注解，第二步检查Spring配置文件是否引入<tx:annotation-driven/>，第三步检查rollbackFor是否设置正确。SpringBoot项目中事务很好用，但SSM中注解驱动必须手动开启，漏配是常见现象。

脏数据要重点检查订单创建时的幂等性。用户在前台页面连续点击“提交订单”两次，如果没有做防重措施，会生成两条相同的订单。在页面端可以提交后禁用按钮，后端则可以检查Session中是否存在一个“正在创建订单”的标志位，或者生成一个一次性token在提交时校验。

6.4 部署上线前后容易忽略的配置

本地运行好好的项目，部署到服务器上就出问题，原因大概率出在配置上。部署前检查三件事：数据库密码是否改成了服务器的密码、Tomcat的server.xml中的端口和上下文路径是否配置正确、图片上传目录在服务器上是否有写权限。

Linux服务器上目录权限问题尤为隐蔽，即使代码完全正确，图片上传会一直报IO异常，检查/usr/local/tomcat/webapps/ROOT/static/upload的目录权限是否为当前用户可写即可解决。

7. 从毕设项目到工作级项目的三个升级方向

种子商店网站做出来，如果只把它当成完成答辩的任务，价值就打折扣了。这套代码其实是个极好的起点，往三个方向延伸，能力会有质的提升。

第一个方向是技术栈升级。把SSM改造成Spring Boot + MyBatis-Plus架构，你会发现原有的Controller、Service、Mapper逻辑大部分能复用，变的只是配置层面。再用Spring Security或Sa-Token替换自己写的拦截器，用Redis存储Session和购物车，用Vue + Element UI重写后台管理页面。改造完成后，你写简历时就可以理直气壮地写“熟悉Spring Boot生态和前后端分离开发”。

第二个方向是业务深化。种子商店的完整模式远不止商品下单这么简单，还可以加会员积分体系、拼团/秒杀活动、优惠券系统、物流跟踪对接。挑选其中一个做深度扩展，都能成为简历上的独立项目亮点。比如做优惠券系统，就涉及券模板设计、领取限制、使用条件校验、分布式锁防超领，这比单纯增删改查的含金量高很多。

第三个方向是工程化完善。给项目补充单元测试（JUnit + Mockito）、增加日志框架（Logback + SLF4J）、引入CI/CD自动构建流程（Jenkins或GitHub Actions）、使用Docker容器化部署，这些工程化能力是校招和社招面试中经常被问到的重点。

我在实际操作中的体会是：一个项目能长期保值，靠的不是代码本身多惊艳，而是你对它的掌握深度。如果种子商店的每一张表、每一个接口、每一个配置文件的来龙去脉你都能讲清楚，这个项目就在你的能力体系里扎下了根，后续不管技术栈如何演变，你都能守住那个不变的内核。

最后分享一个小技巧。分组开发或交付项目时，建议额外维护一份README，把项目的开发环境、运行步骤、管理员账号、常见问题四块内容随时更新。这份文档既是给别人看的交付说明，也是你调试运行时的操作手册，实际上比任何口述讲解都节省沟通成本。