企业官网建设流程全解析

1. 这个项目到底在解决什么问题：需求拆解比写代码更重要

做二手物品交易网站，听起来是个老掉牙的课题——凡是学Java Web的人，十有八九都做过或者见过类似的东西。但我盯上这个项目，恰恰是因为它“老”，老到很多人根本不重视它背后的逻辑，上来就建表、写Controller、套个前端模板，最后做出来的东西看起来五脏俱全，实际上一推敲就露馅。

先把这个系统的核心需求看清楚。二手交易和普通商城最大的区别在于：商品的发布者是C端用户，不是运营人员。这就带来三个连锁问题。

第一，商品数据是高度异构的。一个卖二手手机的人想填“电池健康度”，一个卖二手书的人想填“几成新”，你不可能像京东自营那样为每个品类设计一套标准属性。所以数据模型不能一上来就按“商品+固定字段”设计，得考虑动态属性怎么存、怎么查。

第二，交易信任成本高。买卖双方都是普通用户，平台要管的不只是“商品有没有上架”，还有交易状态怎么流转——从发布、被下单、买家确认、到订单完成，每一步都可能出现“拍了不付款”“发货不确认”的情况。状态机设计是这个系统的隐藏核心。

第三，搜索和筛选的逻辑比想象中复杂。二手商品的标题是用户自己写的，乱七八糟什么风格都有，你不能指望数据库LIKE一把梭就能让用户满意。价格区间、成色筛选、地域偏好，这些条件组合起来怎么走索引，是个很现实的性能问题。

我见过太多同类项目把精力花在了“界面好看”上，用了各种花里胡哨的Bootstrap模板、Vue组件，结果连最基本的“同一件商品被两个人同时下单”这种并发问题都没处理。这篇文章我打算把SSM这套经典组合怎么落地这些需求讲清楚，重点不在于给你贴几百行代码，而在于把“为什么这么设计”说明白，你能拿去应对课程设计、毕业设计，也能在面试时把项目讲出层次。

2. SSM选型不是“老古董”：这套组合在今天依然有它的合理位置

我在项目里选择SSM，不是因为Spring Boot不好，而是因为在这个场景下，SSM反而能把“框架是怎么工作的”展示得更透明。很多初学者用Spring Boot，写了一年代码可能都没搞清楚DispatcherServlet到底做了什么，因为内嵌Tomcat和自动配置把一切都抹平了。

SSM三个组件各自负责的事情分得很清楚：

• Spring管对象。Service层的类、DAO层的Mapper，这些Bean的生命周期、依赖注入，都是Spring容器在管。这也是整个系统能解耦的根基。
• SpringMVC管HTTP。请求从Tomcat进来，DispatcherServlet负责找合适的Controller方法，把参数绑定好，返回视图或JSON数据。这个过程你可以在XML里看到每一个配置项。
• MyBatis管SQL。Mapper接口只定义方法签名，真正的SQL写在XML文件里，动态SQL能根据条件拼出不同的查询语句，非常适合二手商品这种“条件组合多变”的场景。

你可能会说：“这些Spring Boot不也都有吗？”对，都有，但Spring Boot把约定大于配置做到了极致，你只需要引入一个starter，一切都被自动配置好了。而SSM需要你手写web.xml、applicationContext.xml、spring-mvc.xml、mybatis-config.xml，这个写一遍的过程，就是把HTTP请求生命周期、Spring容器初始化顺序、MyBatis会话工厂绑定过程全部过一遍的过程。

举个例子，SpringMVC的DispatcherServlet和Spring的ContextLoaderListener这两个东西，在Spring Boot里你根本不需要碰它们，但在SSM里你必须理解：ContextLoaderListener先初始化根容器，加载Service、Mapper这些业务Bean；DispatcherServlet再初始化自己的子容器，加载Controller。子容器能看到父容器的Bean，反过来不行。这个机制直接决定了你的事务注解应该放在Service层而不是Controller层——因为事务管理器通常在根容器里，Controller在子容器中，如果事务加在Controller上，增强逻辑可能压根没被事务管理器处理。

还有一点是MyBatis和Spring的整合方式。很多人用MyBatis的时候，习惯于直接用SqlSessionFactoryBuilder去构建会话，但在SSM里，你需要借助MyBatis-Spring这个桥接包，让SqlSessionFactory交给Spring容器管理，并且通过MapperFactoryBean把Mapper接口动态代理成Bean。这个过程中，Mapper接口没有实现类，只有XML里的SQL，Spring是怎么把它变成可注入的对象的？靠的就是JDK动态代理——启动时扫描Mapper接口，为每个接口生成代理对象，方法调用时根据全限定名去找XML里的statement。理解了这一层，以后你看到“Mapper标了@Autowired但报NoSuchBeanDefinitionException”这类问题，才不至于两眼一抹黑。

3. 数据模型设计：二手商品表的坑与解法

数据模型是整个系统的地基，这段我踩过很多次坑，值得单独拿出来说。

3.1 商品主信息表：不可变字段抽出来

先从最核心的product表说起。我当时的设计是把“所有商品都有的信息”放进主表，主要包括：

• product_id，主键
• user_id，发布者ID
• title，标题，用户自定义，varchar，长度给到120
• description，描述，text类型
• price，decimal(10,2)，精确到分
• original_price，可选，decimal(10,2)
• category_id，分类ID
• status，上架状态/交易状态，tinyint
• view_count，浏览次数，int，默认0
• created_time，updated_time
• province，city，区域ID，用于地区筛选

这个表设计本身不难，难的是字段取舍。比如original_price，很多二手平台的表单里是选填项，那数据库里就允许NULL，查询的时候要用IFNULL做兜底。再比如status字段，我想特别强调一下——不少人喜欢给状态存字符串，比如“on_sale”“sold_out”“pending”，这非常坑。字符串的比对效率低，数据校验不严格，而且状态流转写起来很容易出错。更好的做法是用tinyint存数字枚举，比如0表示已下架、1表示在售、2表示已被下单锁定、3表示交易完成。代码里写常量类或者枚举去对应，数据库里只存数字。

为什么要有“已被下单锁定”这个状态？这是二手交易特有的问题。平台必须保证同一件商品同一时间只被一个买家下单。如果不加锁定状态，A买家下单后还没付款，B买家又下单了，最后就乱套。处理方式是：在买家提交订单接口里，用一个条件更新SQL——UPDATE product SET status = 2 WHERE product_id = ? AND status = 1。受影响行数为1说明抢锁成功，为0说明商品已经不是可售状态。这个通过“乐观锁”思路完成状态流转的方案，比先SELECT再UPDATE的方式安全得多。

3.2 动态属性：扩展表比JSON字段在SSM中更顺手

商品动态属性怎么存？同类项目里有拍脑袋用JSON字段的——直接在product表加一个attributes字段，把各种属性塞进一个JSON字符串里。但SSM项目有个特殊性：MyBatis对JSON的支持远没有JPA那么便捷，你要么用TypeHandler自己去解析，要么在Service层手写序列化和反序列化。这其实还能接受，真正的问题是查询——如果有人要筛选“电池健康度大于90%的手机”，JSON存储会让SQL写到你怀疑人生。

所以我更推荐“主表+扩展属性表”的设计思路。逻辑是这样的：凡是可能被筛选的属性，比如成色、品牌、型号、保修情况，都拆出来做成键值对的形式存一张product_attribute表：

• id，主键
• product_id，商品ID
• attr_name，属性名
• attr_value，属性值

这样有一个好处：属性可以随时扩展，今天来了个卖摩托车的用户要填“行驶里程”，你不需要改表结构，直接存一行数据就行。查询的时候，用GROUP BY product_id配合HAVING COUNT(DISTINCT attr_name)的方式来过滤，逻辑也不复杂。

同时也别把所有东西都往这张表里塞。像“手机品牌”这种使用频率很高的筛选维度，要么在product主表冗余一个字段，要么建单独的索引。实际上，二手交易网站的搜索热点非常集中，品牌、价格区间、地域这三板斧占了绝大多数筛选需求，把高频属性做主表的正式字段，把低频自定义属性放扩展表，是性能和灵活性的最佳平衡点。

3.3 订单表和交易状态机

订单表的核心字段是：order_id、order_no（业务订单号，要唯一且不暴露自增ID）、product_id、seller_id、buyer_id、amount（订单金额，注意下单时就把价格快照存下来，不能去关联商品表的实时价格，否则卖家中途改价会导致纠纷）、status、created_time、pay_time、confirm_time。

订单状态流转是整个系统里最容易出逻辑漏洞的地方。我设计的状态包括：

• 0：待付款
• 1：已付款待发货（或线下交付待确认）
• 2：交易完成
• 3：已取消

每一步转换都必须有对应的条件校验。比如只有状态为0的订单才能取消，只有状态为1且买家确认收货（或者卖家确认收款）后才能变成2。这些状态流转不能散落在Service的各个方法里靠开发者自己记，最好用一组状态机的常量定义，甚至写一个简单的状态机工具类集中管理合法的迁移路径。

还有一个细节：这里的订单和普通电商订单不一样，二手交易大多数是线下见面交易或者第三方平台转账，平台本身不涉及支付渠道对接。所以“支付”这个动作很多时候只是一个标记——买家点“确认付款”，系统把订单状态从0改成1，同时把商品状态锁定。理解了这一点，你会发现这个系统的核心不是支付功能，而是信用标记和流程引导。这也是它在业务上清晰的边界：做一个交易信息撮合平台，而不是做金融系统。

4. 后端分层设计：从Mapper到Controller，每一层到底该写什么

4.1 Mapper层：MyBatis动态SQL处理条件查询

二手商品列表页是一个典型的多条件筛选场景，用户可能选分类、填价格区间、按成色过滤、按地区筛、按时间排序。SQL查询条件不确定，用MyBatis的<where>标签配合<if>标签拼动态SQL是标准解法。

<select id="selectByPage" resultType="map" parameterType="map"> SELECT p.*, u.nickname as seller_name, u.avatar FROM product p LEFT JOIN user u ON p.user_id = u.user_id <where> p.status = 1 <if test="categoryId != null"> AND p.category_id = #{categoryId} </if> <if test="minPrice != null"> AND p.price &gt;= #{minPrice} </if> <if test="maxPrice != null"> AND p.price &lt;= #{maxPrice} </if> <if test="cityId != null"> AND p.city = #{cityId} </if> <if test="keyword != null and keyword != ''"> AND (p.title LIKE CONCAT('%', #{keyword}, '%') OR p.description LIKE CONCAT('%', #{keyword}, '%')) </if> </where> ORDER BY p.created_time DESC LIMIT #{offset}, #{pageSize} </select>

这里有个很直观的性能问题：LIKE查询走不了索引，所以在数据量大之后，这个方案会撑不住。但对于一个课程设计或中小规模的二手交易平台，数据量在万级到十万级左右，全表扫描加优化过的MySQL查询完全能扛住。如果真想优化，方向是全文索引或ES，但那就超出SSM单体应用的范畴了。

很多人的MyBatis动态SQL写出来能跑，但细节经不起推敲。比如参数判断用!= null还是!= ''要分清，价格筛选的边界值用>=还是>导致带上临界值的问题，parameterType="map"时注意键名大小写，以及分页时offset和pageSize的计算方式——页码从1开始的话，offset等于(pageNum-1)*pageSize。

4.2 Service层：事务边界与业务流程编排

Service层是这个系统的灵魂，所有业务规则都应该在这一层落地。让我用发布商品这个最常见的操作来说明。

发布商品的流程包括：写入product主表、写入product_attribute扩展表、给用户发布数加1。这三步必须在一个事务里——主表写进去了，扩展表写失败了，就会产生一个残缺的商品信息。所以@Transactional注解加在Service方法上，而且要注意，默认情况下这个方法必须是public的，并且通过Spring代理调用才有效。

另一个重点是“发布者不能同时是购买者”。你想象一个场景：用户A发布了一个商品，用户B来下单，订单成交通知里要同时带上双方的信息。如果某个用户发布商品后自己又去下单自己的商品，这在业务上是应该被禁止的。校验逻辑很简单，就是对比Product中的user_id和当前登录用户的ID，查出来不一样就抛异常。

Service层还有一个容易被忽略的职责：把Controller传来的DTO转换成数据库实体，或者反过来。比如前端传来一个JSON格式的List，里面是动态属性键值对，Service要负责遍历这些属性，逐个Set到List<ProductAttribute>里，再批量插入。批量插入用MyBatis的foreach循环，一次insert里插入多条，别在for循环里调用单条insert，那是最典型的性能杀手。

4.3 Controller层：参数校验与登录拦截

Controller层的核心原则是薄，越薄越好。它只干三件事：取出Session或Token里的当前用户、把请求参数绑定成对象、调用Service拿到结果后返回统一格式的JSON。

对于“浏览商品”这类接口，用户即使没登录也应该能访问；但对于“下单”“收藏”“发布商品”这类接口，必须要求登录。这个逻辑用SpringMVC的拦截器来实现最合适。

<mvc:interceptors> <mvc:interceptor> <mvc:mapping path="/order/**"/> <mvc:mapping path="/product/publish"/> <mvc:mapping path="/favorite/**"/> <mvc:exclude-mapping path="/order/list"/> <bean class="com.example.interceptor.LoginInterceptor"/> </mvc:interceptor> </mvc:interceptors>

LoginInterceptor里做的事情非常简单：从request的session里取user对象，如果不存在就返回一个状态码为401的JSON。这里有个很重要的细节——拦截器不处理静态资源。你的商品图片如果放在项目内的static目录下，且图片路径是以/productImg/开头的，那一定要在拦截器配置里把静态资源路径排除掉，否则你会看到浏览器里图片资源全部403，排查半天才发现是拦截器把图片请求也拦了。

Controller层的参数校验，我建议不要用JSR-303注解那一套，在SSM老项目里加validation依赖容易和旧版本Tomcat冲突。自己写一个简单的校验工具类，或者在Service入口处做if判断抛自定义异常，效果一样，代码还更直观。比如发布商品的请求里，标题为空、价格小于等于0、description过长，这些在Service入口直接判断并抛出BusinessException，会被全局异常处理器捕获并返回给前端。

5. 从“能用”到“好用”：搜索、排序、图片处理的实用细节

5.1 搜索与排序的策略选择

我在前面提到LIKE查询的局限性，但作为单体SSM项目，这个方案是性价比最高的。如果你想让搜索结果稍微“智能”一点，可以引入一个简单的分词方案，比如把用户输入的关键词按空格切分，每个词都作为一个LIKE条件拼接起来：

String[] words = keyword.trim().split("\\s+"); for (String word : words) { // 每个词都拼一个title LIKE条件 }

这样用户搜“iPhone 12 256G”的时候，会把包含任意一个词的商品都搜出来，比整句匹配效果好很多。

排序方向上，除了默认的发布时间倒序，二手交易平台通常会提供“价格从低到高”“价格从高到低”的排序，以及“最新发布”排序。这个可以在查询参数里加一个sortField和sortOrder，动态拼接ORDER BY子句。这里要防一手SQL注入——不要直接拼接用户参数，排序字段名先映射成白名单，比如sortField等于price时实际拼“p.price”，等于time时拼“p.created_time”，方向只允许asc和desc两个字面量。

5.2 商品图片上传：真实落地的方案

二手商品对图片的依赖非常高，一个商品至少得有三张图。图片上传功能的实现，要考虑三个问题：存哪里、怎么存、怎么访问。

首先，图片不能直接存数据库的BLOB字段，除非你不在乎数据库膨胀到几个G。常规方案是存磁盘路径或云存储。对SSM项目来说，校内部署或小项目部署，把图片存在服务器的一个独立目录（比如/usr/local/upload/），数据库存相对路径，最合适。

SpringMVC里处理上传需要配置CommonsMultipartResolver，注意两个参数：maxUploadSize控制单次上传总大小，defaultEncoding设置UTF-8防止文件名乱码。接收文件的Controller方法参数用MultipartFile，调用transferTo方法直接落盘。

@PostMapping("/product/uploadImage") @ResponseBody public Result uploadImage(@RequestParam("file") MultipartFile file, HttpServletRequest request) { if (file.isEmpty()) { return Result.error("文件不能为空"); } String originalFilename = file.getOriginalFilename(); String ext = originalFilename.substring(originalFilename.lastIndexOf(".")); // 白名单校验扩展名 if (!Arrays.asList(".jpg", ".jpeg", ".png", ".gif", ".webp").contains(ext.toLowerCase())) { return Result.error("不支持的图片格式"); } String newFileName = UUID.randomUUID().toString().replace("-", "") + ext; String filePath = uploadDir + "/" + newFileName; try { file.transferTo(new File(filePath)); String visitPath = "/upload/" + newFileName; return Result.success(visitPath); } catch (IOException e) { return Result.error("图片上传失败"); } }

扩展名白名单校验是必须的，不然用户上传一个.jsp文件放到你的静态目录里，配合某些服务器配置不当的情况，就是一个非常严重的漏洞。真实项目里还应该做内容校验，比如读取文件头判断是不是图片魔数，而不只是信任扩展名。这里我强烈建议至少做到扩展名白名单加UUID重命名，这一步能防住90%的风险。

图片访问路径怎么映射？如果你用的是Tomcat，最简单的方式是配置虚拟目录：在server.xml的Host节点里加一句Context映射，把磁盘路径映射到/upload这个URL前缀。不推荐把图片放到项目内的WebRoot下，因为项目一旦重新部署或clean，图片全没了——这个坑我踩过一次，血的教训。部署在本地测试环境还可以凑合，但凡是正式部署，必须把上传目录和项目目录分离。

5.3 收藏功能的业务细节

收藏是二手交易网站的高频交互功能，看起来简单，实际还是有设计空间的。核心数据表favorite只需要用户ID、商品ID、创建时间三个字段，唯一索引建在(user_id, product_id)上防止重复收藏。

但有几个问题值得注意。一是收藏接口的幂等性——用户连点两次收藏按钮，应该只产生一条记录。实现方式可以是在Service里先查再插，也可以捕获DuplicateKeyException后直接返回成功。二是“收藏列表里的商品下架了怎么办”，界面上应该显示“已失效”状态，这是通过查询时LEFT JOIN product表并判断product是否为空实现的。三是收藏数要不要在商品表加冗余字段，我的建议是加一个favorite_count，发布商品列表和商品详情页都显示这个数字，每次收藏或取消收藏时做增减。这样虽然多了一步数据一致性维护，但换来了列表页不需要COUNT查询的性能优势，值。

6. 并发与安全：这套系统最容易被看轻的两个维度

6.1 超卖问题的本质与解决

虽然二手交易不是高并发场景，但“同一件商品被两个买家同时下单”的问题是真实存在的。我在前面提到了状态字段加条件更新的方案，这里把完整流程展开说一遍。

场景是这样的：买家A和买家B同时看中一个商品，同时点击“立即购买”。如果代码逻辑是先SELECT再INSERT，两个请求都查到了status=1，然后都插入订单，就产生了重复订单。解决方式把状态检查从“应用层校验”下沉到“数据库层面的原子操作”：

UPDATE product SET status = 2 WHERE product_id = #{productId} AND status = 1

执行这条SQL，返回受影响行数。是1，说明抢购锁定成功，继续创建订单；是0，说明商品已经被别人抢走，直接抛“商品已下架或已被购买”异常。

在Service方法上加@Transactional，把UPDATE和INSERT订单包进同一个事务，就能保证锁定商品和创建订单要么都成功，要么都回滚。这里的核心思想是：用数据库行锁替代应用层的同步锁，既简单又可靠。

6.2 用户输入是一等安全威胁

来来来，我把安全问题当成一个重要话题。二手交易系统面向的是全网用户，用户输入就是最大的攻击面。至少要做如下几个事情：

第一，XSS防御。用户在商品标题、描述、留言里输入的<script>标签，如果原样输出到页面上，就可能被执行。防御措施是后台对用户输入做HTML转义，或者前端框架统一做了转义。如果是JSP时代的老项目，可以使用JSTL的<c:out>标签输出，它会自动转义特殊字符。如果是前后端分离用JSON返回数据，Vue或React默认也会转义，问题不大，但要防止用户通过接口直接提交带HTML的字符串，所以在Controller入口统一过滤是个好习惯。

第二，SQL注入防御。MyBatis的#{}方式默认是预编译，已经有效防住了大部分注入。主要的风险点在于ORDER BY这样的位置不能用#{}，只能拼字符串，这就回到了我之前说的“排序字段白名单”思路。还有LIKE查询里要小心拼接%，用CONCAT处理可以保证参数化。

第三，越权访问。这是个容易被忽略的问题。用户A登录后，如果通过改URL的ID去查看、修改、删除不属于自己的数据，就属于越权。处理方式是在Service层对当前登录用户与数据归属进行校验，比如订单只有买家或卖家本人能查看，商品只有发布者本人能编辑。这个校验在Controller和Service都要做，Controller做拦截是为了用户体验，Service做校验才是真正保护数据安全。

6.3 前端接口的幂等处理

用户连续点击两次下单按钮，实际上会发送两个相同的请求。即使后端有商品状态锁，也要考虑接口层的幂等设计。简单做法是下单按钮点击后立即置灰防重复点击，但这只能防君子不能防小人。更稳妥的方式是前端生成一个requestId（UUID），下单接口接收这个参数并且把(userId, requestId)加上唯一约束，重复请求插入失败后捕获异常返回“订单处理中，请勿重复提交”。

这种处理方式在真实项目里很常见，面试聊到并发和幂等的时候也是一个很好的加分点。

7. 实测中最容易翻车的几个细节：SSM配置与部署的避坑记录

7.1 applicationContext.xml和spring-mvc.xml到底各管什么

我在项目刚开始搭建框架时，经常看到有人把所有的Bean都一股脑扫描进spring-mvc.xml里，结果运行时报各种诡异错误。其实这两个配置文件的职责边界非常固定：

• applicationContext.xml（根容器）：扫描@Service、@Repository、@Component，配置数据源、事务管理器、MyBatis的SqlSessionFactory、Mapper接口扫描。这里面的Bean是全局共享的。
• spring-mvc.xml（子容器）：只扫描@Controller，配置注解驱动、视图解析器、静态资源映射、拦截器、文件上传解析器。

如果不小心在spring-mvc.xml里也扫描了@Service，就会导致容器出现同一个Bean的实例——一个在根容器里，一个在子容器里，事务增强的配置会出现混乱，Service方法上@Transactional时好时坏，DAO事务管理失效但你不一定能第一时间看出来。这类问题我遇到过太多次了，建议强制执行“两个配置文件扫描策略边界”：根容器配<context:component-scan base-package="com.example.service"/>这种精确路径，spring-mvc.xml里只配<context:component-scan base-package="com.example.controller"/>。

7.2 MyBatis的Mapper扫描配置

如果SSM整合时遇到Injection of autowired dependencies failed的问题，大概率是Mapper没有被Spring容器管理。目前最稳妥的做法是在applicationContext.xml中配置MapperScannerConfigurer：

<bean class="org.mybatis.spring.mapper.MapperScannerConfigurer"> <property name="basePackage" value="com.example.dao"/> <property name="sqlSessionFactoryBeanName" value="sqlSessionFactory"/> </bean>

它会对basePackage下所有接口生成代理并注册到Spring容器里。注意属性是sqlSessionFactoryBeanName而不是sqlSessionFactory，这是因为MapperScannerConfigurer这个Bean的初始化时机很早，如果用ref属性引用SqlSessionFactory的Bean实例，可能会导致提前初始化依赖的Bean，出现循环依赖问题。用字符串名字延迟查找，能规避这个坑。

7.3 懒加载与JSON序列化的相爱相杀

如果你在商品详情页要展示发布者信息，数据库设计是product表关联user表的seller_id，MyBatis的resultMap里配置了关联查询，并且开启了懒加载。那么当Controller把Product对象转成JSON返回给前端时，序列化器访问product.getUser()，会触发懒加载查询。这本身没问题，但如果懒加载配置或依赖不对，比如mybatis-config.xml里少了<setting name="lazyLoadingEnabled" value="true"/>，或者CGLIB代理不可用，就会出现序列化时抛LazyInitializationException。

一个更稳妥的方案是：如果详情页需要展示的信息本来就固定，直接使用MyBatis的JOIN查询一次性查出所有字段，返回一个Map或自定义VO，不用resultMap的关联映射。少一层懒加载，就少一类问题。

7.4 部署环境下的数据库初始化

最后提一个很实际的部署问题。很多人在本地开发用MySQL 5.7，部署到服务器上的MySQL 8.0，结果项目跑起来各种字符集乱码、排序规则不正确、SQL语法不兼容。建议数据库连接串里从一开始就加上几个核心参数：useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai。前两个保证连接层字符集一致，第三个避免MySQL 8.0默认SSL的手续费，第四个是关键，MySQL 8.0对时间类型的处理发生了变化，不指定时区会导致日期字段读写错乱。

SQL文件写完之后，也建议统一导出和执行。数据库schema建表语句里统一使用utf8mb4字符集和utf8mb4_general_ci排序规则，给所有需要模糊搜索的字段建索引前先想清楚这个表的写入频率，别在大字段上硬建索引。

8. 写在最后：SSM项目做下来最值钱的东西

我反反复复做了好几轮这类二手交易系统，个人体会最深的一点是：真正把这个项目吃透的人，收获的绝不只是几个配置文件怎么写，而是理解了“一个完整应用从用户请求到数据库落盘”的整条链路。

JSP或Thymeleaf页面发出请求，DispatcherServlet匹配Controller方法，Controller调用Service，Service开启事务并操作Mapper，Mapper执行预编译SQL，数据库返回结果，结果再一层层封装回JSON响应给前端——在这个闭环里，每一层都有自己的职责，任何一层越权都会引发连锁问题。这种分层意识，是进入任何Java后端项目最基本的素养。

如果还往前走一步，我可以告诉你哪些地方是下一个阶段的提升方向：比如引入Redis做商品列表页缓存，把热门商品的查询从数据库里解放出来；比如把文件上传改成OSS云存储，解决单机磁盘扩展问题；比如引入MQ做订单超时自动取消，避免用户拍下不付款导致商品一直锁定。但这些都是“从能用走向可用”的优化，不是“从不会走向会”的跨越。

在动手写代码之前，先把商品的交易状态流转、订单的状态机、以及并发下如何锁定商品这三件事想清楚。这三件事想清楚了，项目的地基就稳了，剩下的细节都是按部就班的填充。反而是那些一上来就急着把注册登录页面做出来的人，十个有九个后期都在改表结构改到怀疑人生。

最后分享一个我自己的习惯：每写一个模块之前，先用一两段话把“这个模块要处理哪些输入、哪些输出、有哪些异常分支、状态是怎么流转的”写出来，然后再动手。这样看起来是慢了，但整体下来无论是调试时间还是返工次数都大幅减少。做工程，慢就是快，这四个字在SSM这个“老家伙”身上体现得格外充分。