企业官网建设流程全解析

简介：基于SSM框架与微信小程序的健身类Java毕业设计项目，主要面向计算机相关专业毕业生、需要完成课程设计或实战项目的Java学习者。压缩包内整合了完整源码、数据库脚本、答辩PPT、开题报告、使用文档及演示视频，内容覆盖前后端开发、接口联调与项目部署等关键环节。包内共970个文件，体积约58.76MB，其中Java源码与Vue/JS前端页面构成主体，辅以微信小程序所需的WXML/WXSS文件、JSON配置、SQL数据库脚本，以及PPTX、MP4演示和文档说明，结构清晰便于按需取用。项目已在Windows10/11环境调试通过，答辩评审分97分，现有154人学习下载。对于需要快速搭建健身类管理系统的读者，可直接参考其代码逻辑与文档完成环境搭建和二次开发，减少从零开始的探索成本。

1. SSM+微信小程序健身毕设资源包：先搞清楚它值不值得你花时间

做毕设最怕的不是功能多，而是后端、前端、数据库三摊事全压在一个人的肩上，时间只剩下几周。这套基于 SSM 和微信小程序的健身项目资源，把后端接口、小程序页面、数据库脚本、开题报告、PPT 和演示视频都打包进去了，目的就是让你从「从零开发」变成「读代码、改业务、讲清楚」。但能不能靠它拿高分，取决于三件事：能不能跑通、能不能改得动、答辩时能不能讲明白——这三步恰好是很多人拿到资源包后最容易翻车的地方。下文按架构拆解、运行环境、核心业务、避坑清单、答辩演示这条路径，把这类项目最常见的落地方案完整过一遍，新手可以照着走，熟手可以直接跳到后面看边界条件和踩坑点。

2. 先拆架构：SSM 后端与微信小程序端的协作模型，搞懂后才能改得动

拿到一套陌生代码，第一件事不是急着启动，而是先花半小时搞懂它怎么组织在一起的。SSM 和微信小程序是两套完全独立的技术栈：后端跑在 Tomcat 里，小程序跑在微信的容器里，中间靠 HTTP 接口通信。如果这块逻辑没理清，后面改任何功能都会像在黑匣子里摸索。下面按三层来讲：后端 SSM 的分工、小程序的数据通路、数据库的表结构。

2.1 Spring、SpringMVC、MyBatis 在健身业务里各管哪一段

SSM 是三个框架的合称，很多新手把它们混在一起学，越学越乱。实际上在健身预约这个业务里，它们的职责边界非常清楚：Spring 是容器，负责创建和管理 Service、Mapper 这些对象，同时提供事务管理能力，比如预约时扣库存和插记录必须同时成功或同时失败，就是 Spring 的@Transactional在管；SpringMVC 是 Web 层，负责把小程序发来的 HTTP 请求映射到对应的 Controller 方法上，同时完成 JSON 参数的绑定和返回值的序列化；MyBatis 是持久层，负责把 Mapper 接口里的方法翻译成 SQL 语句，再把查询结果映射成 Java 实体对象。

举个典型的 Controller 例子，小程序端请求「获取课程列表」时：

@RestController @RequestMapping("/api/course") public class CourseController { @Autowired private CourseService courseService; @GetMapping("/list") public Result list(@RequestParam(defaultValue = "1") Integer page, @RequestParam(defaultValue = "10") Integer size) { List<Course> courses = courseService.getCourseList(page, size); return Result.success(courses); } }

这个接口做了三件事：用@RestController声明这是一个返回 JSON 的控制器，小程序拿到的不是 JSP 页面而是纯数据；用@Autowired把 CourseService 注入进来，实际干活的逻辑在 Service 里，Controller 只负责接参数和回结果；@RequestParam把 URL 上的 page 和 size 参数绑定为方法入参，不传时默认取第一页十条。这样的分层习惯几乎贯穿所有 SSM 毕设，你拿到代码后找功能入口，先找 Controller，再顺着 Service 往下摸到 Mapper，就能把一条业务链路看清楚。

2.2 小程序端怎么和后端通信：请求封装、登录态与 JSON 约定

小程序端不是直接连数据库的，它只做两件事：渲染页面、发请求。以课程列表页为例，小程序通过wx.request发起 HTTP 请求，后端返回 JSON 数组，前端再通过setData渲染到页面上。为了方便维护，通常会把请求封装到一个公共文件里，每个页面引用这个封装，而不是在页面里重复写wx.request。

// utils/request.js const BASE_URL = 'http://192.168.1.100:8080/fitness'; function request(path, method = 'GET', data = {}) { return new Promise((resolve, reject) => { wx.request({ url: BASE_URL + path, method, data, header: { 'Content-Type': 'application/json', 'Authorization': wx.getStorageSync('token') || '' }, success: (res) => { if (res.statusCode === 200) { resolve(res.data); } else { reject(res); } }, fail: reject }); }); } module.exports = { request };

这段封装有四个关键设计：BASE_URL 是后端服务的根路径，IP 地址写的是你电脑在局域网里的地址，不能写 localhost，因为手机或小程序开发者工具访问的是你电脑的局域网 IP；header 里带了 Authorization，这是登录后后端签发的身份标识，后续每个请求都靠它来识别用户是谁；Promise 包装让页面里可以用 async/await 写异步逻辑，避免回调地狱；fail 回调里什么都不做，直接把错误抛给调用方，方便页面统一弹 toast 提示网络异常。我习惯把 token 放请求头而不是 URL 参数里，一是防止 token 出现在服务端日志中，二是方便以后接入拦截器统一校验。

2.3 健身业务的数据库建模：用户、课程、教练、预约怎么设计

数据库是整个项目的底座，也是最容易被答辩老师抓住追问的部分。一套常规的健身预约小程序，核心表至少有四到六张：用户表、教练表、课程表、预约表，外加课程分类表和收藏表。实体关系是：一个教练可以带多门课（一对多），一个用户可以预约多门课（多对多），这个多对多关系通过预约表拆开。

CREATE TABLE t_user ( id BIGINT PRIMARY KEY AUTO_INCREMENT, openid VARCHAR(64) NOT NULL UNIQUE, nickname VARCHAR(50), avatar VARCHAR(255), phone VARCHAR(20), role TINYINT DEFAULT 0 COMMENT '0-会员 1-管理员', create_time DATETIME DEFAULT CURRENT_TIMESTAMP ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; CREATE TABLE t_course ( id BIGINT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(100) NOT NULL, coach_id BIGINT NOT NULL, category_id BIGINT, max_count INT DEFAULT 20, current_count INT DEFAULT 0, start_time DATETIME NOT NULL, end_time DATETIME NOT NULL, price DECIMAL(10,2), image VARCHAR(255), status TINYINT DEFAULT 1 COMMENT '1-上架 0-下架' ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; CREATE TABLE t_appointment ( id BIGINT PRIMARY KEY AUTO_INCREMENT, user_id BIGINT NOT NULL, course_id BIGINT NOT NULL, status TINYINT DEFAULT 1 COMMENT '1-已预约 0-已取消', create_time DATETIME DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_user_course (user_id, course_id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

这三张表是核心。openid 字段是微信用户的唯一标识，登录时要用它来匹配用户，所以加了唯一索引；current_count 和 max_count 是预约库存场景的关键字段，判断课程是否满员全靠它们；t_appointment 上的联合唯一索引 uk_user_course 是防止同一个用户重复预约同一门课的最后一道防线，即使代码里有判断，数据库层面也要兜底。理解这三张表后，再看资源里的完整 SQL 脚本，会发现其余表基本都是围绕它们做扩展的，比如课程分类表可以挂在 t_course 的 category_id 上，收藏表则可以设计成 user_id 与 course_id 的联合记录。

3. 把资源包跑起来：从导入 SQL 到小程序正常出数据的完整链路

很多人在这一步卡住，而且卡得莫名其妙：明明按文档操作了，Tomcat 能起来，小程序却刷不出数据。这一章按顺序过一遍跑通这套项目必须做的三件事：导数据库、改后端配置、配小程序端。

3.1 导入数据库脚本：字符集、库名、账号权限三个前置检查

解压资源后，找到以 .sql 结尾的数据库脚本，执行导入前先做三个检查。第一，确认本地 MySQL 版本不低于 5.7，因为脚本里可能用了 utf8mb4 和 datetime 默认值，老版本会直接报语法错误；第二，确认脚本里 CREATE DATABASE 的库名是不是你想要的，有些脚本把库名写死成 fitness_db，你改了库名就得连配置一起改，不然连接串对不上；第三，确认当前 MySQL 账号有建库建表权限，有些同学用的是 root 但密码和脚本里的不一致，导致连接失败。

# 第一步：创建数据库，指定 utf8mb4 字符集避免中文乱码 mysql -u root -p -e "CREATE DATABASE IF NOT EXISTS fitness_db DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;" # 第二步：导入 SQL 脚本，路径换成你解压后的实际路径 mysql -u root -p fitness_db < /path/to/fitness_db.sql

第一条命令先创建数据库并指定 utf8mb4 字符集，第二条命令把整个 SQL 脚本导入到这个库里。导入完成后建议先验证一下：执行SHOW TABLES;看是否有课程表、预约表等核心表，再执行SELECT COUNT(*) FROM t_user;看看有没有预置的测试数据。数据导入之后并不是万事大吉，下一步还要检查后端连接数据库的配置是否和你本地环境一致，这个坑在第 5 章会专门展开。

3.2 修改后端连接配置：db.properties 里必改的三个参数

SSM 项目通常把数据库连接信息放在 src/main/resources 目录下，文件名一般是 db.properties 或者 jdbc.properties。你需要修改的是 jdbc.url、jdbc.username、jdbc.password 三项，其中 jdbc.url 最容易被忽略的是后面的参数部分。

# 数据库驱动，MySQL 5.x 用 com.mysql.jdbc.Driver，8.x 用 com.mysql.cj.jdbc.Driver jdbc.driver=com.mysql.jdbc.Driver # 连接地址，那两个 utf8 参数不能删，否则中文乱码 jdbc.url=jdbc:mysql://localhost:3306/fitness_db?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai jdbc.username=root # 改成你自己的 MySQL 密码 jdbc.password=你的密码

这段配置里，useUnicode=true和characterEncoding=utf8解决中文乱码问题，不加上会出现数据库里存的是中文、Java 读出来变成问号的经典翻车现场；serverTimezone=Asia/Shanghai解决 MySQL 8.x 的时区报错，不加会在启动时报 The server time zone value 相关异常。如果你的 MySQL 是 8.x 版本，driver 需要改成com.mysql.cj.jdbc.Driver，这是很多人拿到旧资源后用不起来的原因。改完配置后，建议先写一个简单的测试类或者在已有 Controller 里临时加一个查询接口，确认后端能连上库再启动完整服务，避免把问题混在一起排查。

提示：改完 db.properties 后，记得确认 IDEA 是否已经把它添加到构建路径。有些同学改了文件但 target 目录里还是旧配置，导致启动后连的还是旧数据库地址，这种情况在 IDEA 里执行一次 Build -> Rebuild Project 就能解决。

3.3 小程序端的三处配置：AppID、局域网地址、域名校验开关

小程序端改配置的地方比较集中，主要在 app.js 的 globalData 和 project.config.json 里。首次打开项目时，微信开发者工具会要求填写 AppID，你有两个选择：用测试号或者用自己注册的小程序 AppID。测试号适合本地调试，但部分 API（比如获取手机号）不能用；自己的 AppID 功能最全，但需要在小程序后台确认 AppID 已正确填入。紧接着把请求地址从后端配置里读出来，统一放到 app.js 中：

// app.js App({ globalData: { // 后端服务根地址，改成你自己的局域网 IP，不能写 localhost baseUrl: 'http://192.168.1.100:8080/fitness', userInfo: null, token: '' } });

这里的关键点是 baseUrl 必须写你电脑的局域网 IP，不能写 localhost 也不能写 127.0.0.1。因为小程序开发者工具模拟器里访问 localhost 指向的是工具所在的电脑，但在真机预览时 localhost 指向的是手机自己，必然失败。确定 IP 的方式是在命令行执行 ipconfig（Windows）或 ifconfig（macOS）查看当前局域网地址，然后在浏览器里访问http://IP:8080/fitness/api/course/list验证后端可达。最后，在开发者工具右上角点击「详情」，勾选「不校验合法域名、web-view（业务域名）、TLS 版本以及 HTTPS 证书」，这一步在本地调试阶段必须打开，否则wx.request会直接报 url not in domain list。这三个配置都改完后，进首页应该能看到课程列表数据；如果还是空白，优先检查电脑防火墙是否放行了 8080 端口，以及后端是否启在 8080 端口上。

4. 核心业务不是背代码：登录、预约、后台管理三条链路的实现逻辑

下面选三个最有代表性的业务点：微信登录、课程预约、后台 CRUD。它们分别对应「用户怎么进来」「核心交易怎么保证」「管理端怎么兜底」，也是答辩被问得最频繁的环节。

4.1 微信登录的服务端实现：从 wx.login 到 openid 的完整链路

微信小程序的登录和传统网页的账号密码登录完全不同，它不需要用户输入用户名密码，而是通过微信官方提供的 code 换 openid 机制。流程是：小程序端调用wx.login获取一个临时凭证 code，把 code 传给后端；后端拿这个 code 加上小程序 AppID 和 AppSecret，请求微信的 jscode2session 接口，换取 openid 和 session_key；最后根据 openid 查用户表，查到就更新登录信息，查不到就自动注册一个新用户。

@RestController @RequestMapping("/api/user") public class UserController { @Autowired private UserService userService; @PostMapping("/login") public Result login(@RequestBody LoginRequest request) { String code = request.getCode(); if (StringUtils.isEmpty(code)) { return Result.error("code不能为空"); } // 用 code 向微信接口换取 openid String openid = userService.getOpenid(code); // 根据 openid 查找用户，不存在则自动注册 User user = userService.findOrCreate(openid); // 生成会话 token 返回给小程序 String token = userService.generateToken(user.getId()); return Result.success(token); } }

这个登录接口有两点值得答辩时展开说。一是 code 是一次性的，有效期只有五分钟，所以后端不能缓存 code，必须每次登录都实时请求微信接口；二是后端不应该把 openid 直接返回给小程序端，因为 openid 是用户在小程序体系内的身份标识，暴露后存在被伪造请求的风险，所以要用 token（通常是一串随机 UUID 或 JWT）作为会话凭证，后续请求只认 token 不认 openid。我见过某同学的项目直接把 openid 当 token 用，答辩老师顺着问了一句「这个值如果泄露了怎么办」，节奏就乱了。上面代码里userService.getOpenid(code)内部封装了对微信接口的 HTTP 调用，注意这一步要设置超时时间，微信接口偶尔会出现慢响应，超时无响应时要给用户一个友好的「登录失败，请重试」提示。

4.2 课程预约的库存处理：用事务和条件更新解决超卖问题

预约功能是这个项目的业务核心，也是并发问题最容易暴露的地方。当多个用户同时预约同一门还剩一个名额的课程时，如果代码只是先查余量再判断再插入，就会出现两人同时查到余量为 1，同时通过判断，最终超卖。解决思路有两个层次：事务保证原子性，用条件更新的方式保证并发正确性。

@Service public class CourseServiceImpl implements CourseService { @Autowired private CourseMapper courseMapper; @Autowired private AppointmentMapper appointmentMapper; @Override @Transactional(rollbackFor = Exception.class) public boolean bookCourse(Long userId, Long courseId) { // 1. 扣减库存，用受影响行数判断是否抢到名额 int rows = courseMapper.decreaseStock(courseId); if (rows == 0) { return false; // 课程已满或不存在 } // 2. 写入预约记录 Appointment appointment = new Appointment(); appointment.setUserId(userId); appointment.setCourseId(courseId); appointment.setStatus(1); appointmentMapper.insert(appointment); return true; } }

对应 Mapper 里的扣减 SQL 是关键，它不能拆成「查余量-判断-更新」三步，而要合并成一条条件更新语句：

-- 条件更新：只有当前人数小于上限时才会执行，返回受影响行数 UPDATE t_course SET current_count = current_count + 1 WHERE id = #{courseId} AND current_count < max_count

这条 SQL 执行后返回受影响行数，只有 1 和 0 两种结果。为 1 说明当前余量还够，本次更新抢到了名额；为 0 说明课程已满或者课程不存在。这里没有用 SELECT ... FOR UPDATE 的悲观锁，而是用条件更新天然实现了乐观锁的效果，并发性能更好，代码也更简洁。配合@Transactional，如果第二步插入预约记录失败，第一步的库存更新会自动回滚，不会出现「预约记录没有但库存被扣了」的脏数据。我在实际指导中见过一个常见错误：把 update 语句写在 Service 里，库也扣了也没用事务，结果预约记录插入失败时库存已经变了，这种问题后期很难排查。

4.3 后台管理端：教练排课与会员管理的 CRUD 边界

后台管理是 SSM 项目的传统主场，资源包里的管理端可能是 Web 页面（JSP）也可能是另一套接口。不管是哪种，功能边界基本一致：管理员登录、课程上下架、教练信息维护、预约记录查看和取消。做管理端时要注意一个分层原则：Controller 里只处理请求参数和返回结构，业务规则放到 Service 里，数据访问交给 Mapper。有些同学图省事，直接在 Controller 里写 SQL 逻辑，答辩老师拿一段代码问「这条 SQL 的参数从哪来的」就答不上来了。

一个典型的排课接口会是这样的：

@PostMapping("/admin/course") public Result createCourse(@RequestBody Course course) { // 校验：教练必须存在，开始时间不能晚于结束时间，课程名不能为空 courseService.createCourse(course); return Result.success(); }

排课接口的核心是后端校验，而不是把表单数据直接塞进数据库。教练 ID 是否存在、时间字段是否合法、价格是否为负数，这些都需要在 Service 层逐一校验并给出明确的中文错误提示。另外管理端的权限控制一般用拦截器实现，判断请求头中的 token 对应的用户 role 是否为管理员，这是比前端隐藏按钮更可靠的控制手段。前端只是体验上的限制，后端拦截才是安全边界，这一步也是答辩老师常问的知识点。如果资源包里的后台没有做拦截器，建议自己补一个，代码量不大但能明显提升项目的完整度。

5. 避坑清单：这套健身毕设从启动到演示最容易翻车的五个环节

我把带过的同学和自己在调试这套技术栈时踩过的坑按频率排了个序，每一条都是「现象 → 原因 → 解决」的完整链路，对照着排查，能省下不少时间。

5.1 现象：Maven 依赖下载卡住或 jar 包冲突，Tomcat 一直起不来

现象是 IDEA 里点启动后，控制台卡在 Downloading 状态很久，或者好不容易下完又报 java.lang.NoSuchMethodError / ClassNotFoundException，项目起不来。原因是默认 Maven 中央仓库在国内访问不稳定，而且几个框架的依赖之间版本不匹配。解决办法是第一步先给 Maven 配置一个能快速访问的公共镜像源，在 Maven 安装目录的 conf/settings.xml 的 mirrors 节点中加入镜像配置；第二步统一 Spring 相关依赖的版本号，用 pom.xml 里的 properties 属性管理 spring-webmvc、spring-jdbc、spring-tx 的版本，让它们保持一致。配置完成后重建索引并重新加载项目，如果还有版本冲突，重点检查 mybatis-spring 和 Spring 主版本是否兼容。用资源包里的 pom.xml 时，不要随意升级某个依赖的版本，经历一次就知道了：为了用新语法把 Spring 升一个大版本，结果 mybatis-spring 适配不过来，越改越乱，最后全部回退才恢复。

5.2 现象：小程序端请求全部 fail，后端日志却显示收到了请求

现象是小程序控制台报 request:fail，但后端打印出了请求日志，看起来非常矛盾。原因是 fail 有两种完全不同的情况，一种是网络层面没连上，一种是服务器返回了非 2xx 状态码。如果后端有日志，说明请求已到达服务器，问题大概率出在响应环节，比如接口抛了异常返回 500，或者返回的 JSON 格式不对导致 wx.request 解析失败。另一种常见情况是后端没有启动在 8080，而是被 IDE 随机分配了端口。处理方法是先把后端完整启动日志翻出来，确认端口号；然后用浏览器直接访问这个接口的 URL，看返回内容是否正常 JSON；最后回到小程序，让 fail 回调里打印完整错误对象，而不是只打一个 fail 字符串，这样能区分是状态码问题还是数据解析问题。小程序里打印了 res 的完整信息后，再对照后端日志排查，定位会直接很多。

5.3 现象：数据库里的中文全是问号或乱码

现象是管理后台录入中文后，页面显示正常，但数据库里变成了 ??，或者反过来数据库正常、页面显示乱码。原因是字符集不一致：连接串没指定编码、表结构不是 utf8mb4、页面本身的编码声明不对，三处只要有一处不一致就可能乱。解决方法是把三个地方的编码统一成 UTF-8。数据库连接串加上 characterEncoding=utf8；表的字符集用 utf8mb4（支持 emoji）；如果是 JSP 页面，在文件头部加<%@ page contentType="text/html; charset=UTF-8" %>，Tomcat 的 server.xml 里也检查一下 URIEncoding="UTF-8"。排查时可以执行SHOW CREATE TABLE t_course;确认 DEFAULT CHARSET 的值，再执行SHOW VARIABLES LIKE 'character_set%';看服务端默认字符集。这种问题一旦出现，改起来不复杂，但耗时会很长，所以建库建表时就统一好是最值的。

5.4 现象：开发者工具里登录正常，真机预览却登录失败

现象是模拟器里流程顺畅，扫码预览到手机上后，登录接口一直超时或报错。原因是手机和电脑不在同一网络环境下。常见两种情况：手机连着 4G/5G 网络，而电脑在局域网里，手机访问不到电脑的局域网 IP；或者手机和电脑连了同一个 Wi-Fi，但电脑开启了防火墙拦截了入站请求。解决方法是先确认手机和电脑连同一个 Wi-Fi，再在手机浏览器里访问电脑的局域网 IP 加端口，能打开后端接口才说明网络通路是好的。最后还要检查后端服务监听的地址，确认 Tomcat 绑定的不是 127.0.0.1，而是 0.0.0.0 或局域网 IP。这一条是演示前必须验证的，不然到答辩现场才发现手机连不上，就真的没有后悔药了。

5.5 现象：预约课程成功后，余量人数没有变化，或者取消预约后余量不恢复

现象是前端提示预约成功，但课程列表页显示的余量和预约前一样；或者取消预约后再看余量，人数没有减回去。原因是第一个场景通常是流程里少了「更新余量」这一步，只插入了预约记录而没有执行 UPDATE 语句；第二个场景则往往是取消预约的业务里漏掉了余量的自增操作，或者事务没提交导致回滚。解决办法是对照库存字段的变更链路检查：预约成功后应该有UPDATE t_course SET current_count = current_count + 1，取消预约后应该有UPDATE t_course SET current_count = current_count - 1。同时确认 Service 方法上有@Transactional，两个步骤在同一个事务里执行。排查技巧是在 MyBatis 的 Mapper XML 里给 update 语句加上返回值类型 int，然后在 Service 里判断返回值等于 1 才继续后续流程，这样每一步的成败都在代码层面留有依据。

6. 高分收尾：演示视频与答辩现场的实战技巧

资源包里带的演示视频，大多数人的用法是看一眼就丢到一边，这有点浪费。更好的做法是把它当成分镜脚本：打开播放器，记录每个操作在第几秒出现，操作内容是什么，界面发生了什么变化，然后按这个节奏在真实环境里重新过一遍。我一般这样安排演示顺序：先讲一个用户痛点，比如想约课但不知道哪个时间段还有余量；然后走一遍用户端完整流程，登录、浏览课程、预约成功、查看预约记录；再切到后台管理端，排课、上下架课程、查看预约列表；最后回到数据库层面展示关键表。这一套走下来大概五到八分钟，节奏紧凑、逻辑自洽，比打开页面逐个点按钮强得多。

代码讲解不要从 pom.xml 开始，也不要把整个项目结构念一遍。选一条最亮眼的主链路：用户点击预约按钮 → 小程序发 wx.request → 后端 Controller 接参 → Service 扣库存 → Mapper 执行 UPDATE → 返回结果。沿着这条链路讲，每一个环节都能带出知识点：小程序讲登录态和请求封装，Controller 讲参数校验，Service 讲事务和并发控制，Mapper 讲条件更新 SQL。这条链路讲完，这个项目在答辩老师心里的技术深度就有了。

最后是必答题的准备。答辩最常听到的三个问题其实是送分题：项目哪些部分是你独立完成的；为什么选 SSM 而不是 SpringBoot；预约并发的时候怎么保证不超卖。第一个问题的回答思路是把资源包的代码按模块划分成「自己重写过的」和「在原有基础上改过的」，讲的时候既不要全揽也不要全推，重点说清楚自己动过的每一个类；第二个问题要诚实地说 SSM 更贴近课程教学里的分层思想，同时补充一句自己知道 SpringBoot 是更主流的工程化选择；第三个问题就用第 4.2 节的条件更新 SQL 回答，提到事务和乐观锁两个关键词就足够了。我做毕设那年就是因为没提前准备并发问题，现场被追问到答不上来，从那之后每次带项目都会先问一句：这个问题你自己能不能讲清楚。希望今天这篇能帮到你，少踩一个是一个。

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