PHP Composer autoload-dev 怎样隔离开发依赖

autoload-dev 用来隔离测试辅助类等开发阶段的自动加载规则；开发工具包应声明在 require-dev。发布构建使用 composer install --no-dev，既跳过开发依赖包安装，也跳过根项目的开发加载规则。只写 autoload-dev，并不会自动删除开发文件或阻止手动包含它们。

Composer 官方地址：https://getcomposer.org/。本文讲解 Composer 现有配置能力，不对应一次新版本公告；示例未执行安装、测试或构建命令。

先分清开发包与开发类映射

一个常见场景是：应用代码放在 src，测试样例、假实现和测试辅助类放在 tests。开发机里两者都需要可加载，部署到生产时则只应让业务代码依赖正式运行所需的组件。

前两项回答“安装哪些包”，后两项回答“如何找到代码”。把一个测试框架的包名写进 autoload-dev 并不能安装框架；把 tests 的目录只放进 require-dev 也不能建立命名空间映射。

哪些代码适合放进 autoload-dev

适合放入开发加载规则的，是只有测试或本地开发才需要的辅助代码，例如 ParcelSample 测试样例。生产请求处理器、正式服务类和运行时必需的共享代码，仍应位于正式加载范围。

要判断一段代码属于哪里，可以看正式业务入口是否直接或间接引用它。若生产代码调用测试目录里的类，开发环境往往能工作，关闭开发加载后才暴露缺失；这应通过调整代码职责解决，而不是把所有测试类重新塞回正式映射。

下面的 composer.json 是不包含第三方工具包的最小配置示例。严格 JSON 不支持注释，字段含义在正文解释：ParcelApp 对应 src，ParcelApp\Tests 对应 tests；新增开发工具时另行维护 require-dev 及锁文件。

{
  "name": "parcel-demo/application",
  "require": {
    "php": ">=8.0"
  },
  "autoload": {
    "psr-4": {
      "ParcelApp\\": "src/"
    }
  },
  "autoload-dev": {
    "psr-4": {
      "ParcelApp\\Tests\\": "tests/"
    }
  }
}

用独立命名空间建立最小示例

在项目中建立 tests/Fixture/ParcelSample.php。类名剩余部分 Fixture\ParcelSample 对应目录与文件名，前缀 ParcelApp\Tests 与 composer.json 中的开发命名空间一致。

 'BOX-A', 'count' => 3];
    }
}

开发模式安装后，项目通过 vendor/autoload.php 使用 Composer 生成的加载器。只改了 composer.json 的映射规则时，可以重建自动加载文件，不必为了更新一条路径就重新解析所有依赖版本。

# 开发目录中安装锁文件记录的依赖，并生成开发自动加载规则
composer install

# 仅修改映射规则时重建自动加载文件，不负责新增或移除依赖包
composer dump-autoload

这里的“可加载”有明确前提：加载器已经按开发模式生成，文件位置和命名空间保持一致。本文没有提供真实执行输出，也不声称此示例经过安装测试。

与全部放在 autoload 的方案比较

如果把 tests 和 src 一起放进 autoload，关闭开发模式也不能表达“去掉测试映射”的意图；它们都已经被声明为正式规则。采用独立的 autoload-dev 后，开发阶段仍方便引用测试辅助类，发布构建则能选择排除这组规则。

# 在独立发布构建目录中，按已有锁文件安装生产依赖并优化加载
composer install --no-dev --optimize-autoloader

# 下面仅展示重建加载规则的另一种用途，不能替代上面的依赖安装
# composer dump-autoload --no-dev

dump-autoload --no-dev 只处理加载规则，不应拿它代替按生产依赖集合构建 vendor。开发包是否安装与开发类是否注册，是两个要分别处理的问题。

推荐在独立构建目录生成发布产物，并保留已经确定依赖版本的 composer.lock。已有锁文件时，install 使用锁定版本；依赖升级应在开发和测试流程中完成，不宜把生产安装悄悄变成一次重新选版本的操作。

采用时注意根包与构建产物

根包范围：autoload-dev 与 require-dev 都具有 root-only 属性。一个库作为别的项目的依赖安装时，消费者不会自动接收这个库的开发规则。若库的正式类需要某个工具包或辅助类，它就不能只存在于该库的开发配置中。

目录并不会消失：关闭开发加载不等于移除仓库中的 tests 目录。发布归档或镜像里是否包含测试源码，应由打包规则决定；需要避免目录对外可访问时，还要设置正确的 Web 根目录与访问范围。

避免宽泛映射：开发目录若又被宽泛的正式 classmap、files 规则或手动 require 包含，就绕过了这次配置拆分想表达的边界。应梳理实际的加载入口，不能只盯着 autoload-dev 字段。

构建脚本也有依赖：如果项目的安装脚本依赖开发工具，使用 --no-dev 可能使该脚本无法工作。应确定哪些脚本属于开发阶段、哪些属于正式构建阶段，并给正式阶段提供必要的运行依赖。不要通过无条件关闭全部脚本来掩盖职责问题。

autoload-dev 可以替代 require-dev 吗？

不能。一个声明开发代码的加载规则，另一个声明开发依赖包，应按对象分别配置。

关闭开发规则可以阻止别人直接执行测试文件吗？

不能。自动加载配置不是访问控制，文件部署位置和服务入口仍要单独管理。

生产需要的共享辅助类应该放哪里？

放在正式代码与正式加载范围内；测试再复用它。不要让正式代码依赖只有开发模式才存在的类。

依据：Composer 配置结构、Composer 命令文档及依赖安装基础说明。