技术栈怎么选：优先匹配现有项目、团队和部署环境

技术栈先满足现实约束

已有仓库、团队经验、部署平台、数据要求和维护期限通常比“最新框架”更重要。新技术带来的学习、构建、观测和招聘成本必须显式比较。

现有系统兼容

是否能复用语言、运行时、鉴权、数据库、组件和监控；迁移成本由谁承担。

把涉及的文件、目录、版本、命令和实际输出写进记录；代码变化同时保留 diff 与测试结果。

团队能力

至少两人能维护吗，测试和排错工具是否熟悉，交接材料能否得到。

确认“团队能力”已经有可回查结果，再进入“部署与运行”；依据仍然来自猜测时，把缺口单列并停在当前步骤。

部署与运行

目标平台支持的运行时、构建、冷启动、存储、网络和费用边界是什么。

确认“部署与运行”已经有可回查结果，再进入“数据与安全”；依据仍然来自猜测时，把缺口单列并停在当前步骤。

数据与安全

事务、并发、权限、合规、备份和恢复需要到什么程度。

确认“数据与安全”已经有可回查结果，再进入“最小原型实测”；依据仍然来自猜测时，把缺口单列并停在当前步骤。

最小原型实测

用同一纵向功能在候选栈中验证开发、测试、构建和部署，不用简单 Hello World 比较。

需要修改时先限定文件和行为范围，无法说明回滚方式或影响面的动作先不执行。 完成后把证据归入“技术选型约束表”。

选择表要写淘汰理由和复核点

记录硬约束、加分项、未知项和最小原型结果。选择后冻结一段时间，除非出现新的阻断证据，不因流行度频繁换栈。