应紧盯composer show -a和Packagist页面的Last update：若包超6个月未更新且存在未关闭critical bug，即标记“观望”；维护活跃度看真实commit时间、PHP版本兼容性、conflicts字段、why依赖链、type适配性、autoload规范性、license全文核对及上下文动态匹配。
别靠直觉选包，composer show -a 和 Packagist 页面右上角的 Last update 是你最该盯住的两个信号。一个半年没更新、issue 区堆着未关闭的 critical bug 的包，哪怕下载量百万，也先标记为“观望”。
怎么看包是否还在 actively maintained
维护活跃度不是看 GitHub star 数，而是看真实动作：
-
Last update超过 6 个月没动，且open issues里有带critical或security标签的未关闭项，基本可判定已半废弃 - 点进 Packagist 页面底部的
Source链接，直接看 GitHub 的Commits时间轴——最近一次 commit 是 2024 年还是上周，比 README 里写的“actively maintained”管用十倍 - 检查
composer.json中的require字段：如果还锁着"php": "^7.4"，而你项目已上 PHP 8.2，它大概率没跑过新版本兼容测试
怎么快速验证包在你项目里会不会冲突
文档写得再好，也不如本地命令吐出的真实依赖关系：
- 运行
composer show -a vendor/package-name，重点看输出里的conflicts字段——它比包作者写的 README 更权威，会暴露它暗中排斥哪些版本（比如symfony/console:^6.0） - 用
composer why vendor/package-name确认这个包是不是真被调用：如果返回no dependencies，说明它只是被其他包带进来的“幽灵依赖”，升级或替换时优先级最低 -
type字段决定能否乱塞：值为laravel-package却用在 Symfony 项目里，轻则服务注册失败，重则容器编译报错
autoload 配置暴露了包的工程成熟度
自动加载方式不是技术偏好问题，是开发体验和部署稳定性的分水岭：
- 若
composer.json的autoload只写了files或干脆为空，意味着它没走 PSR-4 自动发现，你得手动require，热更调试成本陡增 -
psr-4是标准做法，适合开发；classmap适合生产环境优化，但前提是它真生成了完整映射——有些包只在composer install --optimize-autoloader时才触发，本地开发根本测不到 - 注意
autoload-dev是否存在：没有它，说明作者连自己的测试类都不愿规范组织，代码质量存疑
license 和安全审计不能跳过人工核验
composer licenses 输出的字符串只是起点，不是结论：
-
license值为SEE LICENSE IN LICENSE.md时，必须打开对应文件全文核对——SPDX 官方列表（https://spdx.org/licenses/）才是许可证兼容性的唯一依据 -
composer audit默认只报已知高危 CVE，对模糊许可、废弃包（abandoned）、弱加密等不敏感；真正可用的是composer validate --with-dependencies+ 手动查conflicts - 用
jq -r '.[] | select(.license | contains("GPL"))' licenses.json这类脚本批量筛 license，比肉眼翻几十页 Packagist 页面靠谱得多
最常被忽略的一点：包的质量不是静态分值，而是你项目上下文里的动态匹配。PHP 8.2 下跑得稳的包，在你用了 opcache.preload 的场景里可能因 autoload 顺序出问题；Laravel 11 的 bundle 在非框架项目里连 ServiceProvider 都注册不上。别信“高星+高下载”，信 composer show -a 输出的每一行元数据。
