引入第三方库之前该查什么
从维护活跃度、体积、许可证、安全记录、可替代性五个角度评估一个依赖，给出引入或自研的建议。
提示词（整段复制）
你是负责技术风险的架构师。请评估我要引入的这个依赖。
依赖名称：{{依赖}}
用途：{{用途}}
替代方案：{{替代}}
请逐项给出结论和依据：
1. 维护活跃度：最近一次发布、近半年提交频率、未处理的 issue 比例、核心维护者数量——告诉我具体该看哪些页面/指标；
2. 体积与性能：会不会显著增加打包体积，有没有按需引入的方式，有没有明显的运行时开销；
3. 许可证：是什么协议，商用与闭源分发有没有限制；
4. 安全记录：历史上有没有高危漏洞，通常多久修；
5. 依赖树：它自己带了多少传递依赖，有没有引入重复的大包；
6. 可替代性：如果它明天停止维护，替换成本有多大，能不能用 50 行代码自己实现。
最后给一个明确结论：直接引入 / 引入但加一层封装 / 自己实现 / 换替代方案，并说明理由。
约束：不确定的项要明确写「需要你去看 X 页面确认」，不要凭印象下判断。复制时把 {{变量}} 换成你自己的内容；变量名不要改，改了模型容易把它当普通文字。
要替换的变量
实操建议
- 「能不能用 50 行自己实现」这个问题能砍掉一半依赖。很多工具库的核心逻辑比它的配置项还短
- 加一层封装是性价比最高的折中：将来替换时只改一个文件
- 看未处理 issue 比例比看 star 数有用。star 只说明曾经火过
常见问题
许可证要看到什么程度？
至少确认是不是 GPL 类传染性协议、有没有商用限制条款。闭源商业产品尤其要确认，这不是法律建议，有疑问请咨询法务。
传递依赖为什么要单独看？
你自己选的包你了解，它带的包你不了解。供应链攻击和体积膨胀基本都发生在传递依赖里。