1. 项目整体设计思路1.1 核心需求拆解信息技术论坛系统说白了就是要解决信息共享、问题讨论、内容沉淀这三件事。我在接手某高校的实验项目时第一件事不是急着写代码而是把需求拆成两个维度用户能做什么管理员要管什么。用户侧的核心链路是注册登录、浏览帖子、发布帖子、回复帖子、按分类或关键词找内容、收藏感兴趣的主题。管理员侧的核心链路是用户管理、帖子审核、分类维护、删帖封号、统计报表。两条链路交织在一起就形成了论坛系统的功能骨架。很多人在设计论坛时容易犯一个毛病就是功能越加越多什么积分体系、勋章系统、私信聊天全往上堆。我的建议是先做减法把主链路跑通再谈扩展。比如第一版只做注册登录、发帖回帖、分类浏览、后台管理这四件事搜索和收藏放在第二迭代这样项目周期可控演示效果也扎实。1.2 为什么选 SSM 而不是 Spring Boot这个项目用的是 SSM 组合也就是 Spring SpringMVC MyBatis。放在 2025 年的视角看Spring Boot 已经是绝对主流但 SSM 依然有两类场景值得选择一是老系统的维护和二次开发二是教学和面试场景里需要理解底层原理。我在这次项目中坚持用 SSM主要有三个考量。第一个考量是学习价值。Spring Boot 的自动配置太省事了省到很多新人写完了整个项目都不知道 DispatcherServlet 是怎么被加载的也不知道 MyBatis 的 SqlSessionFactory 是怎么初始化的。SSM 需要你手动配置 web.xml、spring-mvc.xml、mybatis-config.xml虽然繁琐但每一步都能让你理解框架的运作机制。第二个考量是面试和课程设计的需求。很多面试官会问你用过 Spring Boot 吗那你知道它和 SSM 的关系吗如果你只会在 IDEA 里勾选依赖那这个问题很难答出深度。会用 XML 配置 SSM至少说明你看得懂 Spring 容器的启动流程。第三个考量是可控性。SSM 没有自动配置所有 Bean 的创建和注入都明明白白写在 XML 里。出了问题排查起来反而简单因为每一个环节都是你自己配置的。相比之下Spring Boot 自动配置的魔法一旦出了偏差新手往往会束手无策。当然我也要说清楚如果你这个项目是纯粹的毕业设计准备时间又短那直接用 Spring Boot 会更稳妥。SSM 的上手成本确实高一些特别是各个框架版本之间的兼容性问题我在后面的章节里会专门讲。1.3 技术选型的完整清单这次项目的技术栈清单如下前端HTML、CSS、JavaScript、JQuery后台管理页面用 Bootstrap 搭建后端Spring 5.2.x、SpringMVC 5.2.x、MyBatis 3.5.x数据库MySQL 8.0连接池Druid 1.2.x分页插件PageHelper缓存Redis 5.0 单机版构建工具Maven 3.6.x服务器Tomcat 8.5其他Lombok、Fastjson、commons-fileupload有几处选型细节值得展开。Druid 连接池是我比较执着的选择它比 MyBatis 自带的连接池多了一个关键能力SQL 监控。在开发阶段我能通过 Druid 的监控页面看到每一条 SQL 的执行时间、并发数、慢查询日志。这对于定位N 1 查询这类性能地雷非常有帮助。分页插件 PageHelper 解决了一个很具体的痛点。如果不使用分页插件你只能手写 limit 语句并且要每次手动计算 offset。PageHelper 的原理是在 MyBatis 执行 SQL 之前自动拦截改写为带 limit 的 SQL 语句同时执行 count 查询。要注意的是PageHelper 的生效范围是紧跟其后的第一条 SQL所以最佳实践是先调用 PageHelper.startPage()然后再执行 Mapper 方法。Redis 在论坛系统里的定位是缓存热点数据。首页的帖子列表、热门帖子、公告信息、板块分类都属于读多写少的数据非常适合放 Redis。至于用户 Session我仍然使用 Tomcat 的 HttpSession没有引入 Spring Session原因很简单单机构建时没必要引入额外的复杂度。2. 数据库设计与核心接口2.1 表结构设计论坛系统的表结构设计是重中之重表设计得不好后面的 Mapper 写起来全是坑。我设计的核心表一共 8 张分别是用户表、板块表、帖子表、回复表、收藏表、通知表、角色表和用户角色关联表。用户表的核心字段包括id、用户名、密码MD5 加盐后的密文、昵称、头像 URL、邮箱、手机号、状态正常/禁言/封禁、注册时间、最后登录时间和积分。密码存储这里必须强调绝对不允许明文。我当时用的是 MD5 加盐虽然比明文安全了很多但如果放在生产环境我更推荐 BCrypt 或 PBKDF2 这类自适应哈希算法因为 GPU 算 MD5 实在太快了。帖子表是信息密度最大的一张表字段包括id、标题、内容、板块 ID、发帖用户 ID、回复数、浏览量、点赞数、置顶状态、加精状态、审核状态、创建时间和更新时间。这里有一个设计细节帖子的回复数量和浏览量其实是冗余字段它们还可以通过关联查询 count 出来。之所以冗余存储是因为每次展示帖子列表都要实时 count 的话数据库压力会成倍增加。用冗余字段换查询性能是论坛系统里常见的取舍。板块表相对简单id、板块名称、板块图标、描述、帖子总数、排序号和状态。回复表的字段要特别注意 parent_id 的设计。我采用的是两级回复模型也就是既可以回复楼主的帖子也可以回复某一层楼的人用一个 parent_id 字段指向父回复的 IDparent_id 为 0 时表示直接回复主贴。这种设计避免了无限层级嵌套的复杂递归查询又满足了国内论坛的使用习惯。2.2 表关系与索引设计表和表之间的关系是典型的单边多对多模型。一个用户能发多篇帖子一篇帖子归属于一个板块一个用户能收藏多篇帖子一篇帖子也能被多个用户收藏。我把收藏表设计成只有三个字段id、用户 ID、帖子 ID并用user_id, post_id建了联合唯一索引。这样做既可以防止用户重复收藏又能快速查出一个用户收藏了哪些帖子。索引设计上我的核心原则是优先覆盖查询条件其次考虑排序条件。帖子表里最常用的查询模式有两种一是按板块查最新帖子列表二是按时间倒序查全站帖子。所以我在板块 ID 和时间上建了联合索引在用户 ID 下也建了普通索引。回复表上帖子的所有回复必然是按帖子 ID 来查的所以帖子 ID 必须加索引。有一类错误我在开发中反复踩到建索引时不考虑最左前缀原则或者建了太多冗余索引导致插入变慢。实际上像这种规模的项目5 到 10 个索引已经完全够用与其建一堆花里胡哨的索引还不如把主键和查询条件设计好。2.3 分页查询与联表 SQL分页是论坛列表页的核心逻辑。以按时间倒序展示某板块的帖子列表为例常规 SQL 是这样的SELECT p.id, p.title, p.reply_count, p.create_time, u.username FROM post p LEFT JOIN user u ON p.user_id u.id WHERE p.board_id #{boardId} AND p.status 1 ORDER BY p.create_time DESC LIMIT #{offset}, #{pageSize}这里要注意两个问题。第一个是 LEFT JOIN 的使用因为发帖用户可能已经被管理员删除如果用 INNER JOIN帖子列表会少掉一些历史帖子用户体验很糟。第二个问题是 LIMIT 的性能当偏移量特别大时比如第 1000 页MySQL 依然需要扫描前面所有行再跳过这是 MySQL 本身的限制项目规模不到百万级帖子时不用过度优化。联表查询的核心是避免过度联表。有些新人喜欢在一句 SQL 里 join 五张表拿到大量重复数据再在内存里去重。这种做法我强烈反对因为一旦数据量上来这种 SQL 就是数据库杀手。我的习惯是列表页先查出帖子基础数据再按 user_id 集合去批量查用户信息。两次查询换来的是 SQL 的简洁和数据库的轻松。2.4 事务管理与回滚场景论坛系统里最典型的事务场景是发帖。发帖动作本身不只是插入一条 post 记录还要同步更新板块表的帖子总数字段以及给用户的积分加值。这三步必须在一个事务里完成否则会出现板块统计数对不上、积分发了但帖子没发出去的情况。我在 Spring 配置文件里配置了事务管理器并用tx:annotation-driven开启了注解式事务。在发帖的 Service 方法上加上Transactional(rollbackFor Exception.class)这样任何一步抛异常都会触发回滚。有些同学会困惑为什么用rollbackFor Exception.class因为 Spring 默认只对 RuntimeException 回滚如果某个检查型异常比如 IOException没有被捕获默认情况下事务不会回滚数据就会处于不一致状态。写rollbackFor Exception.class是更稳妥的选择。事务的粒度控制也要注意。论坛系统里的浏览量累加这个操作我没放进发帖事务里因为它允许失败也不追求强一致。而且如果每次浏览都开一个事务在高并发下数据库事务数量会非常恐怖反而拖慢主流程。3. 权限与安全机制3.1 登录态管理与拦截器设计论坛系统的访问控制分两层未登录用户可以浏览版块和帖子但发帖、回帖、收藏、点赞必须登录管理员和版主拥有额外的管理权限。我用 SpringMVC 的拦截器实现登录校验。拦截器分为两层第一层是登录检查拦截器拦截所有/user/**、/post/add、/post/reply这些需要登录的路径第二层是权限拦截器拦截/admin/**路径检查当前用户是否拥有管理员角色。拦截器里的核心代码逻辑是这样的从 HttpSession 中取出当前登录用户对象如果为空则重定向到登录页。需要注意重定向会导致地址栏 URL 变化如果用户在发帖页填写了一半内容重定向回来后内容全丢了。我的方案是用 RedirectAttributes 保存一个提示信息同时在前端用 localStorage 暂存草稿这个体验问题就解决了。角色权限的粒度上我采用的是 RBAC 模型的最简实现。用户表不直接存角色字段而是通过用户角色关联表关联到角色表角色再对应一批权限标识。虽然论坛系统的角色数量不多但用关联表的好处是将来扩展运营人员这类新角色时不用改表结构。3.2 密码存储与登录安全密码存储我采用的是 MD5 加盐方案。所谓加盐就是在用户明文密码后面拼接一个随机生成的字符串再对整个拼接结果做 MD5 哈希。加盐的目的很简单如果两个用户密码相同不加盐时它们的 MD5 值也一样一旦数据库泄露攻击者可以通过彩虹表批量还原弱密码。盐值本身的存储位置有两个选择单独字段存盐值或者直接拼在密文后面。我使用的是后者在密码字段里保存的格式为盐值:MD5(密码盐值)这样既不用多开字段也方便校验时解析。登录防暴力破解也是很多论坛系统的短板。我的做法很简单在登录失败时记录当前 IP 在一定时间窗口内的失败次数超过 5 次就暂时锁定 15 分钟。这个逻辑可以用 Redis 的 INCR 和 EXPIRE 实现代码量不大但对安全性提升很明显。3.3 XSS 过滤与富文本处理论坛系统最容易被忽视的安全漏洞就是 XSS 跨站脚本攻击。用户在回帖内容里插入script标签窃取 cookie或者用img srcx onerror...触发恶意脚本这些都是经典攻击手法。对付 XSS我的策略是分层防御。第一层是在用户输入时做过滤使用 jsoup 解析用户提交的 HTML白名单放行安全的标签和属性其余全部清除。第二层是在输出时对普通文本内容做 HTML 编码把尖括号转义为lt;和gt;。富文本编辑器这里要特别小心。如果论坛允许用户在帖子里使用富文本例如加粗、链接、图片那就绝对不能简单地在前端做 sanitize因为前端过滤完全可以被绕过。必须在后端再次做过滤以服务端的过滤结果为准。链接的处理也有讲究。我发现很多小白写的论坛系统用户发一条带网址的内容前端就会生成一个a标签如果 href 指向的是javascript:alert(1)点一下就会执行脚本。正确做法是服务端统统一处理链接只保留http://和https://两种协议开头其他协议一律移除。3.4 SQL 注入防护与 MyBatis 的 # 与 $SQL 注入在我接触过的项目里依然时有发生主要原因是开发者没有理解 MyBatis 中#{}和${}的区别。#{}会被预编译成 JDBC 的?占位符参数值通过参数绑定传入这是一种安全的防注入写法。${}则会将参数值直接拼接进 SQL 字符串如果参数来自用户输入就等价于在拼 SQL 时留下了注入漏洞。框架层面对 SQL 注入的防御是有限度的MyBatis 不会自动判断#{username}后面是否会被用户写成 OR 11。所以我在项目里的实践是所有动态排序字段、动态表名这些无法用#{}替代的地方一律在代码中做一次白名单校验而不是直接信任前端传过来的字段名。配合 Druid 监控我还能在后台看到每一条 SQL 的实际执行情况一旦发现异常语句可以及时溯源。把 MyBatis 的日志级别设为 DEBUG在开发阶段会看到完整的 SQL 打印方便验证预编译是否生效。4. 核心功能实现细节4.1 发帖和回帖的完整流程发帖流程看似只是表单提交实际上涉及多个环节。用户在发帖页面填入标题、选择板块、填写内容点击提交后后端流程是这样的校验用户是否登录未登录跳转到登录页面。校验帖子标题是否为空、长度是否在限制范围内。校验帖子内容是否为空剥离多余空格。调用发帖 Service在事务里完成插入帖子记录、板块帖子数加 1、用户积分加 5。提交事务后异步清空 Redis 里该板块的帖子缓存。跳转到帖子详情页。这里有一个细节容易踩坑帖子的审核状态。很多论坛网站是允许帖子直接发布的但一旦出现广告刷帖你就要考虑引入审核机制。我在项目里增加了审核状态字段普通用户发帖默认状态为待审核管理员后台可以批量通过。演示的时候可以切到直接发布省去审核流程的麻烦。回帖流程和发帖类似但有一个特殊点回帖要出于用户体验考虑做通知。用户在回帖时如果输入了用户名系统需要解析出被 的用户并在帖子中加上高亮标记。这里包含一个简单的字符串解析逻辑加上给被通知用户添加一条站内通知形成闭环。4.2 搜索与热词统计论坛系统的搜索功能如果只针对帖子标题做模糊匹配SQL 是这样写的SELECT * FROM post WHERE title LIKE CONCAT(%, #{keyword}, %)这种方式能满足小规模论坛的基本需求但性能很差。LIKE %关键词% 是无法走索引的这意味着每次搜索都要全表扫描。当帖子量达到几万条时搜索接口就会明显变慢。如果希望论坛搜索体验更好建议引入全文索引或独立的搜索服务比如 Elasticsearch。热词统计在课程设计里是个加分项。用户每次搜索我都把关键词记到 Redis 的 ZSet 里score 累加搜索次数。然后定时把统计结果刷回 MySQL 的一张统计表供首页展示大家都在搜。这个功能的实现难度不大但展示效果很直观能给答辩增色不少。关键是搜索接口的防抖处理。前端做防抖用户停止输入 500 毫秒后才发起请求减少无效请求量。后端做限制同样的关键词在一定时间窗口内只统计一次避免刷词。4.3 图片与文件上传论坛系统里用户上传头像和帖子配图是高频场景。我在项目中用的是 commons-fileupload上传后文件存储在服务器本地磁盘的指定目录访问时通过虚拟路径映射。具体来说我在 SpringMVC 的 XML 配置里加了一个资源映射配置将/upload/**的请求映射到本地的上传根目录。这样前端可以通过 URL 直接访问图片同时这些图片不经过后台权限校验因为图片本身就是放开的。文件上传有两个必须处理的问题。第一个是文件类型校验只允许 jpg、png、gif 等图片格式校验时不能只看文件后缀还要用图片解码库读取文件头判断真实类型。第二个是文件大小限制我在配置里把单文件最大限制设为 5MB防止有人上传超大文件把磁盘打满。比较让我头疼的是 Tomcat 默认限制的 POST 请求体大小默认为 2MB超过就报错。这个在server.xml的Connector节点里配置maxPostSize和maxSwallowSize或者直接设置为 -1 表示不限制。如果漏了这一步上传稍大一点的图片就会莫名其妙报请求失败。4.4 Redis 缓存的应用Redis 在论坛系统里的应用我做了三个场景首页板块帖子的缓存、热门帖子的缓存、验证码的存储。首页帖子的缓存策略相对简单。首页会展示多个板块的最新帖子这些数据如果每次刷新都查数据库其实成本不算高但既然系统里已经引入了 Redis我选择用缓存提升并发承受能力。缓存 key 设计为post:list:{boardId}:{page}value 是帖子列表的 JSON 字符串。当有新帖子发布时我会先删除对应板块的缓存让下一次访问重新从数据库构建缓存。缓存有一个坑就是缓存穿透。如果用户恶意请求一个不存在的帖子 ID每次都会穿透缓存去查数据库。我通过让缓存空对象的办法来避免把这个不存在的 ID 缓存为或 null设置较短的过期时间后续相同请求就不会直接打到数据库。验证码的场景是最值得做 Redis 的。传统做法是把验证码存到 Session 里每次校验从 Session 读出。但用 Redis 的话验证码 key 设置为手机号或邮箱value 是验证码数字过期时间 5 分钟这样既统一了多端登录状态又能方便地控制发码频率。对于接入了短信服务的论坛系统来说这个方案的收益非常明显。5. 部署与性能优化5.1 从开发到生产的配置差异SSM 项目本地跑得顺部署到服务器上问题百出这是常见现象。核心原因是开发环境和生产环境的配置没有分离。我在项目里搞了三份配置文件开发环境、测试环境、生产环境用 Maven 的 profile 机制在打包时动态选择。数据库连接、Redis 地址、文件上传路径、日志级别这些配置按环境分别维护。生产环境里数据库连接串必须用 JNDI 或者环境变量注入不能写死。如果密码泄露影响面是整个数据库。我在课程设计阶段算是偷懒了一回直接在配置文件里写了测试库的密码但这个习惯真的不好现在是能通过环境变量覆盖就绝不放明文。日志配置也很关键。生产环境的 MyBatis SQL 日志不能只开到 DEBUG 级别否则每一条 SQL 都被打印出来日志文件会膨胀得非常快。我建议生产环境只打印 WARN 级别以上的日志常见业务日志输出到独立文件方便排查。5.2 Tomcat 与 JVM 参数调优Tomcat 的调优主要集中在线程池和连接器配置。默认的线程数上限是 200对于并发量不大的论坛系统基本够用。如果预估并发较高可以调整maxThreads参数同时也要适当增大acceptCount也就是请求等待队列的长度。JVM 参数里我重点调整了堆内存大小和垃圾回收策略。以一台 4G 内存的虚拟机为例我通常给 JVM 分配 2048 兆的堆内存初始堆和最大堆设置成一样的值避免运行期堆扩容带来的性能抖动。用-XX:UseG1GC启用 G1 垃圾收集器对响应时间更友好。测试环境中把-Xms和-Xmx设小一点避免影响同一台机器上其他进程的运转。JVM 调优的粒度不需要太大论坛这类业务系统主要是 I/O 密集型CPU 计算很少。真正的瓶颈大多在数据库连接池和高频 SQL 上调 JVM 往往属于无效努力。5.3 前端静态资源与 Nginx 反向代理生产环境的部署和本地开发有一个很大的不同用户浏览器访问到的不应该是 Tomcat 本身而应该是前置的 Nginx 静态服务器。Nginx 承担两个职责一个是处理静态资源把 HTML、CSS、JS、图片这些请求直接交给 Nginx 文件系统处理不用进 Tomcat。第二个是反向代理把/api/*和.action这类动态请求转发给 Tomcat 处理。前端资源如果全部走 Tomcat 也是可以运行的但随着用户访问量增长Tomcat 的多余 I/O 开销会让动态接口变慢。Nginx 处理静态资源的效率远超 Tomcat这是我强烈建议加上的部署环节。静态资源的缓存策略也可以配合做一下。图片资源设置 30 天的缓存过期时间CSS 和 JS 文件通过文件名加指纹的方式更新缓存。这样用户刷新页面时大部分静态资源直接命中浏览器缓存几乎不会请求服务器。5.4 数据库层面的性能优化MySQL 侧的优化优先级我排的顺序是慢查询日志、索引优化、分页优化。首先开启 MySQL 的慢查询日志设置阈值 1 秒运行一段时间后分析出现频繁的慢 SQL。我在这个项目里发现最常出现的慢查询是帖子详情页的那句 SQL原因是没有使用覆盖索引导致数据库回表查询了整行数据。优化方法是在索引上带上查询必需的字段让 SQL 直接走覆盖索引。回表操作省掉后单次查询耗时下降得很明显。分页优化的重点是避免大偏移。当用户翻到第 100 页时LIMIT 1000, 20 这个查询要扫描前 1000 行再丢弃效率很低。我后来改成了基于上一页最大 ID 的翻页方式记录当前页最后一条帖子的 ID下一页的 SQL 条件改为WHERE id #{lastId} ORDER BY id ASC LIMIT 20。这种翻页方式无法跳页但比 LIMIT 偏移量快一个数量级。6. 常见问题与排查实录6.1 依赖冲突与框架版本兼容SSM 项目最让人头疼的就是版本兼容问题。Spring 5 对应 Java 8 和 Servlet 3.1 以上MyBatis 3.5 需要搭配对应的 mybatis-spring 版本如果版本不匹配运行时经常出现奇怪的报错。我遇到过的一个典型报错是NoClassDefFoundError: org/springframework/dao/support/DaoSupport。这个问题的原因是 spring-jdbc 包缺失或版本不对。手动引入 SSM 项目时依赖树容易混乱解决方案是让 Maven 管理依赖尽量统一 Spring 家族的版本号不让某个子依赖独自升级。另一个经验是当出现无法解释的错误时先检查是否命中了依赖冲突。用 Maven 插件查看依赖树的完整路径看看哪些依赖被覆盖了。依赖冲突是 SSM 项目里暗藏的地雷排查效率的高低直接影响开发进度。6.2 404 与 405 等常见状态码排查SSM 项目里的 404 通常分两类一类是请求路径根本不存在另一类是请求路径对但没被 DispatcherServlet 正确映射到 Controller。第二类更隐蔽。比如我曾在 SpringMVC 配置里写了mvc:resources的静态资源映射导致所有/resources/**的请求不再走静态资源处理器页面一旦引用静态资源全部 404。这种问题要认真看启动时的日志检查 HandlerMapping 注册了哪些路径。405 错误一般是请求方式不匹配。Controller 里的方法标注了RequestMapping(value /add, method RequestMethod.POST)前端却用 GET 请求访问就会返回 405。排查时先看浏览器开发者工具的 Network 面板确认请求方式后再回看后端注解这类问题解决得很快。还有一类 404 是字符编码导致的。URL 中带中文参数Tomcat 默认解码字符集是 ISO-8859-1请求到后端后参数变成了乱码Controller 匹配不到对应的值就频繁报 404。Tomcat 8 前的版本需要手动配置 URIEncoding8 版本默认是 UTF-8遇到同类问题可以先检查编码配置。6.3 后台管理页面编辑帖子数据库没有更新的排查后台管理页面里有一类最常见的错误是表单提交成功但数据库内容没变化。页面显示成功实际数据没变这往往是事务管理器配置有问题。我在项目初期就栽过这个跟头。修改帖子的 Service 方法上写了Transactional但 Spring 的注解驱动没有开启事务注解形同虚设。注解没生效时即使某一步抛了异常事务也不会回滚数据库里会留下部分变更的脏数据。排查步骤是先确认 spring 配置里有没有加tx:annotation-driven和事务管理器 Bean。Service 方法是不是被别的无事务方法调用了如果用this.method()自调用事务不会生效因为代理类没有拦截到这次调用。自调用问题是 Spring 事务最经典的坑解决办法是把事务方法拆分到另一个 Bean或者通过 ApplicationContext 获取代理对象调用。如果你遇到数据没更新可以先看控制台有没有打印 UPDATE 语句。有 SQL 但没生效大概率是事务没提交没有 SQL则是 Mapper 接口没被扫描到或者 SQL 写错了没走预期的方法。6.4 中文乱码的两处源头UTF-8 中文乱码问题在论坛系统里几乎必现。原因很多我这里记录两个最容易被忽略的源头。第一处是 JSP 页面的编码。JSP 的pageEncoding、contentType的charset以及浏览器解析时的响应头编码这三处必须一致。如果页面是 UTF-8但 response 的 contentType 是 ISO-8859-1中文就是问号。第二处是 POST 请求的表单编码。SpringMVC 中配置一个 CharacterEncodingFilter并且强制设置为 UTF-8。这个 Filter 必须放在其他所有 Filter 之前因为后续 Filter 和 Servlet 都要依赖已经设置好的请求编码。如果放的位置不对请求参数在后续解析时已经按错误的编码被读取了。数据库层面的编码也要检查。MySQL 创建库和表时的字符集必须是 utf8mb4不要用 utf8因为 utf8mb4 支持表情符号。对论坛系统来说用户发帖可能带 Emoji 符号如果数据库是 utf8插入就会报错。这也是我把所有表统一设置为 utf8mb4 的原因。6.5 上线之后不得不说的那些细节项目能跑通和能上线之间还有一段不小的距离。有几个细节是我每次部署论坛系统都要反复检查的。第一个是数据库连接的超时配置。MySQL 默认的 wait_timeout 是 8 小时如果连接池里的连接空闲时间超过这个值MySQL 会主动断开。连接池里的旧连接如果不做周期性校验用户访问时就会拿到一个已经断开的连接报 Connection is not available, request timed out 错误。Druid 的testWhileIdle和timeBetweenEvictionRunsMillis这两个配置就是干这个的。第二个是服务器防火墙和安全组。我在一次演示前遇到过一个大乌龙项目部署好后本地访问一切正常但外网怎么也访问不到。排查到最后发现是服务器安全组没有放行 8080 端口。这类问题虽小但真的很耽误时间建议先把端口规则列一张清单。第三个是备份策略。论坛系统上线后数据是无价的。最简单但有用的备份方案是每天定时把 MySQL 的数据库用 mysqldump 导出再配合同步工具把备份文件放到另一台机器上。哪怕是一个课程设计级别的论坛养成备份的习惯也受益终身。7. 写在最后的个人体会这套 SSM 论坛系统写下来我最大的感受是技术本身并不难真正难的是把各个模块统筹起来让它们在同一个容器里顺利运行。SSM 相比 Spring Boot 确实繁琐但这种繁琐恰恰逼迫你回头读框架的源码和配置文档。我在配置 SpringMVC 的视图解析器时为了搞清楚逻辑视图名是如何拼接出物理视图路径的翻了不少资料这个过程比单纯用 Spring Boot 敲几行 application.yml 要有收获得多。对于准备做类似项目的同学我的建议是先花三天时间把数据库的关系图画清楚再开始写代码。数据库就是系统的地基地基稳了业务层再怎么折腾都有退路。地基如果歪了后期改表结构会让你欲哭无泪。如果后续想在这个项目上继续扩展可以考虑的方向有引入 Elasticsearch 做全文搜索用 Spring Security 替换手写的拦截器权限或者把前端升级成 Vue 分离架构。循序渐进来总能把这套 SSM 项目的底子打得很扎实。
