autoload-dev 专为开发环境设计，用于自动加载测试类、工厂类等开发专用代码，仅在非生产环境且未启用 --no-dev 时生效，不影响生产环境 autoload.php 体积。
autoload-dev 是给谁用的
它只在 composer install 或 composer update 时，且当前环境不是生产环境（即 COMPOSER_DEV=0 未显式启用、或没加 --no-dev）才会生效。换句话说：你写的测试类、工厂类、假数据生成器这些「开发专用代码」，靠它才能被自动加载。
常见错误现象：Class TestsTestCase not found，但 phpunit 明明跑起来了——大概率是 autoload-dev 没配，或者你误用了 --no-dev 部署。
- 它不会影响生产环境的 autoloader 文件体积（
vendor/autoload.php里不包含 dev 类） - 如果你在
require-dev里装了phpunit，但没配autoload-dev，那Tests目录下的类根本不会进 PSR-4 映射表 - 和
autoload是并列关系，不是子集；两者配置结构完全一样，但作用域隔离
PSR-4 下 autoload-dev 怎么写才不漏类
最常踩的坑是路径写错，尤其容易忽略 vendor 包根目录和项目根目录的相对关系。比如你的测试文件在 tests/Feature/ExampleTest.php，类名是 TestsFeatureExampleTest，那配置必须严格匹配：
"autoload-dev": {
"psr-4": {
"Tests\": "tests/"
}
}
注意三个关键点：
- 末尾斜杠
"tests/"必须有，否则 Composer 会当成文件而非目录处理 - 命名空间结尾的反斜杠
"Tests\"是必需的（JSON 里要双写），少一个就找不到类 - 路径是相对于
composer.json所在位置的，不是相对于vendor/或public/ - 如果同时用了
classmap或files，它们也会被 dev 环境加载，但优先级低于 PSR-4
autoload 和 autoload-dev 冲突吗
不冲突，但容易混淆。Composer 会把两者合并进同一个 autoloader 实例（vendor/autoload.php），只是 autoload-dev 的映射只在 dev 模式下注册。真正麻烦的是「重复声明」：
- 比如
autoload里写了"App\": "src/"，autoload-dev又写了"App\": "tests/mocks/"—— 后者会覆盖前者，导致 src 下的 App 类反而加载不到 - 更隐蔽的是路径重叠：
"App\": "src/"和"App\Tests\": "tests/"看似合理，但一旦tests/里有App/Tests/Helper.php，就会触发两次映射，可能报Cannot declare class - 解决办法只有一个：确保
autoload-dev的命名空间前缀不与autoload重叠，哪怕只是多一个Dev或Test
为什么 vendor 里的包也有 autoload-dev
因为第三方包（比如 laravel/framework）自己也写测试，它们的 autoload-dev 是给自己的测试套件用的，**默认不会影响你的项目**。但如果你执行了 composer dump-autoload --dev，或者在非生产环境下运行 composer install，Composer 就会把所有已安装包的 autoload-dev 一并合并进来。
这就带来一个容易被忽略的副作用：某些包的测试辅助类（比如 OrchestraTestbench 提供的 TestCase）可能意外暴露到你的命名空间里，导致 IDE 提示混乱，或运行时出现意料外的类解析。
- 检查方式：运行
composer show -s vendor/package-name，看输出里有没有autoload-dev字段 - 若不需要，可在
composer.json中加"minimum-stability": "stable"并避免 require-dev 引入带测试依赖的包 - 最稳妥的做法：永远别在生产部署时漏掉
--no-dev，哪怕你觉得自己没用到任何 dev 代码
