技术选型与平衡
一、选型维度：团队能力、生态、演进与锁定风险
团队能力：技术要有人能维护、能排障、能演进。若团队没人熟悉某技术，要么投入学习与招聘，要么选团队已掌握或学习曲线平缓的。避免「为了先进而先进」导致上线后无人能接手。
生态：文档、社区、第三方库、招聘市场是否成熟。生态好的技术遇到问题更容易查、招人更容易；小众技术要评估长期支持与人才供给。
演进：技术路线是否清晰、版本升级是否平滑、是否有弃用或断更风险。选型时看一眼 roadmap 与社区活跃度，避免押注在即将弃用的栈上。
锁定风险（Vendor / Technology lock-in）：过度依赖某一家云、某一种协议或某套私有 API，将来迁移成本会很高。在关键路径上尽量用标准、可替换的组件，或通过抽象层隔离依赖，便于将来换掉。
二、构建 vs 采购 vs 开源
构建（Build）：自己从零或基于底层能力开发。适合差异化核心能力、无合适现成方案、或需要深度可控的场景。代价是研发与维护成本高，要评估是否值得。
采购（Buy）：购买商业产品或 SaaS。适合通用需求（如 CRM、邮件、监控）、希望快速上线且可接受定制边界。要关注合同、SLA、数据主权与退出成本。
开源（Open Source）：采用开源组件或基于开源二次开发。成本低、可定制、无单家绑定，但需要自己维护与跟进社区。要选活跃、许可合规的项目，并评估长期维护能力。
实际项目中常混合：核心差异化自建或基于开源，通用能力采购或成熟开源。选型时明确「必须自己掌控」与「可以外包/采购」的边界。
三、技术雷达与持续学习
技术雷达（Tech Radar）是 Thoughtworks 推广的一种呈现方式：把技术（或工具、平台、语言）按环（Adopt / Trial / Assess / Hold）与象限（如 Languages & Frameworks, Platforms, Techniques）分类。Adopt 表示建议采用；Trial 可小范围试用；Assess 值得关注与评估；Hold 暂不推荐。团队可维护自己的雷达，定期更新，对齐「什么在推广、什么在试、什么先别用」，避免各说各话与盲目跟风。
持续学习：技术迭代快，选型与架构能力需要持续更新。通过雷达、内部分享、会议与开源参与保持对行业的敏感度；学习时结合业务场景思考「能否解决我们的问题」，而不是为学而学。
技术雷达四环
- Adopt：建议采用，团队已验证
- Trial：可小范围试用，待观察
- Assess：值得关注与评估
- Hold：暂不推荐，谨慎使用
四、避免追逐热点与从众
不追热点：新技术、新框架往往有营销与社区热度，但不一定适合当前项目。选型要看问题匹配度（是否解决我们的痛点）、成熟度与风险（是否过早采用）、团队与生态，而不是「最近很火」。
不从众：别人用得好不代表你就该用。公司规模、业务阶段、团队构成不同，照抄大厂或网红栈可能带来不必要的复杂度或锁定。选型要有自己的依据与文档（可写成 ADR），便于事后复盘与迭代。
避免追热点与从众
- 看问题匹配度与成熟度，而不是「最近很火」
- 别人用得好不等于适合你；规模、阶段、团队不同
- 选型依据写进 ADR，便于复盘与演进
一句话： 选型要在团队能力、生态、演进、锁定风险间权衡；构建/采购/开源可混合，核心自控、通用可外采。技术雷达与持续学习帮助对齐与更新；不追热点、不从众，选型要有依据、可追溯。
五、小结
选型维度：团队能力、生态、演进、锁定风险。构建/采购/开源：自研控核心、采购或开源补通用，常混合。技术雷达：Adopt / Trial / Assess / Hold，团队对齐与更新。持续学习：结合业务场景，不为学而学。不追热点、不从众：依据问题与约束选型，写 ADR 可追溯。下一章是从工程师到技术负责人，讲个人贡献者与带人带项目的区别、技术决策与路线图、培养他人与课程回顾。