企业官网建设流程全解析

做SSM电商平台这个项目，其实是一个很“酸爽”的过程。说它酸爽，是因为SSM这套组合——Spring + Spring MVC + MyBatis——在当下微服务满天飞的环境里，确实显得有点“复古”，但它依然是大量中小型项目、课程设计、毕业设计和公司内部系统的绝对主力。你只要打开招聘网站看Java岗位要求，SSM依然是出现频率极高的词汇。所以不管是为了应付项目需求，还是为了打牢基础，把SSM电商平台从零到一完整撸一遍，都特别值。

这篇文章我结合自己做过的几个电商类项目，把整个“基于SSM的电子商务平台”从框架选型、数据库设计、核心模块实现到常见坑位排查，完整拆开揉碎讲一遍。全程干货，没有废话，适合刚学完Java Web想练手的人，也适合已经在做项目但被各种细节卡住的朋友。你看完不仅能跑起来一个商城，而且能明白每一步为什么这么做，遇到报错也知道去哪里查。

1. 项目整体设计与框架选型思路

1.1 为什么还用SSM，不直接用Spring Boot？

很多人一上来就问：都2025年了，新项目谁还用SSM？这个问题的答案其实很现实。第一，大量存量系统的技术栈就是SSM，你进去不是写新代码，而是维护和迭代，不会SSM寸步难行；第二，SSM本身就相当于Spring Boot的“底层源码版”，你用Spring Boot时那些自动配置、约定大于配置，其实底层都是Spring和MyBatis在干活。你把SSM搞透了，再去看Spring Boot的自动装配，就是降维打击。

还有一个很实际的原因：很多学校的课程设计和毕业设计，题目明确要求“基于SSM框架”。这时候你用Spring Boot，即便功能做得再好，也可能因为“不符合题目要求”被打回。我在带新人的时候经常说一句话：框架只是工具，电商平台的业务逻辑和数据库设计才是真正值钱的东西。SSM刚好让你被迫去手写配置、理解Bean生命周期、理解事务传播行为，这个过程对于提升内功非常有帮助。

1.2 电商平台的核心模块怎么拆？

一个标准的SSM电商平台，按功能域拆解，至少有这几大块：

• 用户模块：注册、登录、个人信息维护、收货地址管理。
• 商品模块：商品分类、商品列表、商品详情、商品搜索。
• 购物车模块：加入购物车、修改数量、删除、清空、结算。
• 订单模块：订单确认、订单生成、订单列表、订单状态流转。
• 支付模块：对接第三方支付，或者用模拟支付。
• 后台管理模块：商品上下架、分类管理、订单处理、用户管理。

初次做项目的人最容易犯的错误是一上来就写代码。正确的姿势是先画用例图、理清角色，再设计数据库表结构。我的习惯是：先用Excel把每个模块的字段、接口、页面路径列出来，确认没有遗漏后再动手。这个过程看起来很“慢”，其实是最省时间的。因为电商项目最大的成本在改表、改接口、改页面之间的连锁反应上，前期设计多花一天，后期能省一周。

1.3 数据库表结构设计的几个关键点

电商平台的数据库设计，核心表有这几张：用户表、分类表、商品表、购物车表、订单表、订单项表、收货地址表。这里有几个我实际踩过坑后的经验总结。

第一，金额字段一律用decimal，不要用float或double。float和double是浮点数，存在精度丢失问题，你存99.9读出来可能是99.899999。在支付领域这是大忌。decimal(10,2)表示最长10位、小数2位的金额，必须作为铁律。

第二，商品图片不要直接存图片本身，存URL路径。有些新手会把图片转成Base64塞进数据库，这是灾难性的。一方面数据库会变得巨大，另一方面页面加载会非常慢。正确做法是图片上传到服务器某个目录，或者对象存储，数据库只存路径。

第三，订单表和订单项表必须分开。订单表存一次下单的整体信息（订单号、总金额、下单时间、状态），订单项表存每一件商品的信息（商品ID、商品快照名称、购买数量、单价）。为什么要存快照？因为商品名称和价格是会变的，如果你不存快照，一个月后买家说“我买的明明是99元”，你一看商品表已经改成199元，就说不清楚了。所以订单项的“商品名称”和“成交单价”必须冗余存储，这叫业务快照，是电商设计的底线逻辑。

第四，购物车表设计要冗余用户ID和商品ID，并且加上唯一约束。同一个用户同一件商品只能有一条购物车记录，否则用户买3件同样的商品，购物车里会出3行，体验非常糟糕。这个唯一约束在数据库层面加，比在业务代码里判断可靠得多。

2. SSM框架核心配置与常用注解详解

2.1 Spring容器配置的三种方式，你该选哪种？

SSM的Spring配置，网上资料特别乱，有纯XML的、有半注解半XML的、还有全注解的。我的建议是：用XML配置数据源和事务，用注解管理Bean和事务边界。这个方案最稳，也最容易排查问题。

理由很简单。数据源、SqlSessionFactory这几个东西是基础设施，用XML写死，启动时一眼就能看明白连的是什么库、扫描的包是哪个；而Service、Controller这些业务组件，用注解@Component、@Service、@Controller标记，配合@ComponentScan自动扫描，代码量少、可读性高。

核心配置我贴一下，这是稳定运行过的方案：

<!-- spring-context.xml --> <context:component-scan base-package="com.mall"> <!-- 排除Controller，Controller交给SpringMVC容器管理 --> <context:exclude-filter type="annotation" expression="org.springframework.stereotype.Controller"/> </context:component-scan> <context:property-placeholder location="classpath:jdbc.properties"/> <bean id="dataSource" class="com.alibaba.druid.pool.DruidDataSource"> <property name="driverClassName" value="${jdbc.driver}"/> <property name="url" value="${jdbc.url}"/> <property name="username" value="${jdbc.username}"/> <property name="password" value="${jdbc.password}"/> </bean> <bean id="sqlSessionFactory" class="org.mybatis.spring.SqlSessionFactoryBean"> <property name="dataSource" ref="dataSource"/> <property name="mapperLocations" value="classpath:mapper/*.xml"/> <property name="typeAliasesPackage" value="com.mall.entity"/> </bean> <bean class="org.mybatis.spring.mapper.MapperScannerConfigurer"> <property name="basePackage" value="com.mall.mapper"/> <property name="sqlSessionFactoryBeanName" value="sqlSessionFactory"/> </bean> <bean id="transactionManager" class="org.springframework.jdbc.datasource.DataSourceTransactionManager"> <property name="dataSource" ref="dataSource"/> </bean> <tx:annotation-driven transaction-manager="transactionManager"/>

这里有一个非常关键的细节：MapperScannerConfigurer的sqlSessionFactory属性，我特意用了sqlSessionFactoryBeanName。如果直接写sqlSessionFactory且值是ref引用，在某种初始化顺序下会提前触发SqlSessionFactory的创建，导致MyBatis配置还没完全加载就报错。用BeanName的方式传字符串，能绕开这个隐性问题。这种坑属于“配置半天查不出来”，写出来希望你们少走弯路。

2.2 Spring MVC的请求流转与常用注解实战

Spring MVC的请求处理流程可以用一句话概括：请求先到DispatcherServlet，DispatcherServlet根据HandlerMapping找到对应的Controller方法，执行完后将返回值交给ViewResolver渲染视图。

实际操作中，你必须配置好DispatcherServlet的URL映射。最常见的是用/，这样RESTful风格的URL才能生效。如果配成*.do，那所有请求URL后面都得带.do，又丑又落后。我用/的配置方式：

<!-- web.xml --> <servlet> <servlet-name>springmvc</servlet-name> <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class> <init-param> <param-name>contextConfigLocation</param-name> <param-value>classpath:spring-mvc.xml</param-value> </init-param> <load-on-startup>1</load-on-startup> </servlet> <servlet-mapping> <servlet-name>springmvc</servlet-name> <url-pattern>/</url-pattern> </servlet-mapping>

Spring MVC的注解里，业务上用得最多的就是这几个：

• @Controller：标记控制器类。
• @RequestMapping：映射URL，可加method限制请求类型。
• @RequestParam：接收请求参数，可设置是否必传、默认值。
• @PathVariable：从URL路径中取参数值。
• @ResponseBody：返回JSON数据，配合Jackson使用。
• @RequestBody：接收前端传来的JSON，自动绑定到Java对象。

@Controller @RequestMapping("/cart") public class CartController { @Autowired private CartService cartService; @RequestMapping(value = "/add", method = RequestMethod.POST) @ResponseBody public Result add(@RequestBody CartAddParam param, HttpSession session) { User user = (User) session.getAttribute("loginUser"); if (user == null) { return Result.error("请先登录"); } cartService.addToCart(user.getId(), param.getProductId(), param.getQuantity()); return Result.success(); } }

这里有个容易踩的坑：如果用HttpSession获取当前登录用户，一定先判空。不然用户未登录直接操作购物车，代码直接抛NullPointerException，前端提示就变成“服务器异常”。一个完备的系统里，这种场景应该用拦截器统一处理未登录状态，或者至少返回一个明确的错误码。

2.3 MyBatis映射文件与动态SQL的实用写法

MyBatis最强大的地方是动态SQL。电商平台里商品列表的搜索和筛选条件是不固定的——可能按分类查，可能按关键字查，也可能同时按价格区间和销量排序。如果每个条件写一个SQL，那组合数是爆炸的。用MyBatis的<where>和<if>标签就能优雅解决。

<select id="searchProducts" parameterType="map" resultType="Product"> SELECT * FROM t_product <where> <if test="categoryId != null"> AND category_id = #{categoryId} </if> <if test="keyword != null and keyword != ''"> AND name LIKE CONCAT('%', #{keyword}, '%') </if> <if test="minPrice != null"> AND price &gt;= #{minPrice} </if> <if test="maxPrice != null"> AND price &lt;= #{maxPrice} </if> </where> <if test="orderBy != null"> ORDER BY price ${orderBy} </if> </select>

写MyBatis映射文件，有几点经验分享。

第一，慎用${}。${}是字符串拼接，存在SQL注入风险；#{}是预编译占位符，安全。只有排序字段名这种没法预编译的场景才用${}，而且必须白名单校验。比如orderBy前端只能传asc或desc，在Java代码里已经校验过，才拼进来。

第二，批量插入要利用foreach标签。订单生成时要插入订单项，一单可能有多个商品。如果写循环一条条插入，会产生多次数据库往返，性能极差。用foreach一次性批量插入，效率提升明显。

<insert id="batchInsertOrderItems"> INSERT INTO t_order_item (order_id, product_id, product_name, product_price, quantity) VALUES <foreach collection="list" item="item" separator=","> (#{item.orderId}, #{item.productId}, #{item.productName}, #{item.productPrice}, #{item.quantity}) </foreach> </insert>

第三，实体类属性和表字段的映射一定要确认好。如果开启了下划线转驼峰（mapUnderscoreToCamelCase=true），那user_name字段会自动映射到userName属性，很省事。如果没开启，就得手动写resultMap。我建议在SqlSessionFactoryBean里加上这个配置：

<property name="configurationProperties"> <map> <entry key="mapUnderscoreToCamelCase" value="true"/> </map> </property>

3. 核心业务模块的实现要点

3.1 用户注册与登录的安全处理

注册和登录是电商平台的入口，安全要求最高。

先说注册。用户的密码绝对不能明文存储。我用的是BCrypt加密，这是目前比较推荐的密码散列算法。它自带盐值，每次加密同一个密码结果都不一样，但验证时又能正确比对，而且计算速度慢，能有效对抗暴力破解。

@Service public class UserServiceImpl implements UserService { @Autowired private UserMapper userMapper; @Override public boolean register(User user) { // 1. 检查用户名是否已存在 int count = userMapper.countByUsername(user.getUsername()); if (count > 0) { throw new BizException("用户名已存在"); } // 2. 密码加密存储 user.setPassword(BCrypt.hashpw(user.getPassword(), BCrypt.gensalt())); // 3. 插入用户记录 return userMapper.insert(user) > 0; } }

再说登录。用户输入用户名和密码后，业务层把查出来的用户密码和输入的明文密码用BCrypt.checkpw比对。比对成功，就把用户对象存入Session。这里要提醒一下：存入Session前，一定把密码字段置空，否则保存了一个带着加密密码的完整对象，万一被反序列化泄露出去，就得不偿失了。

3.2 商品列表的分页与搜索设计

商品列表页看起来简单，实际上分页查询是性能敏感点。用户量一上来，全表查询和一次性加载所有数据都是不可接受的。我用的方案是PageHelper这个分页插件，基于MyBatis拦截器实现，用起来极其简单：

PageHelper.startPage(pageNum, pageSize); List<Product> productList = productMapper.selectByCondition(condition); PageInfo<Product> pageInfo = new PageInfo<>(productList);

PageHelper.startPage后面执行的第一条SQL会被拦截并自动加上LIMIT语句。这里有一个隐性问题：如果你在startPage和SQL执行之间又做了别的数据库操作，分页就会作用到错误的SQL上。所以PageHelper一定要紧贴着Mapper方法调用，中间不要插入任何其他逻辑。这个坑我至少见过三次，每次都是bing搜索半天才恍然大误。

搜索结果的关键字搜索，用LIKE模糊查询时要注意通配符。用户输入了%或_会破坏查询语义，应该在Java层做转义，把%替换成\%，_替换成\_，并把语句改为LIKE CONCAT('%', #{keyword}, '%') ESCAPE '\\'。

3.3 购物车与订单的下单事务处理

购物车模块和订单模块是联动的，这里最核心的是“下单操作必须保证事务一致性”。

一个完整的下单流程是：

1. 从购物车勾选出要结算的商品。
2. 校验商品是否上架、库存是否充足。
3. 计算订单总金额。
4. 生成订单主记录，状态为“待付款”。
5. 批量生成订单项。
6. 扣减商品库存。
7. 清空购物车中对应的商品。

第4到第7步，任何一步失败，前面的操作都不能生效。比如扣库存失败了，订单不能留在库里；生成订单项失败，库存不能白扣。这就必须在一个数据库事务里完成。

@Transactional(rollbackFor = Exception.class) public Long createOrder(Long userId, List<CartItem> items, Long addressId) { // 1. 创建订单主记录 Order order = new Order(); order.setOrderNo(generateOrderNo()); order.setUserId(userId); order.setStatus(OrderStatus.PENDING_PAYMENT); order.setCreateTime(new Date()); orderMapper.insert(order); // 2. 批量插入订单项 List<OrderItem> orderItems = buildOrderItems(order.getId(), items); orderItemMapper.batchInsert(orderItems); // 3. 扣减库存 for (OrderItem item : orderItems) { int rows = productMapper.reduceStock(item.getProductId(), item.getQuantity()); if (rows == 0) { throw new BizException("商品库存不足，下单失败"); } } // 4. 清空购物车对应商品 cartMapper.deleteByUserAndProductIds(userId, items.stream().map(CartItem::getProductId).collect(Collectors.toList())); return order.getId(); }

@Transactional注解有几个细节必须注意。第一，rollbackFor要设置为Exception.class，默认情况下RuntimeException才触发回滚，受检异常不会。第二，事务只对通过Spring代理调用的方法生效，同类内部调用this.createOrder()事务会失效。第三，事务方法必须是public的，private方法不代理，这个在开发时容易被忽略。

扣减库存的SQL也有讲究。不能先查库存再判断够不够、然后update，因为并发场景下两个线程同时查到库存为1，都判断够，都执行update，就会超卖。必须用一条带条件的update原子操作：

@Update("UPDATE t_product SET stock = stock - #{quantity} WHERE id = #{productId} AND stock >= #{quantity}") int reduceStock(@Param("productId") Long productId, @Param("quantity") Integer quantity);

受影响行数为0则说明库存不足。这是高并发下防止超卖的最基础手段，也是面试常考的考点。

3.4 订单状态机与模拟支付

订单状态的流转，我强烈建议设计成一个清晰的状态机，而不是在业务代码里随意if else改状态。电商平台的订单状态至少包括：待付款、已付款/待发货、已发货、已完成、已取消。

PENDING_PAYMENT -> PAID -> SHIPPED -> COMPLETED PENDING_PAYMENT -> CANCELLED PAID -> CANCELLED (退款场景，这里简化为取消)

后端只用定义好状态的枚举，在处理每个动作的方法里校验当前状态是否符合预期。比如“发货”这个动作，只有当前状态是PAID才能变为SHIPPED；如果状态是COMPLETED还执行发货，就要抛异常。这能防止脏数据出现。

支付模块对接真实支付通道需要商户资质，所以项目里通常做模拟支付。最简单的方式是：创建一个支付页面，点“确认支付”，直接调订单服务把状态从待付款更新为已付款。如果你想更逼真一点，可以加一个支付单表，记录支付方式、支付金额、支付时间、支付流水号，再异步回调订单服务更新状态。这样练手的效果更好，简历上也更有讲头。

4. 常见问题与排查技巧实录

4.1 NoSuchBeanDefinitionException和Bean类型冲突

这是SSM项目里出现频率最高的异常之一。NoSuchBeanDefinitionException的意思是Spring容器里没找到某个Bean。常见原因有三个：

• 扫描包路径写错，导致Controller/Service没被扫描到。
• 类上忘加@Controller或@Service注解。
• 我在前面提到的XML和注解扫描配置互相冲突，比如Spring容器扫描了Controller，导致部分依赖初始化顺序错乱。

排查方法很简单：在web.xml里设置日志级别为DEBUG，启动时看Spring到底扫描了哪些包、注册了哪些Bean。重点看MappedInterceptor和RequestMappingHandlerMapping的日志输出。如果发现工具类里的Bean由于类型相同出现冲突，用@Qualifier指定Bean名称，或者用@Primary标记首选Bean。

4.2 MyBatis的Invalid bound statement (not found)

这个错误真是让人头皮发麻。意思是Mapper接口的方法找不到对应的SQL语句。排查路径是：

1. 确认mapperLocations指定的路径和实际存放Mapper XML的目录一致，注意classpath:mapper/*.xml里的*是否能匹配到你的子目录层级。
2. 确认Mapper XML里的namespace和接口的全限定名完全一致，一个字符都不能差。
3. 确认XML里每个statement的id和接口方法名一致。
4. 确认接口方法参数和XML里的参数类型匹配。

我遇到过最诡异的一种情况：XML文件里的SQL完全没问题，但就是报not found，最后发现是Maven构建时没把mapper目录下的XML文件打包进classes目录。因为Maven默认只打包Java源文件，XML如果放在src/main/java下就会被遗漏。解决方案是在pom.xml里加资源过滤，或者老实把XML放在src/main/resources里。

4.3 Jackson转换JSON报错和日期格式问题

前端用Ajax请求后端接口，@ResponseBody返回对象时，如果对象里有日期字段，默认会序列化成时间戳数字，看起来很不友好。解决方案是配置Jackson的日期格式：

<mvc:annotation-driven> <mvc:message-converters> <bean class="org.springframework.http.converter.json.Jackson2ObjectMapperFactoryBean"> <property name="dateFormat"> <bean class="java.text.SimpleDateFormat"> <constructor-arg value="yyyy-MM-dd HH:mm:ss"/> </bean> </property> </bean> </mvc:message-converters> </mvc:annotation-driven>

如果你用了@JsonFormat(pattern = "yyyy-MM-dd HH:mm:ss")注解在实体类字段上，效果也是一样的，二选一即可。

4.4 上传图片失败和Tomcat临时目录权限问题

商品后台要上传图片。很多人在本地IDE跑得好好的，部署到Linux服务器就上传失败，报错是java.io.IOException: Failed to delete临时文件。这是因为Tomcat的work目录对当前用户没有写权限，或者磁盘满了。排查时先df -h看磁盘，再看Tomcat目录属主，chown -R给权限。另外图片上传接口一定要限制文件大小和类型，避免有人上传恶意脚本文件。我习惯在后端至少校验扩展名，并做二次随机命名，不沿用用户上传的原始文件名。

5. 性能优化与部署经验

5.1 数据库连接池和慢SQL优化

电商平台性能瓶颈几乎都在数据库。我用的是Druid连接池，它自带监控页面，可以实时看慢SQL、活跃连接数、执行次数。在你的项目里接入Druid非常简单，只需在web.xml配置一个StatViewServlet，然后在浏览器访问/druid/index.html就能看到监控面板。

慢SQL出现最多的场景是商品搜索的LIKE查询。如果商品数据量到了几十万条，LIKE '%关键词%'的前缀模糊查询是走不了索引的，全表扫描非常慢。这时候要么用全文检索方案（比如ElasticSearch，但会引入复杂度）；要么退一步，用商品分类+热门关键词做缓存。对练手项目来说，先把数据库索引建好，是最务实的优化：

ALTER TABLE t_product ADD INDEX idx_category_id (category_id); ALTER TABLE t_product ADD INDEX idx_price (price);

只给查询条件里最常用的字段建索引，别给每个字段都建，索引有维护成本，写多读少的表索引多了反而拖慢插入速度。

5.2 商品详情页的缓存设计

商品详情页是读多写少的典型场景。同一个商品，用户可能短时间反复查看，但商品信息一两周才改一次。这种情况非常适合加缓存。轻量级方案是直接用Redis，缓存的key设计成product:详情:{productId}，首次访问从数据库加载，之后走缓存。商品编辑后主动删掉缓存，下次访问再重新加载。

加了缓存之后要留意一个问题：缓存穿透。如果用户恶搞，不断请求不存在的商品ID，每次都会穿透到数据库。解决办法是在缓存里存一个空值，或者用布隆过滤器。对练手项目来说，存空值就够。这是面试提到的加分项，项目中实打实做了，一定会让简历更有分量。

5.3 项目部署到服务器的最小可行方案

SSM项目打war包部署到Tomcat，是最传统的方案。流程就是：

1. Maven执行package，生成war包。
2. 把war复制到Tomcat的webapps目录。
3. 启动Tomcat，它会自动解压war包。
4. 修改数据库连接配置，指向线上数据库。

这里有一个特别容易忽视的问题：本地jdbc.properties里数据库地址往往写的是localhost，部署到服务器就连接失败。我建议在资源目录里维护多份配置文件，比如jdbc.properties和jdbc-prod.properties，打包的时候用profile切换。或者在部署文档里明确醒目标注，每次部署前检查数据库连接。我甚至见过同事把生产库密码提交到git仓库的，安全意识和环境隔离这件事，再怎么强调都不过分。

5.4 会话共享与登录状态

如果你的项目部署在单台Tomcat上，Session直接存内存没问题。但如果你想后续做负载均衡——多台Tomcat通过Nginx分发请求——那Session就有问题了：用户第一次请求落在TomcatA，下一次请求被分到TomcatB，B上没有用户的Session，用户就被踢下线。这就是分布式会话的经典痛点。

最常间的解决方案是把Session存储从内存搬到Redis。Spring提供了HttpSessionStrategy方案，也可以在web.xml里配置Spring Session的过滤器，结合Redis存储Session。具体配置稍微繁琐，但思路很清晰：Session序列化后存入Redis，多台服务器共享同一个Redis来读Session。这样数据库层面也顺便解决了——购物车、登录态都不依赖单台机器的内存，水平扩展才真正可行。

6. SSM项目后续扩展的方向

项目做完，运行稳定了，别急着交差。我建议你至少做三件事来提升这个项目的含金量。

第一，接入Redis缓存商品详情和Session共享。这样项目从单机变成了初步支持分布式会话，简历上可以理直气壮写“使用Redis解决了高并发下商品详情页的访问压力以及多节点下Session共享问题”。

第二，引入消息队列削峰填谷。下单接口如果瞬时请求量特别大，数据库会被打垮。可以在用户点击下单后先把请求丢进MQ，后端异步消费处理订单和扣库存。这个改造听起来复杂，但实际用RabbitMQ的简单队列就能实现，又能学到异步解耦的思想。

第三，把接口改成RESTful风格并加统一返回体。目前很多SSM项目接口返回的格式五花八门，有的返回String视图，有的返回JSON。统一改造为Result<T>结构：code、message、data三要素。前后端联调会非常舒服，也为未来前后端分离打基础。

我个人的体会是，把一个SSM电商项目从头到尾完整做一遍，胜过零散敲十个小demo。你在这个过程中踩过的每一个坑——Bean找不到、事务没生效、库存超卖、JSON格式不对——都是最有价值的经验。这些坑在Spring Boot时代依然存在，只是换了层皮而已。基础打得越牢，以后学什么框架都快。如果你正卡在某个报错上排查不出来，把日志发到社区提问时，记得附上完整的堆栈信息和配置片段，这样别人才能帮你定位。希望这篇文章能让你少走点弯路。