加 -D 参数才能安装开发依赖；旧版 Composer 不支持 --dev，需升级或改用 -D。
composer require -D 安装 dev 依赖时没生效？检查是否漏了 -D 或写错命令格式
直接运行 composer require 默认只写入 require，开发依赖必须显式加 -D（即 --dev）。很多人输成 composer require --dev xxx 却发现 composer.json 里还是进了 require，原因通常是用了旧版 Composer（-D。
-
composer require -D phpunit/phpunit✅（推荐，全版本兼容） -
composer require --dev phpunit/phpunit⚠️（Composer ≥ 2.2 才可靠） -
composer require phpunit/phpunit --dev❌（位置错，会被忽略）
require-dev 依赖在生产环境被加载？确认 autoload-dev 配置和部署流程
即使写进 require-dev，如果项目用了 "autoload-dev" 且路径包含生产代码，或者部署时没加 --no-dev，这些包仍可能被加载甚至执行。更隐蔽的问题是：某些测试工具（如 phpstan/phpstan）的配置文件若放在 src/ 下，IDE 或静态分析器可能误读。
- 检查
composer.json中是否有"autoload-dev"指向了不该暴露的目录 - 上线部署务必用
composer install --no-dev --optimize-autoloader - CI 流程中跑测试前要
composer install（带 dev），但构建产物镜像时得重新install --no-dev
本地装了 dev 依赖，但 CI 报 “Class not found”？可能是 autoloader 缓存或平台配置差异
常见现象：本地 phpunit 能跑，GitHub Actions 却提示 Class 'PHPUnit\Framework\TestCase' not found。不是没装，而是 vendor/autoload.php 没被正确引入，或 PHP 版本不匹配导致某些包根本没安装成功。
- CI 中先执行
composer show确认phpunit/phpunit是否真在列表里 - 检查
composer.json的"platform"配置是否锁死了低版本 PHP，与 CI 环境冲突 - 避免在
tests/bootstrap.php里手动 requirevendor/autoload.php—— 应该由 Composer 自动生成的 autoloader 处理
想临时禁用某个 dev 依赖？别删 require-dev，改用 config.platform 模拟缺失
调试兼容性问题时，有时需要“假装没装”某个 dev 工具（比如验证项目是否真不依赖 symfony/var-dumper）。直接删 require-dev 条目再 install 太重，而且容易误提交。
- 临时屏蔽：运行
composer config platform.php 7.4.0，再装一个只支持 8.0+ 的包，它就不会被装上 - 更干净的做法：用
composer create-project --no-install xxx初始化空白环境对比 - 注意：
config.platform是全局设置，操作完记得composer config --unset platform.php
dev 依赖的边界其实很薄——一个 autoload-dev 路径配错，或一次忘记 --no-dev，就可能让测试工具代码混进生产。比装不上更麻烦的是“看起来装上了，实际没起作用”。
