SSM羽毛球交流平台：Java Web毕业设计从数据库到部署全解析

简介：面向计算机相关专业毕业设计与课程设计需求，这是一套基于SSM+JSP+MySQL的羽毛球交流平台系统实现资料包，适合正在做毕设的学生、Java学习者以及需要期末大作业项目的开发者。系统按前台用户与后台管理员双角色设计：用户可完成注册登录、查看站内新闻、按编号或名称查询场地并预约、发表留言与评论、进入个人后台查看或删除预约；管理员可登录后台进行系统相关管理，整体业务链完整，便于理解SSM分层开发思路。资料包含项目源码、数据库脚本、开发说明文档和软件工具等，项目经过调试、可运行，能直接作为毕业设计或课程设计主体。压缩包约48.8MB，详情页未标注具体文件数量与类型明细，下载解压后可获得完整工程目录。当前已有132人浏览/学习，适合作为同类课题的落地参考。

1. SSM 羽毛球交流平台：一套能答辩的 Java Web 毕业设计该长什么样

每年毕业季，Java 方向的课题选来选去就那么几类：要么是纯管理系统的增删改查，太单薄；要么是电商类项目，业务重、表多、答辩时根本讲不透。羽毛球交流平台属于那种"看起来有社区感、实际复杂度可控"的题目：用户注册登录后能发帖、约球、报名活动，管理员在后台做审核和统计。技术栈是 SSM + JSP + MySQL，这是 Java Web 课程设计和毕业设计里最经典、面试也最常被问的一套组合。

这套源码加数据库和文档，解压后不是空壳，三层分包、六张数据表、前后台两套页面都是齐的。这份笔记会从拆表讲到部署、再从部署讲到踩坑，照着走一遍，答辩时被问到的点基本都能接住。适合正在做选题、或者已经拿到项目但还没跑起来的同学。

2. 项目拆解：SSM 三层架构与六张核心表怎么搭配

2.1 为什么毕业设计选 SSM + JSP + MySQL：技术选型不是玄学

先说选型。SSM 由 Spring、Spring MVC、MyBatis 三个框架组成——Spring 管对象和事务，Spring MVC 管请求转发与参数绑定，MyBatis 管 SQL 和实体类的映射。这套组合在近几年的 Java 课程设计和毕业设计里占据绝对主流，原因很简单：面试会问、资料好找、范例多。

JSP 作为视图层，放在今天看确实老，但它有一个别的模板引擎替代不了的优势：答辩场景下，JSP 页面里的<c:forEach>标签和 EL 表达式可以直接展示后端传来的 List，老师一眼就能看懂数据怎么从数据库到页面。换个 Vue 或 Thymeleaf，反而要多解释一层。这不是技术落后的问题，是"用最直白的方式把完整链路口述清楚"的问题。

我一般会建议选题前先想清楚三个问题：数据有没有关联（用户发帖、帖下有评论）、有没有状态流转（帖子待审核、已通过）、有没有前后台权限差异（普通用户和管理员）。羽毛球交流平台恰好三条都占，业务量又不大，四到六张表就能撑起来，是目前这类题目里性价比比较高的一个。

2.2 数据库建模：user / post / activity / comment 四类核心表

整套系统的逻辑可以浓缩成一句话：用户登录后发帖或发起约球活动，其他用户报名或评论，管理员在后台审核与统计。落到数据库设计上，就是围绕用户、帖子、活动、评论这四个实体建表。我拿到项目的第一件事不是看 Java 代码，而是先看 SQL 脚本里建了哪些表、字段默认值设得对不对。

下面这段建表脚本是项目里最常见的设计方式，先删表再建表，方便重复初始化：

DROP TABLE IF EXISTS `t_user`; CREATE TABLE `t_user` ( `id` int(11) NOT NULL AUTO_INCREMENT, `username` varchar(32) NOT NULL COMMENT '登录名', `password` varchar(64) NOT NULL COMMENT 'MD5加密后的密码', `nickname` varchar(32) DEFAULT NULL COMMENT '昵称', `phone` varchar(11) DEFAULT NULL COMMENT '手机号', `role` tinyint(4) DEFAULT 0 COMMENT '0普通用户 1管理员', `status` tinyint(4) DEFAULT 0 COMMENT '0正常 1禁用', `create_time` datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uk_username` (`username`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

这段 SQL 里有三个细节值得注意。第一个是password字段用varchar(64)，对应 MD5 或 MD5 加盐后的十六进制串，而不是varchar(32)明文；第二个是role和status用tinyint存，比枚举字符串省空间，查询也快；第三个是建了uk_username唯一索引，防止注册时并发插入相同用户名。

帖子表和活动表是两套独立实体，帖子偏内容型，活动偏约球场景，继续看建表脚本：

DROP TABLE IF EXISTS `t_post`; CREATE TABLE `t_post` ( `id` int(11) NOT NULL AUTO_INCREMENT, `user_id` int(11) NOT NULL COMMENT '发帖人，外键到t_user.id', `title` varchar(100) NOT NULL, `content` text COMMENT '正文', `type` tinyint(4) DEFAULT 0 COMMENT '0技术交流 1约球 2球拍装备', `status` tinyint(4) DEFAULT 0 COMMENT '0待审核 1通过 2驳回', `view_count` int(11) DEFAULT 0, `create_time` datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `idx_user_id` (`user_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; DROP TABLE IF EXISTS `t_activity`; CREATE TABLE `t_activity` ( `id` int(11) NOT NULL AUTO_INCREMENT, `post_id` int(11) NOT NULL COMMENT '关联帖子', `location` varchar(64) NOT NULL COMMENT '球场或场馆', `start_time` datetime NOT NULL COMMENT '开打时间', `max_num` int(11) DEFAULT 4 COMMENT '人数上限', `join_num` int(11) DEFAULT 0 COMMENT '当前已报名人数', PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

活动表和帖子表分开，比把约球信息全塞进帖子字段里要好。max_num与join_num分离，报名时先判断join_num < max_num再执行UPDATE join_num = join_num + 1，逻辑清晰，后面做并发控制也有抓手。start_time单独拎出来，方便做"即将开始的约球"这类排序查询。

2.3 Service 层与 Controller 层的职责边界：以约球报名为例

三层架构里最容易写乱的是业务逻辑到底放哪。很多初学者会把判断代码写在 Controller 里，Service 变成空壳。正确做法是 Controller 只做三件事：接收参数、调用 Service、返回响应；真正的判断和事务管理全在 Service 层。

以报名约球为例，Service 层通常长这样：

@Override @Transactional(rollbackFor = Exception.class) public boolean joinActivity(Integer activityId, Integer userId) { Activity activity = activityMapper.selectById(activityId); if (activity == null) { return false; // 活动不存在，直接返回失败 } if (activity.getJoinNum() >= activity.getMaxNum()) { return false; // 人数已满，不再受理报名 } // 防止同一个用户重复报名，先查报名记录 if (activityMapper.checkUserJoined(activityId, userId) > 0) { return false; } activityMapper.increaseJoinNum(activityId); activityMapper.insertJoinRecord(activityId, userId); return true; }

这段代码里@Transactional注解是必须的，因为"更新人数"和"插入报名记录"是两个写操作，中间任何一步抛异常都会造成数据不一致——人数加了但记录没插上。rollbackFor = Exception.class的意思是任何异常都要回滚，而不是默认只回滚 RuntimeException。

注意这里用了"先查再改"的方式判断人数上限，在并发量极低的毕业设计场景里完全够用。如果答辩老师追问高并发怎么办，顺着说改成UPDATE ... SET join_num = join_num + 1 WHERE id = ? AND join_num < max_num就能规避风险，这条 SQL 放在避坑章节里细讲。参数上，max_num默认给 4 是羽毛球局常见的双打组队人数，如果场地支持多局轮换可以调大。

3. 从 0 跑起来：环境准备、SQL 导入与 IDEA 部署全流程

3.1 环境清单：JDK、Maven、Tomcat、MySQL 的版本搭配

拿到压缩包先别急着双击 IDEA，先把环境对齐。项目基于 SSM，我建议按 JDK 1.8 + Maven 3.6.x + Tomcat 8.5 + MySQL 5.7 的组合来跑，这个组合跟项目里的pom.xml和web.xml兼容性最好。如果你本机装的是 MySQL 8.0 也别慌，避坑章节会专门讲驱动和时区的问题，这里先把推荐版本列清楚：

这里特别提醒一句：网上很多教程让你直接装最新版 JDK 17 或 21，SSM 项目不是不能跑，但pom.xml里引的旧版依赖在高版本 JVM 上可能直接报反射或IllegalAccessError错误，排查起来很费时间。想看项目内容就用兼容版本，这是最省事的路径。

3.2 数据库初始化：建库、导数据、改连接配置

解压后的sql文件夹里通常有db_badminton.sql，里面是建库、建表和初始化数据的完整脚本。打开命令行进入 MySQL：

mysql -uroot -p Enter password: 你的密码 mysql> CREATE DATABASE IF NOT EXISTS db_badminton DEFAULT CHARACTER SET utf8mb4; mysql> USE db_badminton; mysql> SOURCE C:/workspace/badminton_platform/sql/db_badminton.sql;

注意SOURCE后面要写绝对路径，Windows 下用正斜杠或双反斜杠，用单反斜杠\会被 MySQL 当成转义符处理。跑完后执行SHOW TABLES;，能看到六张表基本就算导入成功。

接下来改数据库连接配置。SSM 项目里一般有两个地方：src/main/resources/jdbc.properties和spring-mybatis.xml里的数据源引用。最常见的是前者，把账号密码和 URL 改成你本地的：

jdbc.driver=com.mysql.jdbc.Driver jdbc.url=jdbc:mysql://localhost:3306/db_badminton?useUnicode=true&characterEncoding=utf8&useSSL=false jdbc.username=root jdbc.password=123456

这里第一处要改的是驱动类名。MySQL 5.7 用com.mysql.jdbc.Driver没问题；如果数据库是 MySQL 8，要改成com.mysql.cj.jdbc.Driver，同时 URL 末尾加serverTimezone=Asia/Shanghai，否则启动大概率报时区错误。第二处是characterEncoding=utf8，不加这一句，后面写入的中文到数据库里就是问号。useSSL=false是关掉 SSL 告警，本地开发不需要加密连接。

3.3 IDEA 部署：配置 Tomcat 与 artifacts

数据库就绪之后，用 IDEA 打开项目根目录，等 Maven 依赖下载完成。首次导入如果仓库里没有依赖，会在右下角持续转圈，这个过程可以顺手把 Maven 的settings.xml换成阿里云镜像，全量依赖一般几分钟内能拉完。

打开Run -> Edit Configurations，点加号选 Tomcat Server -> Local。在 Deployment 页签里加badminton_platform:war exploded，Application context 填/badminton。这一步经常有人漏掉，导致启动后访问的是 Tomcat 欢迎页而不是项目页面。Server 页签里把 HTTP port 设为 8080，Open browser 设为 After launch。

启动前还要确认 Project Structure 里 Artifacts 的 Output Layout 已经包含了lib目录下的所有 jar 包。如果没包含，启动时报ClassNotFoundException或NoClassDefFoundError，原因就是依赖没有打进去。IDEA 在 Maven 项目生成 war exploded 时一般会自动带上，但如果你手动动过 Artifacts，就要重新检查。

启动正常后，IDEA 控制台会输出 Tomcat 的启动日志，看到INFO: Server startup in...并且没有红色 ERROR 就说明容器起来了。

3.4 启动验证：从 404 到成功页面的检查路径

系统跑起来之后，第一件事不是点功能，而是按下面这条路径把主链路验证一遍。

浏览器访问http://localhost:8080/badminton/。如果出现首页或者跳转到登录页，说明 Spring MVC 的 DispatcherServlet 正常工作。如果 404，按顺序检查三点：项目有没有成功部署到指定 context、web.xml里dispatcherServlet的 url-pattern 是否覆盖了要访问的路径、index.jsp或login.jsp是否在webapp根目录下。

访问注册页面，用测试用户名注册，然后去数据库确认：

SELECT id, username, role, status, create_time FROM t_user;

能看到刚注册的用户，说明从 JSP 表单到 Controller、再到 Service、最终写入 MySQL 的链路是通的。如果注册成功但页面上显示乱码，跳到避坑章节的乱码记录去处理。这套验证路径做完，系统"跑不跑得通"这个问题就有了确定答案。

4. 核心功能落地：用户注册、发帖约球与后台管理实现要点

4.1 注册登录与验证码：MD5 加密和登录态保持

用户模块是整个系统的地基。项目里常见的实现方式是用过滤器统一处理未登录跳转，登录成功后把用户对象放进 session。注册环节除了常规非空判断，还要做两件事：检查用户名是否已存在、密码用 MD5 加密后入库。

Service 层的注册逻辑通常是这样：

@Override public boolean register(User user) { // 先查用户名是否被占用 User exist = userMapper.findByUsername(user.getUsername()); if (exist != null) { return false; } // 密码加密后重新赋给对象 String md5Pwd = DigestUtils.md5DigestAsHex( user.getPassword().getBytes(StandardCharsets.UTF_8)); user.setPassword(md5Pwd); user.setRole(0); // 默认普通用户 user.setStatus(0); // 默认正常 userMapper.insert(user); return true; }

这里DigestUtils.md5DigestAsHex来自 Spring 自带的工具类，不用额外引依赖，对毕业设计来说足够演示。存储层拿到的是密文，哪怕数据库被导出了也不会直接泄露明文密码。登录时把用户输入的密码同样做 MD5，再和库里的密文比对。

登录态这块，我建议把用户信息只放 session，不要放 cookie。毕业设计规模下不需要考虑分布式 session，session.setAttribute("loginUser", user)就够，再配合一个LoginInterceptor做拦截。JSP 页面里取当前用户也很直观：${sessionScope.loginUser.nickname}。

验证码部分，项目里一般用 Java 画图片的方式在 Controller 里生成，把四位随机数放进 session，校验时忽略大小写且只允许一次比对。验证码过期时间要设短一点，五分钟以内比较合理，不然容易被挑出安全漏洞。

4.2 发帖与约球：从表单提交到数据落库的完整链路

发帖是平台的核心操作。流程是：用户登录后进入发帖页，填标题、正文，选择帖子类型（技术交流、约球、装备），提交后进入PostController。这里要理解一个关键设计：约球帖不只是普通帖子，提交时还要同时插入一条活动记录。

Controller 接收参数的方式决定了代码好不好写。我建议用PostVO对象接收表单，而不是用HttpServletRequest一个个getParameter。PostVO里既有帖子字段，也有location、startTime、maxNum等约球扩展字段：

@Controller @RequestMapping("/post") public class PostController { @Resource private PostService postService; @RequestMapping(value = "/add", method = RequestMethod.POST) public String add(PostVO vo, HttpSession session) { User loginUser = (User) session.getAttribute("loginUser"); if (loginUser == null) { return "redirect:/user/login"; } vo.setUserId(loginUser.getId()); boolean result = postService.addPostWithActivity(vo); if (result) { return "redirect:/post/list"; } return "post/add"; } }

Controller 层很薄，所有业务判断都在postService.addPostWithActivity里完成。这个方法内部做的事是：先往t_post插入主帖记录拿到自增 ID，如果帖子类型是约球，再往t_activity插入活动记录，两者在同一事务里，任一失败则整体回滚。这就是典型的"两次写操作必须包事务"场景，和第 2 章强调的@Transactional是同一套思路。

发布成功后跳转到列表页，列表查询通常就是分页加类型筛选：

SELECT p.id, p.title, p.create_time, u.nickname, p.view_count, p.status FROM t_post p LEFT JOIN t_user u ON p.user_id = u.id WHERE p.status = 1 ORDER BY p.create_time DESC LIMIT #{offset}, #{pageSize}

注意这里用LEFT JOIN而不是INNER JOIN，防止发帖人被删了以后帖子也查不出来；LIMIT #{offset}, #{pageSize}是 MyBatis 里做分页最基础的方式。帖子列表只要加一个WHERE p.type = 1就能过滤出约球帖，这也是把约球扩展字段单独建表带来的好处。

4.3 后台管理：列表分页、状态审核与删除

后台管理的原型是管理员登录后看到一个管理首页，上面显示用户总数、帖子总数、今天的新帖量、待审核帖量。这些统计数字用一条 SQL 就能算出来，放在后面的报表章节细说。这里先讲后台最常被问的操作：审核帖子和禁用用户。

审核动作的本质是一次状态更新，不涉及复杂逻辑：

@Override public boolean auditPost(Integer postId, Integer status) { // status: 1表示通过，2表示驳回 Post post = postMapper.selectById(postId); if (post == null || post.getStatus() != 0) { return false; // 帖子不存在，或不是待审核状态，拒绝操作 } postMapper.updateStatus(postId, status); return true; }

这段代码体现了一个容易被忽略的防线——"不是待审核状态就不允许审核"。如果省略这个判断，管理员反复点击审核按钮会把一条已通过的帖子改回驳回，状态流转就失去了单向性。答辩时老师问"为什么要有这个 if"，能答出"保证状态机只能从待审核流转到终态"基本就过关了。

禁用用户的逻辑类似，userMapper.updateStatus(userId, 1)把用户状态改成禁用，但该用户当前 session 不会被踢出，真正生效要等下次操作时拦截器检查。如果想让禁用立即生效，可以在拦截器里每次都查一次库取最新 status，代价是多一条 SQL，但对管理后台的交互体验更友好。

后台列表的分页建议直接用PageHelper.startPage(pageNum, pageSize)，它基于 MyBatis 拦截器自动改写 SQL，不用手写 offset。唯一要注意的是PageHelper.startPage必须紧跟第一条 Mapper 查询语句，中间不能有任何其他查询，否则分页参数会被错误的查询消费掉。这个坑非常经典，几乎每次答辩现场都会有人翻车。

5. 避坑与排查：从 404 到乱码的五个实战记录

5.1 MySQL 8 驱动类与时区导致的连接失败

现象：启动 Tomcat 时报ClassNotFoundException: com.mysql.jdbc.Driver，或报The server time zone value '�й���ʱ��' is unrecognized。

原因：两种原因叠加。项目里的jdbc.properties默认配的是 5.7 时代的驱动类名，而本机装的是 MySQL 8.x，驱动类已经改名成com.mysql.cj.jdbc.Driver；同时 8.x 的 JDBC 驱动对服务器时区有强校验，没传serverTimezone参数就直接抛异常。

解决：把jdbc.properties改成下面这样：

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

改完之后记得清理 IDEA 缓存再重启。改完配置还报错的话，先确认 Maven 依赖里实际引入的是哪个版本的 mysql-connector-java，高版本驱动可能已经不认旧 URL 格式。检查方法是在右侧 Maven 面板的 Dependencies 树里看坐标。

5.2 Tomcat 版本与 JDK 版本不匹配导致 JSP 编译失败

现象：启动后访问页面报Unable to compile class for JSP，或者The superclass "javax.servlet.http.HttpServlet" was not found on the Java Build Path。

原因：Tomcat 10.x 把 Servlet 包名从javax.*换成了jakarta.*，而项目代码和 JSP 里全是旧包名。另一种可能是 JDK 版本太高，Tomcat 8.5 在高版本 JDK 上会有兼容性问题。

解决：换成 Tomcat 8.5.x + JDK 1.8 的组合。在 IDEA 的 Run Configuration 里把 Application server 指到本地解压的 Tomcat 8.5 目录，Project Structure 里把 Project SDK 和 Module SDK 都改成 1.8。改完后执行一次mvn clean package，把 target 目录删掉再重新部署。

这属于"环境问题优先于代码问题"的典型情况。出现后先看 Tomcat 版本，再考虑是不是代码问题，顺序反了容易在报错日志里浪费时间。

5.3 中文乱码：从 JSP 到数据库全链路排查

现象：注册的用户名在数据库里显示为???，或者页面显示乱码。

原因：乱码通常是三个环节中的一个断了。JSP 页面没有声明 UTF-8、Tomcat 接收请求的编码不是 UTF-8、数据库连接 URL 没带characterEncoding=utf8。三个环节只要坏一个，数据流全程乱。

解决：逐个排查。JSP 页面头部必须有这段：

<%@ page contentType="text/html;charset=UTF-8" language="java" %>

然后在 Spring MVC 的配置文件里加编码过滤器：

<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> <init-param> <param-name>forceEncoding</param-name> <param-value>true</param-value> </init-param> </filter> <filter-mapping> <filter-name>encodingFilter</filter-name> <url-pattern>/*</url-pattern> </filter-mapping>

forceEncoding设为true的意思是同时把 request 和 response 的编码强制设为 UTF-8，改完这个基本都能救回来。如果数据已经乱掉，把那张表的数据清掉重新测试。数据库连接 URL 里的characterEncoding=utf8别拼成utf-8。

5.4 静态资源 404：路径和 web.xml 配置细节

现象：页面结构正常但 CSS、JS、图片全部加载不出来，浏览器控制台一堆 404。

原因：Spring MVC 的DispatcherServlet会把所有请求都拦下来，包括/css/xxx.css、/js/xxx.js，如果配置里没有放行静态资源，就会报 404。

解决：在 Spring MVC 配置里加静态资源映射：

<mvc:resources mapping="/static/**" location="/static/"/>

同时确认项目里静态文件放在webapp/static目录下，在 JSP 里引用时写成${pageContext.request.contextPath}/static/css/style.css。不加contextPath是常见翻车点——本地直接访问可能碰巧能出来，但部署到带 context 路径的 Tomcat 后样式全丢。改用c:url标签或者${pageContext.request.contextPath}前缀是最稳的写法。

5.5 报名约球时的并发覆盖：条件更新与事务回滚

现象：活动页面显示剩余 2 个名额，两个人同时报名，数据库里实际收到的报名人数可能和显示不符，极端情况是超过人数上限。

原因：第 2 章那个"先查再改"的逻辑在并发场景下有竞态条件。两个请求同时读到join_num = 3，都判定3 < 4满足条件，都去执行join_num = join_num + 1，最终join_num变成 5，而按业务规定最多只能有 4 人。

解决：把两步合并成一条条件更新 SQL，让数据库来保证原子性：

UPDATE t_activity SET join_num = join_num + 1 WHERE id = #{activityId} AND join_num < #{maxNum}

这条语句执行后先看受影响行数，等于 1 表示报名成功并拿到了名额，等于 0 表示名额已满。在此基础上再插入报名记录，两条操作留在同一个@Transactional方法里。毕业设计答辩时，把这个"条件更新代替查改分离"的点讲出来，通常能在技术分上加分。

6. 答辩前最后一步：给系统加报表，用数据说话

6.1 用 ECharts 在后台首页展示用户活跃度

答辩的时候，光有"能增删改查"是不够的，评审老师更想看到数据能说话。我习惯在后台首页加一块简单的统计区域：本周每日新增帖数、约球活动的报名率、用户增长曲线。数据不用额外开发，后台管理的 Service 里做几个聚合查询就行。

举例，统计最近七天的发帖量，核心 SQL 是一句 GROUP BY：

SELECT DATE(create_time) AS d, COUNT(*) AS cnt FROM t_post WHERE create_time >= DATE_SUB(CURDATE(), INTERVAL 6 DAY) GROUP BY DATE(create_time) ORDER BY d;

后端把这个结果封装成List<Map<String, Object>>传到 JSP，前端用 ECharts 的折线图渲染。引入 ECharts 用一个 CDN 标签搞定：

<script src="https://cdn.jsdelivr.net/npm/echarts@5/dist/echarts.min.js"></script> <script> var chart = echarts.init(document.getElementById('postChart')); chart.setOption({ xAxis: { type: 'category', data: ${dates} }, yAxis: { type: 'value' }, series: [{ type: 'line', data: ${counts} }] }); </script>

如果答辩现场不能联网，把 echarts.min.js 提前下载到static/js下走本地引用。图表不复杂，一个图表加一句解释就能让演示从"点按钮看列表"升级成"看数据趋势"，这个观感差异在答辩现场是实实在在的。

6.2 搜索与状态筛选：从列表页到可用的小功能

功能扩展的边界要控制住，加太多超出原始设计的项反而容易被追问。我建议只做两个：全局站内搜索和约球活动按时间排序。搜索就是帖子列表加一个模糊通配：

WHERE p.status = 1 AND p.title LIKE CONCAT('%', #{keyword}, '%')

LIKE CONCAT('%', #{keyword}, '%')比直接写'%${keyword}%'安全，因为前者走的是预编译参数绑定，不会拼 SQL；后者会有注入风险。活动排序更简单，ORDER BY a.start_time ASC把临近开始的约球放在最前，这个查询让平台的使用价值立刻不一样。

每加一个功能，都要顺手把对应的 Controller 路径和 JSP 表单 name 对齐，这是最常见的自找麻烦来源——后端接收参数名跟页面不一样，调试半天发现是单词拼错。我现在的习惯是写完一个功能先跑通主链路，再做异常分支，最后回头理一遍参数命名。

我自己的毕业论文就是这样折腾过来的：答辩前一周把报表加上，反复演示了三轮完整流程，从注册到约球到后台审核，每条数据都能对上一个地面真值。从那以后，我每次交付类似 SSM 项目都会强制走一遍同样的流程——先初始化数据库、启动看日志、跑主链路、查库验证数据。这套流程不神奇，但能在答辩现场减少八成意外。希望帮到你。

本文还有配套的精品资源，点击获取