require –dev 将包写入 composer.json 的 “require-dev” 字段，仅用于开发环境，安装后可通过 composer install –no-dev 在生产环境跳过；加 –no-install 仅修改 json 不安装；升级需显式指定版本或用 update。
require 命令加 –dev 会写入 composer.json 的 “require-dev” 字段
加 --dev 不是“临时安装”，而是明确告诉 Composer：这个包只在开发阶段需要，比如测试、代码检查或构建工具。它会把依赖写进 composer.json 的 "require-dev" 区块，而不是 "require"。
执行后，Composer 会立即下载并安装该包（含其自身依赖），但后续运行 composer install --no-dev 时，这些包不会被装上 —— 这正是生产环境部署的关键隔离机制。
-
composer require phpunit/phpunit --dev→ 写入"require-dev": { "phpunit/phpunit": "^10" } - 不加
--dev→ 默认写入"require"，上线时也会被装 - 如果项目已禁用
autoload-dev，即使包存在，其autoload-dev部分定义的类也不会被自动加载
require –dev 和 require –dev –no-install 的区别
--no-install 是个常被忽略的开关：它跳过实际安装动作，只改 composer.json。这对 CI 流程或批量维护很有用 —— 比如先集中修改依赖声明，再统一 composer install。
-
composer require friendsofphp/php-cs-fixer --dev→ 修改 JSON + 立即安装 -
composer require friendsofphp/php-cs-fixer --dev --no-install→ 只改 JSON，不下载、不解析依赖树、不写入vendor/ - 后者适合在 docker 构建多阶段中，把依赖声明和安装拆开，避免重复拉取
require –dev 在 lock 文件里怎么体现？
composer.lock 本身不区分 require 和 require-dev，它记录的是最终解析出的完整依赖图（包括所有传递依赖）。但关键点在于：composer install 是否带 --no-dev，决定了哪些包会被解压进 vendor/，以及 autoload_dev.php 是否被生成和启用。
- 即使某个 dev 包的依赖（比如
sebastian/exporter）也被 runtime 包用到，它仍可能出现在 lock 中两次：一次在 dev 分支路径，一次在主依赖路径 -
composer update --no-dev会移除 lock 文件中仅由require-dev引入的包（及其子依赖），哪怕它们版本没变 - 所以不要手动编辑
composer.lock，否则容易破坏 dev/non-dev 的边界一致性
常见误操作：–dev 不能用于 require-dev 已存在的包升级
如果一个包已经在 "require-dev" 里，直接 composer require foo/bar --dev 不会更新版本 —— 它只做“声明存在”，不触发版本变更逻辑。要升级，必须显式指定版本，或用 update。
composer require phpunit/phpunit:^9.6 --dev否则 Composer 会提示 Package foo/bar is already present...，且不改变版本号。
- 想升级已有 dev 包？用
composer update phpunit/phpunit（默认包含 dev） - 只想升级 dev 包，排除 runtime？用
composer update --with-dependencies --no-dev不行 ——--no-dev是“不装”，不是“不更新”。正确做法是composer update --with-dependencies phpunit/phpunit - 依赖冲突时，
--dev不提供额外解析权重，它只是字段标记；解决仍需看conflict或replace规则
真正容易被忽略的是：dev 包的 autoload-dev 配置只在 vendor/autoload.php 被 require 时才生效，而它的加载逻辑藏在 vendor/composer/autoload_real.php 的条件分支里 —— 如果你手写 autoloader 或用 PSR-4 手动注册，这部分不会自动触发。