企业官网建设流程全解析

做SSM项目最怕的不是写代码，而是代码写完了，环境起不来、数据库连不上、部署完一脸懵。最近整理了一套SSM协同购物推荐系统，程序、源码、数据库、调试部署、开发环境一条龙都过了一遍，论文文档也写完了一万多字。这篇文章我不打算念PPT，就把整个项目从设计到落地、从踩坑到排错的过程全部分享出来，尤其把SSM框架的常用注解、数据库设计、协同过滤推荐的核心实现，以及后端同学最容易翻车的部署调试环节讲透，适合正在做JavaWeb课程设计、毕业设计，或者想搞懂SSM全家桶怎么落地的人直接参考。

先说清楚这个项目是干什么的。它本质是一个电商购物推荐系统，用户登录后在商品列表里浏览、购买，系统根据用户的历史行为（浏览、收藏、购买）计算出一个推荐列表，把“你可能还喜欢”的商品推到首页。技术栈用的是SSM，也就是Spring + SpringMVC + MyBatis三个框架的整合，数据库用的MySQL，前端是JSP加Bootstrap这一套经典组合。这个组合放到今天看确实不算新，但它依然是学校课程设计、毕业设计里出现频率最高的一套东西，原因很简单：结构清晰、资料多、招聘市场里存量系统大量还是这套架构，搞懂它一点都不亏。

1. 项目整体拆解：协同购物推荐到底在做什么

1.1 SSM不是三个框架的简单叠加

很多初学者把SSM理解成“Spring管对象、SpringMVC管请求、MyBatis管数据库”，这个说法没错，但太粗糙了。实际项目里它们的协作关系是：浏览器发请求过来，SpringMVC的DispatcherServlet先接住，根据URL映射找到对应的Controller；Controller调Service层处理业务逻辑；Service里通过Mapper接口（MyBatis的代理实现）去操作数据库；整个过程中Controller、Service、Mapper这些对象的创建和依赖注入全是Spring容器在管。

这套项目里我用了Spring 5.x、SpringMVC 5.x、MyBatis 3.5.x的组合。有人会问，为什么不直接用Spring Boot？我的看法是，SSM的手动配置过程本身就是最好的学习素材。你亲手写过web.xml、spring-mvc.xml、spring-mybatis.xml之后，再看Spring Boot里的自动配置，会有一种“原来你帮我干的就是这些活”的通透感。而且很多公司的老项目确实还在用SSM，你能看懂、能维护，这本身就是一种竞争力。

1.2 推荐系统的核心逻辑

协同购物推荐，核心是“协同过滤”的思路，说白了就是：跟你行为相似的人喜欢什么，我就把这些东西推荐给你；或者，你之前喜欢的东西跟哪些东西相似，我就把相似的东西推给你。这个项目里两种思路我都做了，但主力是用户协同过滤。

举个例子。用户A买了《Java编程思想》和《深入理解Java虚拟机》，用户B买了《Java编程思想》和《Spring实战》，系统通过计算发现A和B的行为相似度很高。这时候用户B买了《Redis设计与实现》，但A没买，系统就会把《Redis设计与实现》推荐给A。这就是用户协同过滤最朴素的理解。

真实实现里，相似度计算用到的是余弦相似度，稍微讲究一点的项目还会做皮尔逊相关系数，但课程设计级别用余弦相似度完全够用，而且解释起来非常直观。计算公式不复杂：两个用户的评分向量分别是u和v，余弦相似度就是两个向量的点积除以各自模长的乘积，值越接近1说明越相似。我封装了一个UserCF的工具类，输入是用户对商品的评分集合，输出是每个用户的Top-N推荐商品列表，核心代码一百行出头，逻辑清楚，论文里也好展开写。

2. 核心技术点逐个说透

2.1 SSM常用注解，每个都要知道为什么这么写

这个项目里用得最多的注解就那几个，但如果只是会抄不会讲，面试或者答辩的时候一问就露馅。我这里把每个注解的用途和注意事项一次性说清楚。

@Controller和@RestController的区别是第一个经典问题。这个项目返回的是JSP页面，所以Controller层统一用@Controller，方法上返回的是视图逻辑名，配合InternalResourceViewResolver解析到具体的JSP路径。如果你用@RestController，返回的字符串会被当成JSON响应体，页面就找不到了。

@RequestMapping是路由映射的核心。类上标注的是一级路径，方法上标注的是二级路径，组合起来才是完整的访问URL。比如UserController上标注@RequestMapping("/user")，里面的login方法标注@RequestMapping("/login")，前端访问的就是/user/login。这种设计的好处是同一个模块的接口路径规整好记，权限拦截的时候也可以按一级路径批量处理。

@RequestParam、@PathVariable、@RequestBody这三个是参数接收的三板斧。@RequestParam用于接收表单提交的普通参数，比如?username=admin&password=123，可以设置required=false和defaultValue来处理非必填参数；@PathVariable用于RESTful风格的路径参数，比如/goods/detail/15中的15；@RequestBody用于接收前端传来的JSON数据，配合Jackson或者Fastjson做反序列化。这个项目里表单提交居多，所以@RequestParam用得最多。

@Autowired是依赖注入的注解，默认按类型注入。这里有个坑：如果同类型的Bean有多个，比如两个Service都实现了同一个接口，@Autowired会直接报错或者注入失败。解决办法是配合@Qualifier("beanName")指定具体名字，或者直接把变量名写成Bean的名字。我在项目里就踩过一次，推荐算法写了两个Service实现类，一个基于用户协同过滤，一个基于物品协同过滤，不指定@Qualifier的话启动直接抛"NoUniqueBeanDefinitionException"。这个异常我在文末的排查表里专门列了。

@Transactional是事务控制的关键。购物下单这个操作涉及订单表插入、订单明细表插入、库存扣减、用户积分变更，任何一个环节出错都不能留半截数据。我在Service层的下单方法上直接标了@Transactional，默认遇到RuntimeException就回滚。特别注意一点：事务只对通过Spring代理调用的方法生效。如果同类内部一个方法调另一个方法，是不走代理的，@Transactional就不生效。所以事务方法不能自己调自己，要调用也得通过注入的Bean来调。

2.2 SpringMVC的工作流程，看懂配置文件的每一行

SpringMVC的核心组件是DispatcherServlet，所有请求先到它这里，再由它分发给各个Controller。整个流程是：请求进来，DispatcherServlet找HandlerMapping，根据URL找到对应的Handler（也就是Controller方法）；找到之后，HandlerAdapter负责真正执行这个方法；方法返回的ModelAndView经过ViewResolver解析，渲染成页面返回给浏览器。

这个项目里我在spring-mvc.xml里配置了这么几个关键的东西：组件扫描器扫描Controller包；注解驱动开启，这样@RequestMapping才能生效；内部资源视图解析器配置了前缀/WEB-INF/views/和后缀.jsp。这里有个细节很多人忽略：JSP放在WEB-INF目录下是安全做法，因为浏览器直接访问不到WEB-INF下的文件，所有页面都必须经过Controller转发，既规范了访问入口，也避免了用户绕过登录直接访问页面。但代价就是静态资源（css、js、图片）如果也放在WEB-INF下就会全部被挡住，所以我额外配置了<mvc:resources>把static目录放开，这也是一个很容易被问到细节的点。

拦截器这块，我写了一个LoginInterceptor，实现HandlerInterceptor接口，在preHandle方法里判断session里有没有用户信息，没有就重定向到登录页。拦截器配置的时候要注意excludePathPatterns把登录接口、注册接口、商品列表、商品详情这些不需要登录就能访问的路径放行，否则会出现“登录页面都被拦了，用户永远无法登录”的死循环，这个坑初学的时候几乎人人都踩。

2.3 MyBatis的Mapper开发与SQL编写

MyBatis这块，这个项目用到了最经典的Mapper接口加XML映射文件的组合。Mapper接口只定义方法签名，SQL写在XML里，namespace指定为接口的全限定名，接口方法和XML里的id一一对应，MyBatis启动时会动态生成接口的代理实现类。

日常增删改查的SQL比较简单，但有几个地方值得展开说。第一个是动态SQL。商品列表页有多个筛选条件：关键词模糊查询、分类、价格区间、排序方式，用户不一定会填满。如果用字符串拼接SQL，一个条件漏判就会导致SQL语法错误。MyBatis的<where>标签配合<if>标签能自动处理这个问题，<where>会自动去掉第一个多余的AND或者OR，代码干净还不会错。

第二个是结果映射。数据库表字段用下划线命名（如user_id），Java实体类用驼峰命名（如userId），如果不处理，查询结果映射出来userId全是null。解决办法有两个：在mybatis-config.xml里开启mapUnderscoreToCamelCase，或者在XML里用<resultMap>手动映射。这个项目我开了驼峰转换，简单粗暴有效。

第三个是一对多关联查询。订单主表和订单明细表是一对多关系，我用了<collection>标签在一个查询里把主单信息和明细列表一起查出来，避免循环查询导致的N+1问题。这里有个性能意识值得在论文里单独写一段：如果先查所有订单，再循环查每个订单的明细，100个订单就是101条SQL，而用一条关联查询加<collection>映射，SQL数量直接降为1条。这个对比写进论文里是个加分项。

3. 数据库设计与核心表结构

3.1 数据库表设计的原则

数据库设计是这种项目的门面，评审老师第一眼看的就是ER图和表结构。我设计的时候遵循三个原则：满足第三范式、主键明确且无业务含义、每张表都有对应的操作场景。

用户表存用户基本信息，包括用户名（唯一）、密码（MD5加密存储）、昵称、头像、手机号、注册时间。商品表存商品信息，包括名称、分类、价格、库存、销量、图片路径、描述。分类表单独拆出来，因为商品和分类是多对一关系，拆开是为了避免分类名称冗余存储在每一行商品记录里。购物车表记录用户加购但未下单的商品，一个用户可能对应多条记录。订单表和订单明细表是经典的父子结构，订单表存收货信息、总金额、下单时间、订单状态；订单明细表存每个商品的快照信息，包括当时的单价、数量。最后核心的是用户行为表，记录用户对商品的浏览、收藏、购买行为，这就是协同过滤算法的数据来源。行为类型用一个字段区分，1代表浏览，2代表收藏，3代表购买，购买行为的权重最高。

3.2 索引设计与工具选择

索引这块是数据库性能的关键。user_id、goods_id这些高频出现在WHERE和JOIN条件里的字段都建了索引。唯一索引设置在用户名上，防止重复注册。联合索引我建了一个(user_id, goods_id)的组合，专门支撑行为表的查询场景，因为协同过滤算法第一步就是查某个用户的所有行为记录。

工具方面，日常开发我用Navicat管理MySQL，但最近网络热词里dbx数据库工具讨论度很高，我也试了试。dbx的定位是轻量级的多类型数据库管理客户端，胜在免费开源、跨平台，而且对MySQL、PostgreSQL、SQLite这些常见数据库都支持。如果你做的是课程设计又不想用盗版付费工具，dbx是个不错的选择，连接配置和日常的增删改查都够用。但要注意数据库工具的导出脚本兼容性问题：用Navicat导出的SQL脚本，在dbx里打开可能因为某些注释或格式差异报错，反过来也一样，所以我建议无论用哪个工具，最终提交项目时都把数据库结构SQL和初始化数据SQL单独导出成一份纯SQL文件，这样评审老师在任何环境下都能还原数据库。

数据库迁移这块我额外提一句：不要只提交一个.sql文件就完事。更好的做法是同时提供建库脚本、建表脚本、初始化数据脚本三份分离的文件，并在文档里写清楚MySQL版本要求（推荐5.7或8.0）、字符集是utf8mb4、排序规则是utf8mb4_general_ci。utf8mb4要专门强调，因为如果不设置，存Emoji或者一些生僻字会出现乱码，很多同学的项目在演示的时候中文显示正常，一存特殊字符就炸，就是这个原因。

4. 从零到部署：开发环境搭建与调试部署

4.1 开发环境准备清单

整套环境搭建下来，我的建议是一步到位，避免版本不一致导致的各种玄学问题。推荐组合是：JDK 1.8（SSM的老配置在更高版本JDK下偶尔会有兼容问题，1.8最稳）、Maven 3.6.x、Tomcat 8.5、MySQL 5.7、IntelliJ IDEA或Eclipse（二选一，IDEA体验更好，但Eclipse跑SSM的老项目也没毛病）。

JDK安装后先确认环境变量配好没有，命令行输入java -version能正常输出版本就是成功。Maven同样要配置环境变量，更重要的是改一下settings.xml，把本地仓库路径换到非C盘目录，顺便配置阿里云镜像，否则下载依赖的速度会让人崩溃。第一次创建Maven项目时IDEA会自动下载一堆依赖，遇到网络慢或者卡住的，多半是镜像没配。

Tomcat不用安装，解压就能用，关键是IDEA里配置好。配置的时候要把Tomcat的版本和本地路径指对，然后在Deployment选项卡里把项目以war exploded模式部署，这种模式支持热部署，改完代码不需要重启服务器，刷新页面就能看到效果，调试效率差很多。

4.2 项目导入与部署的具体步骤

拿到源码之后不要急着双击打开，先把依赖和环境准备好。我的实际操作流程是这样的：

第一步，把源码包解压，用IDEA的Open功能选择项目根目录下的pom.xml，以Maven项目方式导入。这里要注意，如果只选中文件夹而不是pom.xml，IDEA可能识别不了Maven结构，导致所有依赖都爆红。

第二步，等Maven依赖下载完成后，检查项目结构：src/main/java存放Java源码，src/main/resources存放配置文件，包括spring-mybatis.xml、spring-mvc.xml、jdbc.properties、log4j.properties，src/main/webapp存放JSP页面、静态资源和WEB-INF/web.xml。

第三步，修改数据库配置。打开jdbc.properties，把数据库URL、用户名、密码改成自己本地的值。URL的格式是jdbc:mysql://localhost:3306/数据库名?useUnicode=true&characterEncoding=UTF-8&serverTimezone=Asia/Shanghai。serverTimezone必须加上，否则MySQL 8.x驱动会报时区错误，这个问题极其常见，下面排查表里我详细说。

第四步，在MySQL里执行数据库脚本，把表和初始数据建好。可以用命令行source命令执行，也可以用数据库工具直接导入。

第五步，配置Tomcat启动项目。在IDEA的Run/Debug Configurations里新增一个Tomcat Server，Local类型，Application Server选到本地的Tomcat，Deployment添加Artifact，Application context填/或者/ssm_shop都行，建议填一个明确的路径，比如/shop，后面访问地址就是http://localhost:8080/shop。配置完成后启动，控制台出现INFO: Server startup in xxx milliseconds就说明部署成功。

最后在浏览器输入地址访问，看到首页能正常渲染、能登录、能浏览商品、能触发推荐列表，整套走通就算部署完成了。

4.3 调试阶段的实战技巧

代码写完之后真正花时间的其实是联调阶段。我最常用的几个调试手段：第一，Controller方法里用System.out.println或者Logger输出参数值和关键中间结果，后端报错了先看控制台堆栈；第二，前端F12打开浏览器开发者工具，Network面板看请求URL、请求参数、响应状态码，500还是404处理方向完全不同；第三，SQL语句有问题是常态，MyBatis的日志配成DEBUG级别，控制台会直接打印出执行的SQL语句和查询参数，一眼就能看出SQL哪里写错了。

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

5.1 环境类问题速查表

我在整这个项目的过程中，把遇到的典型问题整理成了下面这个表，每个都是实操现场踩过的，不是网上抄来的。

5.2 三个印象最深的坑

第一个坑是jar包冲突。项目里同时引入了旧版本的mysql-connector-java和c3p0连接池，结果启动时一直报ClassNotFound。排查了半天发现是Maven依赖里有重复的版本，通过mvn dependency:tree查依赖树，exclude掉多余的旧版本才解决。所以遇到奇怪异常，第一反应应该是看依赖树，而不是去改代码。

第二个坑是@Transactional不生效。我把下单方法写在Controller里，方法上标了@Transactional，结果测试时模拟抛异常，数据库数据还是写进去了。后来查资料才明白，事务需要通过Spring代理对象调用才生效，Controller直接调自己的方法是不走代理的。把业务逻辑下沉到Service，然后在Service方法上标@Transactional，问题解决。这个知识点在答辩的时候被问到的概率很高，建议论文里单独写一段。

第三个坑和数据库同步有关。我需要在两台电脑之间同步项目运行数据，一开始图省事直接拷贝MySQL的data目录，结果各种权限问题、表损坏。后来改用数据库工具的结构同步和数据同步功能，数据完整迁移，表结构差异一目了然。这里顺便推一下热词里频繁出现的“数据库同步软件”这个概念：如果你只是开发阶段在两台机器之间搬数据，直接用图形化工具的同步功能就够了，没必要上专门的同步软件；但如果你要定期把开发库同步到测试库，那确实值得研究一下专门的数据同步方案，比如MySQL主从复制或者用工具定时导出导入，这个属于进阶内容，课程设计用不到。

5.3 部署环节的最后一公里

项目在本机能跑，不代表换个环境也能跑。部署阶段最常见的问题无非三类：端口被占用、JDK版本不一致、数据库连接配置不对。端口被占用的话，在命令行用netstat -ano | findstr 8080查一下是谁占用的，或者直接改Tomcat的server.xml端口。JDK版本不一致的表现是编译报错或者启动报UnsupportedClassVersionError，编译时用的JDK版本高于运行时版本就会这样，所以建议全程统一用JDK 1.8。

部署到生产环境的思路和本地调试是两回事：本地用war exploded方便热部署，生产要用war包放到Tomcat的webapps目录；本地数据库可以用root账号图省事，生产要建独立账号只授予最小权限；本地DEBUG日志随便开，生产日志级别要改成INFO以上。这些属于从课程设计思维往工程思维转变的过渡，有意识地在文档最后写清楚，会给老师或者面试官留下很深的印象。

拿来做课程设计或者毕业设计的同学，我对你们有一个具体建议：不要满足于把系统跑起来，把部署过程、踩过的坑、解决方案写进论文里，这部分是你和网上下载的模板代码最大的区别，也是最能体现工作量和个人思考的部分。我在实际操作中体会最深的一点是，一个SSM项目的价值不在于用到了多少新技术，而在于你能不能把每一层都讲明白，从注解到SQL，从拦截器到事务，从算法到部署，整个链路在自己的脑子里跑通一遍，答辩和面试就都不会虚。最后再分享一个小技巧：项目里加一个“数据初始化”按钮，一键往用户行为表里插入模拟数据，演示推荐功能的时候不用一次性把数据集造全，点一下按钮就能看到推荐列表的实时变化，这种演示效果比干巴巴截图好太多了。