autoload-dev 是 composer.json 中专用于开发环境的自动加载配置，其映射不会写入生产环境的 vendor/autoload.php；而 autoload 的配置在所有环境中生效。
autoload-dev 是什么，和 autoload 有什么区别
autoload-dev 是 composer.json 中一个独立配置项，专门用于定义「仅在开发环境生效」的自动加载规则。它和 autoload 的核心区别在于：Composer 安装依赖时，autoload-dev 的映射**不会写入生产环境的 vendor/autoload.php 自动加载器中**——除非你显式执行 composer install --dev 或未加 --no-dev 标志。
这意味着：tests/ 目录下的类，在 CI 或线上部署时默认不可被 require 或 new，能有效避免测试代码意外进入生产逻辑。
如何在 composer.json 中正确配置 tests/ 目录自动加载
最常用且推荐的方式是使用 psr-4 映射，把测试命名空间与目录明确绑定。例如你的项目根命名空间是 MyApp，测试类放在 tests/ 下：
{
"autoload": {
"psr-4": {
"MyApp\": "src/"
}
},
"autoload-dev": {
"psr-4": {
"MyApp\Tests\": "tests/"
}
}
}
配置后需运行 composer dump-autoload 生效。注意以下几点：
-
MyApp\Tests\后面的双反斜杠是必需的，表示命名空间结尾，否则可能匹配到MyApp\TestSuite\等子命名空间 -
tests/路径是相对于composer.json所在目录的，不能写成./tests/或绝对路径 - 如果测试类没有按 PSR-4 规则命名（比如文件名不匹配类名），自动加载会失败，此时应改用
classmap
什么时候该用 classmap 而不是 psr-4
当你有以下情况时，classmap 更可靠：
Linux Security Scanner
下载
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
- 测试目录里混着函数文件（如
tests/helpers.php）、匿名类或非标准命名类 - 使用了 PHPUnit 的
Test后缀但类名不完全遵循命名空间层级（如tests/Unit/HelperTest.php中定义的是HelperTest而非MyAppTestsUnitHelperTest） - 想让某个目录下所有 PHP 文件无条件被扫描并注册（适合快速原型或遗留结构）
示例配置：
{
"autoload-dev": {
"classmap": ["tests/", "tests/bootstrap.php"]
}
}
注意：classmap 生成的是静态路径列表，每次增删测试文件后必须重新运行 composer dump-autoload，否则新文件不会被加载。
常见错误：测试类找不到、Class not found、autoload.php 不包含 tests
典型现象包括：PHP Fatal error: Class 'MyAppTestsUnitExampleTest' not found，或在 GitHub Actions 中跑测试时报错但本地正常。排查要点：
- 确认当前执行环境是否启用了 dev 包：CI 中常带
--no-dev，导致autoload-dev被跳过 - 检查
vendor/autoload.php是否真包含tests/映射：可临时加一行var_dump($loader->getPrefixesPsr4());查看输出 - 留意大小写——Linux 下
Tests/和tests/是不同路径，但 Windows 可能不报错，造成本地通过、CI 失败 - 如果你用的是 Composer 2.2+ 并启用了
optimize-autoloader，确保autoload-dev映射仍被保留（它默认只优化autoload，不影响autoload-dev）
测试类的自动加载看似简单，但跨环境一致性往往卡在路径大小写、CI 参数和 dump-autoload 的触发时机上。
