开题里写了「基于 Spring Cloud 的分布式××平台」，第三周还在配 Nacos，这是本科毕设最高频的烂尾路径之一。本页只回答一件事：怎么专业地拒绝拆服务，同时不让导师觉得你偷懒。默认技术栈见 Spring Boot 页；真难点用 冲突检测 这类业务约束顶上。
结论：一个人、8–12 周、管理系统体量 → 用 Spring Boot 模块化单体。论文可写「按领域拆模块、接口清晰、便于日后扩展」，部署仍是一个应用。
一、为什么本科默认不做微服务
| 维度 | 微服务 | 模块化单体 |
|---|---|---|
| 人力 | 要运维多进程、网关、注册中心 | 一人能盯完 |
| 答辩风险 | 服务怎么拆、分布式事务、调用失败 | 讲清包结构和业务即可 |
| 业务量 | 适合高并发多团队 | 校园管理系统完全够 |
| 工期 | 环境就吃 2–3 周 | 第 2 周可跑主流程 |
二、给导师的 30 秒话术（可改名）
「这题业务量是单校/单院级，当前阶段用 Spring Boot 按用户、预约、统计分包的模块化单体更合适。接口边界按领域划清，以后若要扩展再拆服务。本学期把主流程、权限和冲突检测做扎实，比搭注册中心更能体现工作量。」
- 承认「面向服务」的设计思想：模块边界清晰
- 明确范围：本学期交付可演示系统，不是生产级平台
- 给出可观察产出：主流程、权限、一个真约束、统计图
三、开题怎么写才不挨批
- 题目：删掉「微服务 / 分布式 / 云原生」空词，改成业务名
- 架构：画一张「浏览器 → Boot → MySQL」，模块用虚线框标 users / business / report
- 创新点：写冲突检测、审核流、权限，不写 Nacos
- 展望：一句「后续可按模块演进为独立服务」即可
功能清单模板见 开题功能清单。
四、什么情况才认真考虑拆
- 导师提供现成多服务脚手架，且验收明确要求多进程
- 小组 3 人以上、每人一服务、有统一联调周
- 已有单体跑通，加分项只多一个「网关转发演示」
即使如此，也先保证 一条业务闭环可演示，再拆。演示脚本见 3 分钟演示。
五、答辩被追问怎么答
| 问题 | 答法 |
|---|---|
| 为什么不用 Cloud？ | 业务量与团队规模不支撑；优先交付完整业务。 |
| 以后怎么扩展？ | 模块已按领域分包，边界清晰，流量上来再拆。 |
| 创新点是什么？ | 业务约束（冲突/审核/权限），不是中间件清单。 |
常见问题
本科毕业设计要不要做微服务？
默认不要。一个人、一个学期、校园业务量撑不起拆分。
导师开题已经写了 Cloud 怎么办？
开题修改说明里改成模块化单体，附话术与工期对比；多数导师接受「能做完」。
Docker 算微服务吗？
不算。单体也可以容器部署。Docker 是打包方式，不是架构。