概述
引入依赖的代价在长期维护与安全，而非安装那一刻。评估维护活跃度与响应、审查安全态势与许可证、考虑自建等替代、并以理由与复核日期记录决策，可避免无意间背上无人维护的风险。
关键步骤
- 从证据评估维护活跃度、发布节奏与响应。
- 审查安全态势、已知漏洞与许可证。
- 在比较中考虑替代方案，包括自建。
- 记录决策理由并定期复核。
验证
- 决策记录列出标准、所选方案与复核日期。
- 未在无正当理由下采用严重漏洞或问题许可证的依赖。
- 弃维护依赖被明确处理。
- 决策可追溯。
决策点
小而健康的库宜采用，核心且变动频繁的逻辑宜自建；弃维护依赖除非自行接管，否则不应引入。
适用范围
本条目围绕「第三方依赖采用工作流」给出可复制的步骤、验证方式与常见问题，适合需要按此流程落地的工程团队。执行时请结合自身上下文调整命令与阈值，并在变更前后留存证据，便于后续复核与回滚。
建议在正式环境落地前先在预发或隔离环境演练一遍，把关键观测指标与负责人一并记录，确保出现异常时能快速定位并恢复。
npm view some-lib version time.modified maintainers
# assess activity, then record the adoption decision