Composer的--dev参数在require命令中是如何工作的？ (添加开发依赖)

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 是否被生成和启用。

Stenography

一个AI驱动的代码库API

下载

• 即使某个 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 规则