composer dump-autoload --no-dev 不生成开发类加载规则是设计行为，它跳过 autoload-dev 配置（如 tests/ 的 PSR-4 映射）且不加载 require-dev 包，仅保留生产环境自动加载逻辑。

为什么 comp

oser dump-autoload --no-dev 不生成开发类加载规则

它确实不会——这不是 bug，而是设计行为。--no-dev 的作用是跳过 autoload-dev 配置段（如 psr-4 或 classmap 下的 tests/、src/Tests/ 等路径），同时不加载 require-dev 中声明的包。生成的 vendor/autoload.php 仅包含生产环境所需的自动加载逻辑。

autoload-dev 配置被完全忽略的典型场景

当你在 composer.json 中写了类似这样的配置：

{
  "autoload": {
    "psr-4": { "App\\": "src/" }
  },
  "autoload-dev": {
    "psr-4": { "App\\Tests\\": "tests/" }
  }
}

执行 composer dump-autoload --no-dev 后，tests/ 下的类将不会出现在生成的 autoload_static.php 或 ClassLoader 映射中。即使你手动 require 了测试类，也会触发 Class not found 错误。

• 该开关只影响自动加载注册，不影响已安装的 dev 包本身（它们仍留在 vendor/）
• composer install --no-dev 会同时删掉 vendor/bin 中的 dev 工具（如 phpunit），但 dump-autoload --no-dev 不动这些文件
• 如果你在 CI 中先运行 --no-dev，再运行 phpunit，会直接失败——因为测试类根本没被加载

如何验证是否生效：检查生成的 autoload 文件

最直接的方式是查看 vendor/composer/autoload_static.php 中的 $classMap 和 $prefixLengthsPsr4 数组内容：

• 对比运行 composer dump-autoload 和 composer dump-autoload --no-dev 后该文件的差异
• 搜索 Tests\\ 或你 dev 目录对应的命名空间前缀，确认是否从 $prefixesPsr4 中消失
• 注意：如果用了 classmap 且路径写在 autoload-dev 下，对应路径也不会出现在 $classMap 中

真正需要「只加载生产类」时的合理用法

这个命令适合部署阶段或构建精简镜像（如 Docker）时使用，目的是减小 autoloader 初始化开销和内存占用。但它不是“性能优化银弹”：

• PHP 8.1+ 的 OPCache 对未使用的类映射几乎无额外成本，实际性能提升微乎其微
• 若项目使用了依赖注入容器 + 自动发现（如 Laravel 的 Route::get() 扫描控制器），而控制器里引用了测试工具类（比如 Mockery），--no-dev 可能导致运行时报错而非编译时报错
• 某些包（如 phpunit/phpunit）自身带 autoload-dev 规则，但它们的类通常不会被生产代码直接引用；真正危险的是你自己写的 autoload-dev 路径被意外用于生产逻辑（比如把 Factories/ 放进了 dev 段）

最容易被忽略的一点：CI/CD 流水线里混用 --no-dev 和本地开发习惯，会让“本地能跑、线上报错”的问题更隐蔽——尤其是当测试辅助类被误塞进业务逻辑分支里时。