Composer依赖可见性：理解require与require-dev的区别

Composer依赖可见性：理解require与require-dev的区别

免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈

先说一个核心判断：require 和 require-dev 这两个字段，本质上并非“开发环境”与“生产环境”的开关。它们更像是为“类是否会在运行时被业务代码加载”划下的一道声明边界。一旦越界，在 composer install --no-dev 之后，等待你的就是冰冷的 Class not found 错误。

require-dev 里的包，线上根本不存在

Composer 可不会去读取你的 APP_ENV 变量，也不会看服务器的 hostname。它只认一个东西：命令行参数。如果你在安装时没有加上 --no-dev 这个标记，那么像 phpunit 这样的开发依赖，就会堂而皇之地进入生产镜像。反之，一旦加上了这个标记，vendor/autoload.php 里连它的 classmap 条目都不会生成。

• 关键点在于，require-dev 中的包及其自动加载规则，压根不会出现在为生产环境准备的 autoloader 映射里。
• 更隐蔽的是，这些包自身的源码目录（比如你项目里的 tests/ 文件夹），也不会被自动注册。除非你在本地执行过不带 --no-dev 的 composer install。
• 这就引出一个 CI/CD 流水线里的典型陷阱：如果缓存了 vendor/ 目录，却没有把 --no-dev 这个参数纳入缓存键，就可能错误地复用了缓存，导致 phpunit 根本没装进去，测试却还在照常运行。

误把 dev 工具写进 require 的典型错误现象

最常见的坑，往往源于一个手误：少打一个空格。命令 composer require-dev phpunit/phpunit 是无效的，Composer 会将其解析为 composer require，直接把包塞进 require 字段。

• 线上部署后，调用 dump() 函数却报错？很可能是 symfony/var-dumper 被误装进了 require，而应用的调试模式又没关。
• 在控制器里写了 new MockeryMockInterface()，却没在 autoload-dev 里声明 Mock 类的目录？CI 环境会直接给你一个 Class not found。
• 如何自查？运行 composer show | grep phpunit，如果输出两行，其中一行标着 “required by your project”，那就说明它进了 require。解决办法是手动删除 composer.json 里的对应行，再执行 composer update phpunit/phpunit。

运行时判断类是否存在，别用 class_exists()

像 class_exists('PhpCsFixerFixerLineEndingLineEndingFixer') 这样的调用，在 --no-dev 环境下会触发自动加载机制。如果类不存在，程序就会崩溃。这其实不是 Composer 的问题，而是你把开发工具的逻辑混入了运行时的代码路径。

• 一个更好的选择是改用 interface_exists() 或 function_exists() —— 它们默认不会触发自动加载。
• 更稳妥的做法是加上环境守卫，例如：if (app()->environment('local')) { ... } 或 if (PHP_SAPI === 'cli') { ... }。
• 需要警惕的是，尽量避免在 config/app.php 这类全局配置文件里做条件加载，很容易因为判断逻辑遗漏而导致问题。

autoload-dev 不是给 require-dev 包用的

这个名字极具误导性。autoload-dev 的真正作用，是告诉 Composer：“当本项目启用了 dev 模式（即安装了 require-dev 中的包）时，请额外把 tests/、stubs/ 这些属于本项目的目录也加进自动加载规则。” 它跟 require-dev 里那些第三方包自身的加载毫无关系。

• phpunit/phpunit 自身的类如何加载，由它自己的 composer.json 控制，完全不依赖你项目里的 autoload-dev 配置。
• 如果你的测试类放在项目的 tests/ 目录下，又想在本地跑测试时能被自动加载，就必须在根项目的 autoload-dev 里明确声明，例如："psr-4": {"Tests\": "tests/"}。
• 这个配置对生产环境完全无影响 —— 因为在 --no-dev 模式下，autoload-dev 这个区块根本不会生效。

话说回来，真正困难的或许不是分清某个包该放哪里，而是如何守住运行时的边界。只要有一处代码——无论是 new、use 还是反射调用——触及了 require-dev 里的类，--no-dev 的隔离效果就会瞬间失效。这种隐性的耦合，往往藏在配置文件、服务提供者或者某些调试钩子深处，上线前很难通过常规测试完全覆盖。这才是依赖管理中最需要绷紧的那根弦。