如何在Composer中定义开发环境特有的依赖

如何在Composer中定义开发环境特有的依赖

为什么 require-dev 是唯一可靠的方式

首先得明确一个基本事实：Composer本身并不支持根据环境（比如开发或生产）来动态切换依赖。所以，我们常说的“开发环境特有依赖”，本质上就是那些只在本地开发、跑测试或者CI构建时需要，但绝不能出现在生产服务器vendor/目录里的包。能满足这个要求，并且被Composer原生支持的机制，有且只有一个：require-dev字段。

它不是一个可以随意开关的选项，而是一种声明式的契约。这个契约规定：列在require-dev里的包，只有在执行composer install（不带--no-dev参数）或composer update时才会被处理。一旦你加上了--no-dev这个标志——这在线上部署时是标准操作——这些包就会被完全忽略，既不会被解析和下载，也不会被纳入自动加载的范围。

• 一个关键细节是，require-dev中的包不会出现在composer.lock文件的生产依赖树里，它们的自动加载规则也仅限于autoload-dev。
• 千万别试图走捷径，比如用config.platform配置或者脚本钩子去“模拟”环境隔离。这往往会破坏锁文件的一致性，导致CI环境和线上环境的行为出现难以排查的差异。
• 如果遇到某个包在开发时需要高版本，而生产环境又必须用低版本这种极端情况，稳妥的做法是拆分成两个独立的依赖条目，或者接受一个统一的版本。因为Composer不支持针对不同环境设置不同的版本约束。

composer install --no-dev 必须出现在部署流程中

仅仅把依赖写进require-dev是远远不够的。很多团队就在这里栽了跟头，忘记了在部署环节执行关键一步，结果把phpunit、larastan、symfony/var-dumper这些大家伙全都打包进了线上容器。这不仅徒增了镜像体积，还可能引入非预期的自动加载路径，甚至触发一些调试类库的__destruct行为，埋下隐患。

• 正确的做法是，在CI/CD管道的构建阶段，就必须执行composer install --no-dev --optimize-autoloader。这能确保最终生成的autoload_classmap.php等优化文件里，绝对不会包含开发专用的类。
• 在编写Dockerfile时，也要养成习惯，禁止使用无参数的composer install，必须显式地带上--no-dev。
• 还有一种看似聪明实则危险的做法：先用composer install安装所有依赖，然后再手动删除vendor/bin下的开发工具。这完全是掩耳盗铃，因为那些开发包的代码仍然留在vendor/目录里，自动加载器在特定情况下仍然可能去尝试加载它们。

开发依赖也能被生产代码意外加载？小心 autoload-dev

这里有个容易踩的坑：autoload-dev。它的作用仅仅是告诉Composer：“这些路径下的类，只有在启用--dev模式执行composer dump-autoload时，才加入到自动加载的映射表中。”但它并不能阻止你在代码里手动require或者通过反射去调用这些类——而这正是许多诡异问题的来源。

• 举个例子，如果你在tests/目录之外的业务代码里，不小心写了一句class_exists('PHPUnit\Framework\TestCase')Class not found错误。
• 要避免这种情况，核心是不要在核心业务逻辑中硬编码开发依赖包的类名。更好的做法是使用接口进行抽象，或者配合条件判断。如果确实需要做类存在性检测，可以考虑使用class_exists($class, false)，并将第二个参数设为false来禁用自动加载。
• 另外，autoload-dev配置的路径，绝对不应该包含任何会被生产代码常规访问的目录。比如，千万别把app/Support/DebugHelper.php这样的文件放进autoload-dev，否则一旦部署上线，应用可能因为找不到这个“未定义”的类而直接崩溃。

想让某些工具只在特定命令生效？用 scripts + bin

还有一类特殊的“开发依赖”，它们其实是命令行工具，比如php-cs-fixer、psalm、infection。这些工具并不需要被你的PHP应用代码加载，我们只关心vendor/bin/目录下有没有对应的可执行文件。

• 处理这类包就简单多了，直接放到require-dev里就行，Composer会自动将它们提供的二进制脚本软链接到vendor/bin/目录下，无需额外配置。
• 我们可以利用Composer的scripts功能来定义一些快捷命令。例如：

  "scripts": {
    "cs-fix": "php-cs-fixer fix --dry-run",
    "test": "phpunit --colors=always"
  }

  这样一来，运行composer run cs-fix就能执行代码风格检查，既方便又不会污染主应用的逻辑。
• 需要注意的是，不要在scripts中调用那些没有在require-dev里声明的命令，因为Composer无法保证这些命令一定存在，这会导致CI流程失败。

话说回来，真正容易被忽略的其实是自动加载的边界问题。很多人以为只要包在require-dev里，就绝对安全了。但只要你的生产代码在某处new或者use了它的类，而这个类文件又恰好被生产的autoload规则所覆盖（比如不小心放在了app/目录下却没有被排除），问题就会立刻暴露。守住这个边界，需要依靠清晰的目录划分、严谨的autoload配置，再加上严格的代码审查，三者缺一不可。