--no-dev 是最直接有效的深度截断方式，它从根节点起彻底忽略所有 require-dev 字段，无论嵌套多深；config.platform 可伪造平台环境裁剪依赖树，但无法精准屏蔽特定包。
为什么 composer install 会拉取几十层嵌套的 dev 依赖？
默认情况下，Composer 不限制依赖解析深度，只要某个包声明了 require-dev，而它的子依赖又带 require-dev，就会一路递归下去。这在 CI 环境或生产部署时非常危险——你本想装一个 phpunit，结果顺带把 symfony/var-dumper 的全部开发依赖（包括 phpstan、infection 等）全拉下来了。
根本原因不是 Composer “没限制”，而是它默认信任所有 require-dev 声明，并按需解析完整图谱。真正起作用的是安装时的上下文和配置开关。
--no-dev 是最直接有效的深度截断方式
它不是“限制递归层数”，而是从根节点开始就彻底忽略所有 require-dev 字段——无论嵌套多深，只要不是根 composer.json 的 require 列表里的包，一律不解析、不下载、不 autoload。
- CI/CD 构建或生产环境部署必须加
--no-dev，否则vendor/体积可能膨胀 3–5 倍 - 它不影响
autoload-dev的自动加载规则，只影响安装行为 - 如果项目里有包把运行时必需的功能放在
require-dev里（极不规范），加了这个参数会导致运行时报Class not found
想保留部分 dev 工具但砍掉深层传递依赖？用 config.platform 欺骗解析器
Composer 在解析依赖时，会把 config.platform 中声明的扩展和 PHP 版本当作“已存在”的环境来裁剪依赖树。你可以利用这点，让某些 dev-only 包的子依赖被跳过。
例如，你想保留 phpunit/phpunit，但不想装它依赖的 phpspec/prophecy 的全部 dev 依赖：
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
{
"config": {
"platform": {
"php": "8.2.0",
"ext-json": "1.0"
}
}
}
这样做的效果是：Composer 认为这些平台扩展“已经装好了”，于是不会去安装提供它们的包（及其传递依赖）。但它不能精准控制某一层，只适合用于“全局降级”依赖图规模。
- 不能用来屏蔽某个具体包，只能靠平台能力“覆盖”其依赖需求
- 若真实环境中缺这些扩展，运行时会报错，和安装时是否下载无关
- 对纯 PHP 包（如
sebastian/exporter）无效，因为它们不依赖扩展
没有 --max-depth 这种参数，别白费力气找
Composer 官方从未提供类似 npm 的 --depth 或 pip 的 --max-depth 选项。社区里流传的 patch、插件或自定义脚本，要么失效（新版 Composer 移除了对应钩子），要么只改了 composer show 的输出层级，不影响实际安装行为。
真正可控的只有两个维度：
- 是否启用
require-dev—— 用--no-dev - 是否伪造平台环境来绕过某些依赖 —— 用
config.platform
递归深度本身不是问题，问题在于你是否需要那些传递进来的 dev 依赖。一旦搞混“开发工具”和“运行时依赖”，再怎么调深度参数也救不了 autoload 冲突和部署失败。
