技术调研方法论 · 参考文档

技术调研手册（一页速查）

研究任何一门陌生技术都走这条漏斗。打印贴墙。方法详解见第 1 课。

类型：参考 / 检查单适用：开源项目、框架、中间件、SaaS 选型

第 0 步：调研问题句（没有它不开工）

【技术 X】能否在【我们的场景】下满足【可度量判据：性能/集成/维护…】，
且不触犯【红线约束：license / 合规 / 技术栈 / 预算】？

写不出问题句 = 还不知道为什么调研，先回去把需求想清楚。默认答案永远是"不引入"——新技术要花创新代币（McKinley），举证责任在它。

只判断"这个项目会不会死"，不看功能细节。任一红线不过直接淘汰。

检查项	看哪里	过/不过的判据
定位	README 第一段 + 官网	它的自我定位与你的诉求对口，不是"勉强能凑合"
License 🚫	LICENSE 文件	允许你的使用方式（商用/闭源/分发）——红线，一票否决
维护方	组织主页、贡献者分布	机构/基金会/多公司共维护 > 单公司 > 个人；警惕 bus factor = 1
发版节奏	Releases 页	有可预期的节奏（如半年一版）；一年无发版且无解释 = 危
Issue 响应	抽查 10 条近期 issue	看维护者响应速度，不看 issue 总数（大项目 issue 天然多）
文档生态	官方文档、社区渠道	有系统文档（非只有 README）；有活人回答问题的社区
自动辅助	OpenSSF Scorecard	`scorecard --repo=github.com/org/repo`，26+ 项安全/维护实践 0-10 分

⚠️ star 数、提交总数是历史人气，不是未来承诺，只作弱信号。产出：候选 N → 2~3 个。

维度（来自问题句判据）	权重	候选 A	候选 B	证据出处
核心能力匹配度	×3	1~5 分	1~5 分	文档链接
性能（按你的量级）	×3	存疑→spike
与现有栈的集成成本	×2
团队学习曲线	×2
运维/升级成本	×1

产出：矩阵得分 + 存疑项清单（文档回答不了、必须实测的问题）。