require 中的包参与运行时逻辑并被自动加载，require-dev 中的包仅开发使用且不进入生产环境；autoload-dev 仅在启用 dev 模式时扩展项目自动加载范围，用于测试类等。
require 和 require-dev 在安装时的行为差异
执行 composer install 时，默认只安装 require 中的包；只有显式加上 --dev（或未加 --no-dev）才会同时装 require-dev 里的依赖。生产环境部署若用 composer install --no-dev，require-dev 里的包完全不会出现在 vendor/ 目录中。
关键判断点：不是“开发时才需要”，而是“是否参与运行时逻辑”。比如 phpunit/phpunit 只在跑测试时调用，不参与 HTTP 请求处理，就该进 require-dev；而 monolog/monolog 即使只在日志模块里用，只要代码运行时会加载它，就必须放 require。
-
require中的包会被自动载入 autoloader，且其依赖也会被递归安装 -
require-dev中的包不会影响主项目的 autoload 配置，但它的autoload-dev（如有）仍可被启用 - 某些工具如
phpstan/phpstan或friendsofphp/php-cs-fixer必须放require-dev，否则会污染生产环境的依赖图谱和内存占用
autoload-dev 是 require-dev 的配套机制
autoload-dev 不是给 require-dev 包自己用的，而是告诉 Composer：“当启用了 dev 模式（即装了 require-dev 包）时，也把这部分路径加入自动加载规则”。它常用于测试类、fixture 文件或集成测试专用服务提供者。
{
"autoload": {
"psr-4": { "App\\": "src/" }
},
"autoload-dev": {
"psr-4": {
"App\\Tests\\": "tests/",
"App\\Fixtures\\": "tests/fixtures/"
}
},
"require-dev": {
"phpunit/phpunit": "^10.5"
}
}
如果把 tests/ 放进 autoload，会导致生产环境也加载测试类——可能触发未定义类、意外初始化或安全暴露。而放在 autoload-dev 后，只有运行 composer dump-autoload（默认含 dev）或 composer dump-autoload --dev 时才生效。
-
autoload-dev不会改变require-dev包自身的加载方式，它只扩展当前项目的自动加载范围 - CI 环境通常执行
composer install --no-interaction，此时是否加载autoload-dev取决于是否带--dev，而非是否声明了require-dev - 若项目发布为库（非应用），应避免在
autoload-dev中声明对外暴露的命名空间，否则下游用户可能意外依赖测试结构
require-dev 被误放到 require 的典型后果
最直接的表现是 composer install --no-dev 后，应用启动报 Class not found —— 因为某个本该只在开发期存在的类，被业务代码直接 new 了。更隐蔽的问题是性能与安全：
- 生产环境多加载几十个 dev-only 类，增加 OPcache 内存压力和冷启动时间
- 像
symfony/debug-bundle这类包若进入require，会在生产路由中暴露调试接口，构成严重风险 - 某些包（如
doctrine/doctrine-fixtures-bundle）自带命令行指令，若混入生产，可能被误执行清空数据库 - 版本冲突概率上升：比如主项目依赖
guzzlehttp/guzzle:^7.0，而某个 dev 工具锁死^6.5，放错位置后 Composer 会强制降级主依赖
CI/CD 和部署脚本中的实际检查点
不能只靠人工审查 composer.json。应在 CI 流程中插入校验步骤，例如用 shell 脚本检查是否有高危包误入 require：
#!/bin/bash # 检查是否把 phpunit 放进了 require if grep -q '"phpunit/phpunit"' composer.json && ! grep -A 100 '"require-dev"' composer.json | grep -q '"phpunit/phpunit"'; then echo "ERROR: phpunit/phpunit found in require, should be in require-dev" >&2 exit 1 fi
更稳妥的做法是用 composer show --dev 对比 composer show 输出，确认所有预期仅开发使用的包确实未出现在生产依赖列表中。另外，Docker 构建时应明确使用 composer install --no-dev --optimize-autoloader，并验证最终镜像中 vendor/bin/ 下没有 phpunit、phpcs 等二进制文件。
真正容易被忽略的，是那些“看起来像运行时依赖”的 dev 工具——比如用于生成 API 文档的 zircote/swagger-php，它只在构建阶段扫描注解，不应参与运行时，却常被放进 require。这类边界情况，得靠团队约定 + 自动化卡点来守住。
