Composer如何使用composer-require-checker_Composer composer-require-checker使用实践

Composer如何使用composer-require-checker_Composer composer-require-checker使用实践

先说一个核心事实：Composer本身并没有内置依赖声明完整性校验的功能。所以，composer-require-checker这个工具是独立存在的，你需要单独安装和运行它。千万别误会，它不会自动集成到composer install或composer update的流程里，必须手动执行。

为什么 composer-require-checker 会报 “Class not found” 却没在 require 里？

这个问题困扰过不少人。其实，它的检测逻辑很直接：扫描你的代码，看看实际使用的类、函数、常量，是不是都在composer.json的require（或require-dev）里声明了对应的包。报错的原因，通常逃不出下面几种情况：

• 只导入了没调用：代码里写了use语句，但后续没实际使用——工具可不管执行路径，只要扫描到符号就会检查。
• 动态加载被忽略：像class_exists('Some\Class', false)或者用字符串拼接类名这种动态方式，工具识别不了，这反而可能导致“漏报”。
• 内置与扩展类默认安全：PHP内置类（比如DateTime）、扩展提供的类（如PDO）以及全局函数（json_encode），默认是不会报错的，除非你特意用--ignore-builtin-functions参数去调整。
• 别名和Trait溯源难：通过class_alias创建的别名，或者Trait中引用的类，工具可能无法准确追溯到源头依赖包。

如何让 composer-require-checker 识别 require-dev 中的包？

这是另一个常见的坑。工具默认只认require里的包，require-dev中的依赖会被直接无视。所以，如果你的测试代码里用了phpunit/phpunit，但只在require-dev中声明了，它照样会给你报错。怎么解决？两个关键方法：

• 运行命令时加上--config-file=composer.json，确保它能读取到完整的配置文件。
• 更精细的控制，是手动创建一个专属配置文件，比如require-checker.json，然后这样运行：composer-require-checker --config-file=require-checker.json。配置文件内容可以参考下面这个模板：

{
    "autoload-dirs": ["src", "tests"],
    "scan-files": ["tests/bootstrap.php"],
    "prevent-unrequired-requirements": false,
    "required-extensions": ["json", "mbstring"]
}

这里有个至关重要的参数："prevent-unrequired-requirements": false。把它设为false，才能允许require-dev中的包被认可为合法的依赖来源。如果设为true，那就意味着所有被代码用到的包，都必须出现在require里，这通常不是我们想要的效果。

composer-require-checker 和 composer-unused 能否互相替代？

绝对不能。这两个工具的目标可以说是完全相反的：

• composer-require-checker：专门查找“用了但没声明”的风险。这是为了防止漏声明导致的生产环境运行时崩溃。
• composer-unused：专门清理“声明了但没用到”的冗余。这是为了给项目依赖“瘦身”，减少不必要的维护负担和包体积。

简单来说，一个是为了安全，防止线上漏洞；另一个是为了效率，优化项目结构。两者搭配使用，才能构成完整的依赖健康检查闭环。

另外，它们的底层机制也不同。composer-unused依赖静态分析，对于条件加载、插件式架构（比如Lara vel的Service Providers）很容易误判。而composer-require-checker在处理这类场景时反而更稳健，只要符号在代码里存在，它就会去校验。

最后提一个最容易被忽略的细节：composer-require-checker的配置文件里，必须显式指定autoload-dirs。否则，它连你项目里的src/目录都不会去扫描。这一点和很多人的直觉相反——它默认并不会去读取composer.json里配置的autoload字段。