答辩秘书把记录本翻开时，评委通常不会先问你的 SpringBoot 版本，而是直接指着演示界面问："你系统里这 200 条违规占座记录是哪来的？"如果回答是后台定时写了随机数脚本，答辩成绩基本就定在及格线边缘。选题可行性评估的第一原则，不是挑一个最前沿的词库，而是确保系统里的业务状态能由真实动作自然触发，且单机 MySQL 能把这些事实存下来。
图：请求调用链 · 私信消息轻量化查询流（说明放弃复杂长连接后依靠HTTP轮询拉取数据库消息）
图：数据流示意 · 推荐算法退化为单体加权（展示砍掉跨进程Python服务、改用单表SQL加权…
图：落地路径示意 · 违规状态生成链路收敛（说明规避虚构硬件传感器、改为巡检员手动入库的合规链…
问答实录一：数据来源与多角色闭环
自习室预约系统开题时，常见的错误写法是包含"学生端、宿管端、图书馆管理员端、校级监控端、物联网设备采集端"。答辩老师只问了一个问题："如果下午两点学生 A 没来，系统怎么知道他没来？"
现场卡住的原因很直接：你既没有接闸机 SDK，也没有在教室门口挂二维码，纯靠后端写一个 @Scheduled(cron = "0 0 14 * * ?") 把状态硬改成违约。在评委看来，这个功能是虚构的。没有输入源的业务，写再多接口也是空转。
改法是立刻砍掉硬件依赖和多端联动，把业务收敛为纯人工登记或同端操作：
-- 适度可行的违约认定：由巡检员手动输入凭证，单表记录
CREATE TABLE `seat_violation` (
`id` BIGINT NOT NULL AUTO_INCREMENT,
`seat_id` INT NOT NULL,
`student_no` VARCHAR(20) NOT NULL,
`reporter_no` VARCHAR(20) NOT NULL,
`violation_time` DATETIME NOT NULL,
`status` TINYINT NOT NULL DEFAULT 0 COMMENT '0-待审核 1-确认 2-撤销',
PRIMARY KEY (`id`),
INDEX `idx_student` (`student_no`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
把"物联网自动感应违规"改成"值日管理员按编号人工点名提交"，数据来源就成立了。系统不再依赖不存在的硬件输入，评委问起来，你可以指着测试账号说："这是巡检员账号录入的真实测试数据。"
问答实录二：推荐算法退化为条件加权
另一个高频翻车点是失物招领或二手交易里的"协同过滤推荐"。老师会追问第二个问题："你这套算法在冷启动时靠什么计算？矩阵稀疏度是多少？"
很多同学为了在开题报告里写上 Python、FastAPI 和 TensorFlow，强行引入了一套跨进程调用。Java 业务层把物品标题用 HTTP 发给 Python 服务，Python 返回推荐 ID 列表，Java 再去 MySQL 查详情。一旦 Python 虚拟环境报错或者端口占满，整个项目连登录后的首页都打不开。
| 维度 | 跨进程混编方案（易翻车） | 单体 SQL 属性过滤（唯一推荐） |
|---|---|---|
| 依赖环境 | JDK 17 + Python 3.10 + PyTorch | JDK 17 + MySQL 8.0 |
| 数据规模依赖 | 至少需要上千条用户点击行为日志 | 10 条基础分类数据即可演示 |
| 联调风险 | JSON 序列化报错、跨域、进程保活 | 0 跨进程通信，本地必定可跑 |
| 答辩评委质疑点 | "矩阵稀疏怎么解？冷启动怎么处理？" | "按地点和时间优先排序，逻辑清晰" |
唯一的推荐做法：停掉外部 Python 脚本，把所谓"协同过滤"退化为基于分类、地点与时效的加权排序。代码在 SpringBoot 内部直接执行：
// 示例：基于分类匹配与时间衰减的兜底查询，单表即可跑通
@GetMapping("/items/recommend")
public List<LostItem> getRecommendItems(@RequestParam String category, @RequestParam String campusArea) {
// 伪算法退化为多条件加权：同校区权重 60%，同分类权重 30%，三天内发布权重 10%
return lostItemRepository.findActiveItemsByWeight(category, campusArea, LocalDateTime.now().minusDays(3));
}
这行代码没有任何高深模型，但它在本地 Tomcat 启动时 100% 成功。只有在一种条件下我收回这个建议：你的导师明确要求论文必须挂靠其国家自然科学基金课题的某个深度学习模型指标。若只是普通工程类毕设，写跨语言脚本就是给自己埋雷。
选型死胡同：从 WebSocket 消息总线撤退到短轮询
在做校园失物招领系统的"在线私信"模块时，最初的设计是接入 Netty 与 WebSocket，希望实现实时的即时聊天。实际联调时遇到了死胡同：前端 Vue 刷新页面导致连接断开、重连逻辑在开发机上频繁触发握手异常，且多端 token 校验在握手拦截器里拿不到标准的 Header，两整天都在查为什么 Sec-WebSocket-Protocol 报 403。
停掉这个方向的原因很简单：毕设演示只需要两台浏览器窗口同时打开，A 发一条消息，B 能看到就行。换成 Axios 配合 3 秒一次的定时器查询未读消息表，只用了 40 分钟就完成了全部联调。答辩时没有任何老师会拿着抓包工具去抓你究竟是长连接还是 HTTP 短轮询，他们只看消息列表能不能刷新出来。
四步完成选题可行性收缩
确定选题前，按照以下有序步骤检查一遍系统设计：
- 审查核心事件触发者：写出核心数据插入的接口，明确是谁发起的请求。如果是"系统自动识别"，必须改成"某特定角色点击确认"。
- 砍掉外部运行环境：凡是需要单独启动 Python 解释器、Redis 哨兵或消息中间件的功能，评估能否用 MySQL 事务与定时任务替代。如果不能，直接从开题报告的功能模块中删掉该小节。
- 收束前端终端类型：放弃"微信小程序 + 移动端 H5 + PC 管理后台"三端并行的规划，统一为单端桌面浏览器展示，分辨率锁定在 1920x1080 纯 Web。
- 设定唯一主链路：整个系统只保留一条完整的状态流转链（例如：发布 -> 申请 -> 审核 -> 归档），其余附加功能全部收敛为标准单表增删改查。
选题做减法并不意味着答辩分低。评委反感的不是功能简单，而是列了十几个前沿模块，演示时却一个都点不开。把精力花在清晰的业务主线上，确保单机无外网依赖下能点通全部流程，才是顺利通过的最稳路径。
相关资料
同类问题里，最常见的不是「不会写某段代码」，而是边界没钉死。下面两张图是公开资料里的结构示意，适合贴在笔记本旁边对照（非代写、不包过）。
Java / Spring Boot 方向可参考站点案例结构
Python 数据分析 / 小系统方向同样适用
