CHAPTER 12 · FINAL REVIEW
12
综合项目验收与代码鉴赏
这不是继续新增技术点的一章，而是回到完整相册系统本身：它为什么这样设计，AI 生成的代码哪些能用，哪些必须修改。
课程主线
这套课程已经走完一个全栈项目的完整生命周期。
从这里开始，继续堆更多技术名词反而会稀释主线。最后要看的不是“又学了一个工具”，而是能否审查一套系统、解释关键决策、驾驭 AI 生成的代码。
最终验收清单
验收不是看页面能不能点，而是看系统是否站得住。
功能完整性
注册登录、创建相册、列表分页、照片上传、公开和私有访问是否形成闭环。
前后端结构
页面、组件、API、类型是否分离；后端 Handler、Service、Repository 是否职责清楚。
权限边界
权限是否真正落在服务端；查询、更新、删除是否包含用户归属条件。
SQL 与索引
是否存在无分页、SELECT *、深分页、N+1；索引是否服务于真实查询。
OSS 安全
是否使用 Private Bucket；Object Key 是否由后端生成；是否避免泄露 AccessKey 和签名 URL。
上线构建
Dockerfile 是否使用多阶段构建；镜像里是否包含源码、.env 或开发工具。
联调与发布
前端是否使用 /api；开发环境是否使用 Vite Proxy；正式环境是否由 Nginx 或网关转发。
可观测性与性能
是否有 Request ID、结构化日志、健康检查；是否能定位慢在前端、Go、MySQL、Redis 还是 OSS。
代码鉴赏
AI 生成的代码，先不要问“能不能跑”，先问“能不能维护”。
所有逻辑写在一个文件里
要拆边界在哪里？页面、请求、业务和数据访问是否混在一起？
接口能返回 JSON
不够是否分页？是否统一响应？是否隐藏内部错误？是否处理空列表？
JWT 登录成功
不够是否校验数据归属？是否存在水平越权？前端隐藏按钮是否被当成权限？
Dockerfile 能构建
继续审是否多阶段？是否把 .env、源码、node_modules 或编译器带入最终镜像？
加了 Redis
先证明瓶颈是否被测量？Key、TTL、失效策略和一致性风险是否清楚？
AI 很适合生成初稿，但工程判断不能外包。代码能跑只是起点，能解释、能维护、能上线、能排查，才是工程能力。
关键工程决策
最终要能解释“为什么这样设计”。
为什么照片不直接放 Go 服务器硬盘？
因为文件生命周期不应绑定某个应用实例，多实例、扩容、可靠性和私有访问都需要独立文件存储。
为什么应用不能用 root 连数据库？
业务服务应该使用最小权限账号，避免一个服务泄露后拥有过大的数据库操作范围。
为什么 Object Key 由后端生成？
Object Key 是权限边界的一部分，前端决定路径可能造成越权、覆盖或非业务目录写入。
为什么正式环境不用 Vite Proxy？
Vite Proxy 是开发工具；正式环境应由 Nginx 或统一网关提供静态资源和 /api 转发。
为什么不能依赖 AutoMigrate？
生产数据库变更必须显式、可评审、可回滚，不能隐藏在服务启动中。
为什么慢了不能直接加 Redis？
Redis 是加速层，不是替代 MySQL 的银弹。没有测量和瓶颈定位，缓存可能只会引入更多复杂度。
最终复盘材料
最后沉淀的不是“代码截图”，而是一份工程说明。
1. 系统功能闭环
2. 前后端项目结构说明
3. 数据库表设计与索引说明
4. API 设计与错误处理说明
5. 登录、JWT 与数据权限说明
6. OSS 上传、访问和安全边界说明
7. 前后端联调与正式部署链路说明
8. 日志、健康检查和故障定位说明
9. 性能瓶颈分析和优化前后数据
10. AI 生成代码的主要修改点
11. 仍然存在的风险和后续改进最终问题
这个系统为什么这样设计？AI 生成的代码哪些能用，哪些必须修改？
- 能解释设计，说明你不是在背代码。
- 能审查 AI 代码，说明你不是只会复制结果。
- 能指出风险，说明你开始具备工程判断力。
- 能提出改进顺序，说明你知道系统如何继续演进。
全栈入门的终点，不是记住更多框架名，而是建立一套从需求、接口、数据、权限、文件、部署、排查到优化的工程思维。