项目

最初在“沿用历史 Java / NestJS 服务”与“收拢到 FastAPI + LangGraph 主线”之间选择了后者：AI 编排、工具调用和流式响应更适合靠近 Python 生态，也让当前服务边界更容易理解。代价是旧服务无法立即消失，前端又同时覆盖 Vue、Next.js 和 Flutter，认证、协议和联调成本随之上升。

这里选择“维护小而明确的多套模板”，而不是把所有后端能力塞进一个万能脚手架：Spring Boot、FastAPI 和 Agent 项目各自保留符合生态的启动方式，同时共享统一响应、异常处理和常用基础设施。后来发现模板会把早期判断固化，依赖升级和特殊业务适配仍需要人工取舍，这是复用带来的维护代价。

博客在“接入数据库或 CMS”与“继续把内容放在 Git 管理的 MDX 文件”之间选择了后者：文章、项目和页面内容可以一起审阅、迁移，并且静态构建天然适合 Vercel。代价是 frontmatter、搜索索引、目录和内容校验都需要自己维护；当内容规模继续增长，编辑体验会成为比渲染性能更早出现的约束。

这个项目选择把管理端、小程序和服务端拆成清晰的客户端与服务边界，而不是先做一个只覆盖单端的演示：这样可以同时练习订单、菜品、套餐、统计和地址管理等完整业务流程。代价是多端状态、接口契约和联调问题会被放大，任何一个核心字段变化都可能牵动管理端、小程序和后端。

这里选择“集中维护一个可搜索的技能仓库”，而不是把经验零散地留在不同项目的 README 中：新工具可以先沉淀，再按主题回看和复用。代价是清单很容易变成只收藏不实践的目录，只有持续补充使用场景、命令和边界，它才会从书签集合变成真正能减少决策成本的工作资产。