require 是运行必需依赖，–no-dev 时仍安装；require-dev 仅开发使用，–no-dev 时完全不装。autoload 全环境生效，autoload-dev 仅开发启用。运行时依赖误放 require-dev 会导致线上崩溃。
require 和 require-dev 的安装行为差异
运行 composer install 时，默认会同时安装 require 和 require-dev 下的包；但执行 composer install --no-dev（常见于生产环境部署）时，require-dev 里的依赖**完全不会被下载或加载**，而 require 中的包始终生效。
这意味着：require 是项目运行所必需的依赖（比如 "monolog/monolog": "^2.0"），缺了就报 class not found；require-dev 只服务于开发流程（比如 "phpunit/phpunit": "^9.5"），不参与线上逻辑执行。
autoload 和 autoload-dev 的对应关系
autoload 块定义的命名空间映射，在所有环境下都生效，供运行时自动加载；而 autoload-dev 仅在开发环境下启用——它通常用来注册测试类、示例代码或命令行工具的类路径，避免污染生产 autoloader。
常见误操作是把测试工具类写进 autoload，结果上线后多加载一堆无用文件，拖慢响应。正确做法：
- 业务核心类 → 放
autoload的"psr-4"或"classmap" - Tests/ 目录、Fixtures/、Commands/（非 runtime）→ 放
autoload-dev - 若某类既被测试调用又被业务调用，必须挪到
autoload，否则生产环境找不到
require-dev 里放运行时依赖的后果
把本该在 require 中声明的包（如 "symfony/console"）错放到 require-dev，会导致：
- CI/CD 流水线用
--no-dev构建失败，抛出Class 'SymfonyComponentConsoleapplication' not found - 本地开发正常，但线上容器启动即崩，排查时容易忽略 composer.json 配置粒度
- ide 或静态分析工具可能因环境不一致给出错误提示
判断依据很简单：该包是否出现在你写的任何 new XXX()、use XXX 或框架配置中？如果是，就必须进 require。
如何安全地迁移依赖到 require-dev
不是所有开发工具都适合直接扔进 require-dev。需确认三点：
- 该包是否只在命令行执行（如
phpstan/phpstan）、测试阶段（如mockery/mockery）或构建环节（如ocramius/package-versions）使用？ - 它的代码是否**从未被应用代码直接引用**？检查
grep -r "use.*package-name" .和grep -r "new PackageName" . - 它是否通过 Composer 插件机制注入（如
dealerdirect/phpcodesniffer-composer-installer）？这类插件必须保留在require，否则composer install阶段就失效
一个常被忽略的点：某些包（如 roave/security-advisories）虽不提供运行时代码，但属于“元约束”，必须放在 require 才能触发版本冲突拦截——放错位置等于关掉安全闸门。