真正影响健康度评估的关键字段只有三个：require、require-dev、autoload；其他如description或keywords仅为辅助信息，不参与健康度判据。
Composer中文元数据里哪些字段真正影响健康度评估
健康度不是看 README 写得多漂亮，而是看 composer.json 里有没有真实约束力的信号。关键字段只有三个：require、require-dev、autoload。其他像 description 或 keywords 属于辅助信息，不能作为健康度判据。
常见错误是把 type 设为 library 就当“规范”，其实它不参与任何依赖解析或自动加载；更危险的是 minimum-stability 设成 dev 还没加 prefer-stable: true，这会让所有下游项目默认拉取不稳定版本。
-
require中出现"php": "^7.4 || ^8.0"比"php": "*"更可信，后者等于放弃 PHP 版本兼容性校验 -
autoload必须含psr-4或classmap，纯files加载方式无法被静态分析工具识别，会导致覆盖率和类型检查失效 -
require-dev里缺失phpunit/phpunit或phpstan/phpstan，基本可判定无持续质量保障机制
用 Composer CLI + JSON 解析做轻量级健康度快筛
不需要跑完整 CI，用本地 composer show --json 和 composer validate 就能筛出 80% 的硬伤。重点不是“是否通过”，而是看报错类型和上下文。
执行 composer validate --no-check-all 能跳过耗时的远程包存在性校验，只验证本地 composer.json 结构合法性；配合 jq 提取关键字段效率更高：
composer show --json | jq '.packages[] | select(.name == "monolog/monolog") | {name, version, require}'
容易踩的坑：直接用 composer show（无 --json）输出是表格格式，不同终端宽度会导致字段截断，jq 解析必然失败。
- 若
composer validate报Invalid package information: license is missing，说明许可证未声明，多数企业合规扫描会直接拒用 -
composer show --json输出中require为空数组[]，比含"php": "*"更危险——意味着该库根本没声明运行环境依赖 - 用
composer info vendor/package --json查单个包时，注意它返回的是已安装版本信息，不是源码仓库的composer.json
PHPStan 和 Psalm 的配置差异如何影响健康度评分权重
静态分析不是“开了就行”，phpstan.neon 和 psalm.xml 的 level 设置直接决定缺陷检出率。Level 5 以上才开始检查泛型和模板类型，而多数中文类库停留在 Level 3，漏掉大量类型隐含错误。
真正影响自动化评估的是配置文件是否存在、是否启用严格模式、以及是否排除了核心业务目录。比如 psalm.xml 里写 <issuehandlers><lessspecificreturntype><severity>info</severity></lessspecificreturntype></issuehandlers>，等于主动关闭关键告警。
- PHPStan 的
level: 8要求所有函数有完整 PHPDoc @return，但很多中文项目用@return mixed应付，这种写法在 Level 7 就会被标为 error - Psalm 默认不检查未声明 return 类型的函数，必须显式开启
<checkclasses>true</checkclasses>才生效 - 两个工具都支持
--no-progress和--no-ansi，这对 CI 环境下的 JSON 输出解析很关键，否则日志混入 ANSI 控制符会导致解析失败
为什么 packagist.org API 返回的 download_count 不可靠
下载量不是健康度指标，而是分发渠道热度指标。Packagist 的 download_count 是近 30 天累计值，且包含 CI 构建缓存、Docker 构建层重复拉取、甚至 composer install --no-dev 的冗余请求。
更严重的是，这个字段在 API 响应中不保证存在——私有包、被标记为 abandoned 的包、或刚提交未索引的包，download_count 字段直接缺失。拿它做加权计算会导致整行数据丢弃。
- 替代方案是查
github.com/vendor/repo的 stars + forks 数，虽然也不完美，但至少反映社区关注度，且 API 稳定可预期 - 若必须用 Packagist 数据，优先取
time.added和time.updated差值，大于 180 天无更新的包，健康度权重应强制衰减 40% - 注意 Packagist v2 API 返回的
downloads是对象结构：{"total": 123456, "daily": 1234, "monthly": 34567}，旧脚本若还按字符串解析会崩溃
健康度评估最难的部分不是收集数据，而是定义“什么算问题”。比如一个包的 autoload 正确但测试覆盖率仅 12%，该给多少扣分？这类阈值必须和实际维护成本挂钩，而不是套用通用标准。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
