背景痛点：为什么计划书常被导师打回重写
写计划书最容易踩的三个坑，我踩过俩。
- 功能堆砌：把“微信小程序+大数据大屏+AI推荐”全写进标题，结果答辩老师一句“你准备一个人写三个系统？”直接问懵。
- 技术无边：通篇“拟采用前沿技术”，却说不清具体版本、接口、协议，后期换框架时发现 JDBC 连不上 Spring Boot 3。
- 非功能缺失：只写“注册登录”，不提并发、幂等性（同一请求重放多次结果不变）、冷启动（首次调用函数计算要拉 runtime）的保障策略，导致演示时 502 频发。
一句话：计划书不是“愿望清单”，而是“可执行合同”。下面用工程视角把合同拆成可落地的技术条目。
技术选型：先选场景，再选栈
把选题归到三类典型场景，给一张“选型速查表”，5 分钟能定大方向。
Web 信息类（电商、二手交易平台）
- 前端：Vue3 + Vite（热更新快，本科生好调试）
- 后端：Spring Boot 3 + MyBatis-Plus（社区大，教程多）
- 数据：MySQL 8（事务完整）+ Redis（缓存击穿保护）
- 优劣：开发快、资料全，但内存占用高，服务器预算 ≥ 2C4G。
数据分析类（校园舆情预测、图书馆借阅洞察）
- 采集：Python Scrapy（Twisted 异步，下载延迟低）
- 计算：Pandas + JupyterLab（交互式探索）
- 调度：Airflow 2（DAG 可视化，补跑幂等）
- 优劣：算法库丰富，单机可跑 10 万级数据；但 Python GIL 限制高并发，后期想转实时流得换 PyFlink，重构量大。
嵌入式边缘类（智能花盆、无人小车）
- MCU：ESP32-S3（Wi-Fi/BLE 双模，宿舍就能烧录）
- 框架：Arduino 或 ESP-IDF（FreeRTOS 原生任务通知，实时性更好）
- 通信：MQTT on TLS（低带宽、断网重连）
- 优劣：硬件便宜，功耗毫瓦级；但冷启动时间受 SPI Flash 速度影响，日志难导出，调试需逻辑分析仪。
一句话总结：选你玩得转的，而不是“最潮”的；毕业设计时间盒 16 周，冷启动学习成本要算进甘特图。
核心实现细节：把“系统”拆成“合同”
计划书要写到“老师能据此写测试用例”的程度，关键是三份合同：API 契约、模块边界、数据流图。
API 契约 采用 OpenAPI 3.0，先写 YAML 再生成代码，保证前后端解耦（一方改字段，CI 会报错）。
# openapi.yaml 片段 paths: /api/v1/posts:
: post: summary: 发布帖子 operationId: createPost parameters: - name: CreatePostReq in: body schema: type: object required: [title, content] properties: title: {type: string, example: "出二手教材"} content: {type: string, example: "九成新，无笔记"} responses: '201': description: 创建成功 schema: type: object properties: postId: {type: integer, example: 1234}
把文件贴进 Swagger Editor，自动生成交互式文档，计划书附录里截一张图，老师秒懂。 2. 模块边界 用“限界上下文”思想拆微服务，毕业设计规模小，拆成 3 个子域即可：用户、内容、交易。每个子域： - 有自己的 DB（用户域用 PostgreSQL，内容域用 MongoDB，交易域回到 MySQL），避免跨库 JOIN，后期可独立扩容。 - 对外只暴露 REST + 事件，内部表结构随便改，只要契约版本号升位即可。 3. 数据流图 画“时序图”而不是“ER 图”放计划书，强调“数据怎么动”。例如用户下单流程：浏览器 → 网关 → 订单服务 → 库存服务（扣减）→ 支付服务（回调）→ 消息队列 → 仓库服务（发货）
在计划书里用横向泳道图，一眼看出幂等性保障点：支付回调带 idempotency-key，库存扣减用乐观锁 version 字段。 ## 结构清晰的计划书模板 把下面 8 段直接套进 LaTe word 模板，页数控制在 15 页以内，导师阅读成本低。 1. 项目目标（1 行愿景 + 3 条可测指标） - 愿景：打造校内二手书交易小程序。 - 指标：① 并发 300 无错；② 页面加载 < 1.5 s；③ 上线 4 周无宕机。 2. 需求清单（用用户故事，带验收条件） - 作为卖家，我可以在 30 秒内发布图书，以便快速回血。 - 验收：使用 Cypress 录制脚本，连续 10 次发布耗时均值 ≤ 30 s。 3. 技术路线与里程碑（甘特图） - W1-W2 需求冻结 + 原型 - W3-W4 API 契约 + 单元测试 - W5-W8 迭代开发（每两周一个 Sprint） - W9 性能压测 + 安全扫描 - W10 用户试用 + Bug 修复 - W11-W12 论文初稿 + 代码冻结 - W13-W14 论文定稿 + 答辩 PPT 4. 系统架构（C4 容器图 + 时序图） 5. 数据设计（逻辑 ER + 索引清单） 6. 接口定义（OpenAPI YAML 附件） 7. 测试策略（单元、集成、压测、安全） 8. 部署与运维（Dockerfile、CI/CD、回滚方案）  ## 性能与安全：别让“小水管”和“小脚本”毁演示 1. 数据库扩展性 - 读多写少：加只读副本，用 Spring 的 AbstractRoutingDataSource 做读写分离。 - 写压力：提前在计划书里写“当单表 ≥ 200 万行启用 ShardingSphere 分片”，老师一看就知道你考虑过 2 年后。 2. 基础鉴权 - 毕业设计常用 JWT，但一定说明刷新机制：Access Token 15 min + Refresh Token 7 天，存 Redis 可吊销，避免“一旦泄露终身有效”。 - 在网关层统一验证，下游服务只认 X-User-Id header，实现“边缘鉴权、内部信任”。 3. 幂等性 & 冷启动 - 订单创建带 UUID 索引，重复提交报 201 但返回同一 ID，不会多扣库存。 - 若用 Serverless（如阿里云函数）做支付回调，提前 10 min 预热容器，防止老师演示时第一次调用 5 s 才返回。 ## 生产环境避坑指南 1. 版本控制 - Git 主干分三支：main（可上线）、dev（集成）、hotfix（紧急修）。 - 每次合并必须通过 PR + CI，计划书里贴一张 Git Flow 图，老师一看就放心。 2. 依赖管理 - 后端用 Maven/Gradle 锁定版本号，禁止 `LATEST`；前端用 package-lock 锁定，演示电脑没外网也能编译。 - 把 `pom.xml` 或 `package.json` 直接附在附录，方便评审复现。 3. 文档同步 - 代码注释 + ADR（Architecture Decision Record）双保险：注释告诉“代码做了什么”，ADR 记录“为什么选 Redis 而不用 Memcached”。 - 用 Docs-as-Code：Markdown 放仓库 `/docs`，GitHub Pages 自动渲染，计划书给出链接，老师随时查看最新时序图。 4. 回滚策略 - 容器化部署必须写 `helm rollback` 命令，并在计划书里给一行“回滚时间 ≤ 2 min”的承诺。 - 数据库迁移用 Flyway，每条脚本带序号，回滚脚本命名对称 `U__xxx.sql`，演示失败可一键倒退。 ## 结语：把计划书当成第一版“产品说明书” 写完计划书，最好自己照表跑一遍“三分钟测试”：打开 API 文档能调通、打开架构图能定位模块、打开甘特图知道今天该写什么代码。如果三样都 OK，导师基本不会打回；若连你自己都看不懂，那代码多半也跑不通。 选题已定就别犹豫，把上面的模板拆成自己的章节，今晚先把 API 契约写出来，明天让同学用 Postman 点点看——计划书一旦经得起“人肉测试”，后面的 16 周你会感谢现在“多写两行字”的自己。祝你一次答辩通关，代码零回滚。 [](https://t.csdnimg.cn/iKHO) ---
