0. 项目背景
项目类型：中小型 Web 管理系统。目标：完成从需求分析、开发、部署到稳定运行的闭环。初始状态：需求描述模糊、模块边界不清、交付风险高。
1. 关键问题拆解
问题 1：需求频繁变化
症状：每周都新增字段和流程，导致返工。
问题 2：模块职责混乱
症状：前后端接口重复改，联调成本高。
问题 3：上线不稳定
症状：环境不一致、日志不可追踪，问题难定位。
2. 方案设计（可复用）
- 先做 MVP 范围收敛：只保留核心链路，非核心需求进入迭代清单。
- 接口先行：统一请求参数、响应结构、错误码。
- 分层日志：业务日志、错误日志、部署日志独立管理。
3. 架构图（示意）
架构说明：Client(Vue) -> Nginx -> Spring Boot -> MySQL/Redis -> Backup+Log。
4. 实施步骤（按周）
- 第 1 周：需求收敛 + 数据模型
- 第 2 周：核心流程开发 + 权限基础
- 第 3 周：异常处理 + 日志完善 + 性能初调
- 第 4 周：部署上线 + 回滚预案 + 操作手册
5. 结果与指标
- 首版按期上线（核心功能完整）
- 联调返工次数下降
- 线上问题可快速定位
6. 经验复盘
- 先“砍范围”再“堆功能”。
- 接口规范能显著降低协作成本。
- 日志体系应在开发期就纳入。
7. 下一步优化
- 增加自动化测试覆盖核心链路
- 引入 CI/CD，降低发布风险
- 补齐监控告警（CPU、内存、慢查询）
补充：上线稳定性架构
核心链路：需求澄清 → 任务拆分 → 日志与监控 → 灰度验证 → 复盘改进。
执行步骤（可直接复用）
- 先写最小可交付范围（MVP）
- 为关键路径补日志与错误处理
- 上线前做一次回归清单
- 上线后24小时跟踪异常指标
8. 模块拆分与职责边界（实战版）
为了避免“谁都能改、谁都背锅”的局面，我把系统拆成 4 个可独立迭代的模块：
- 用户与权限模块：登录、角色、权限校验（最小权限原则）
- 业务流程模块：核心表单流转、状态机、审批动作
- 数据与缓存模块：MySQL 持久化 + Redis 热点缓存
- 观测与运维模块：日志、监控、备份、告警
图示说明：所有模块只通过明确接口交互，禁止跨层直接访问数据库。
9. 接口约定与错误码（可复制模板）
统一返回结构：
{
"code": 0,
"message": "ok",
"data": { ... },
"traceId": "req-20260324-xxxx"
}错误码建议：
- 1001 参数错误（前端可直接提示）
- 2001 业务冲突（状态不允许）
- 3001 鉴权失败（跳登录）
- 5001 系统异常（附 traceId）
10. 上线前检查清单（最小可执行）
- 数据库迁移脚本先在预发布环境演练并回滚一次
- 核心 API 压测到目标峰值的 1.5 倍
- Nginx、应用、数据库时间同步（避免签名与日志错位）
- 设置监控阈值：5xx、慢查询、CPU、内存、磁盘
- 准备“一键回滚”步骤文档，值班同学可独立执行
11. 部署与回滚流程（示例命令）
# 1) 拉取并发布
./deploy.sh release-2026-03-24
# 2) 健康检查
curl -f http://127.0.0.1:8080/health || exit 1
# 3) 异常时快速回滚
./deploy.sh rollback release-2026-03-23重点：上线不是“代码跑起来”就结束，必须把回滚当作同等重要的主流程。
12. 复盘模板（每次上线后都能复用）
- 发生了什么：按时间线列事实
- 为什么发生：根因与诱因分开写
- 怎么避免再次发生：必须落到可执行动作
- 负责人和截止时间：避免“下次再说”