PHP json_decode() 默认深度限制为512层，用于防止栈溢出和DoS攻击；超出时返回null并触发JSON_ERROR_DEPTH错误，需通过json_last_error_msg()确认“Maximum stack depth exceeded”。
这是 PHP 的 json_decode() 在解析 composer.json 时触发的嵌套层级限制（默认 512 层），不是 Composer 自身报错，而是底层 JSON 解析器拒绝处理——删掉冗余嵌套结构比调高 max_input_nesting_level 更安全、更治本。
为什么 json_decode() 会报深度超限
PHP 默认对 JSON 嵌套深度设了硬限制（max_input_nesting_level = 512），防止栈溢出。当 composer.json 里塞了太多重复字段、深层嵌套的 scripts、或手动拼出来的超长 autoload.files 数组时，就容易触顶。这不是 Composer 故意卡你，是 PHP 主动熔断。
-
composer.json里出现多层"scripts": { "post-xxx": { "pre-yyy": [ { "run": "..." } ] } }这类嵌套写法 - 用脚本自动生成配置，把整个
vendor/composer/installed.json结构误拷进composer.json的某个字段 -
config块中堆砌大量已废弃插件配置（如"fxp-asset"、"github-protocols"），且每项又带子对象
怎么快速定位哪段 JSON 导致超限
别靠肉眼数大括号。直接用 PHP 命令行验证：
php -r "echo json_last_error_msg(); json_decode(file_get_contents('composer.json'));"
如果输出 Maximum stack depth exceeded，说明确实超限；再配合 jq 查看结构深度：
jq 'walk(if type == "object" then . else empty end) | length' composer.json
数值超过 400 就该警惕。重点检查以下三处：
-
scripts字段：是否存在递归调用链（比如post-install-cmd又触发另一个post-xxx） -
extra字段：是否把整段 YAML 配置转成 JSON 塞进来，形成深层嵌套 -
repositories：是否写了多个type: "package"并各自带完整dist+source对象
删哪些字段能立刻见效
真正影响依赖管理的字段其实很少，其余全是历史包袱。优先清理：
- 整个
scripts区块，除非你明确需要post-autoload-dump或pre-install-cmd -
config下所有与fxp-asset、github-protocols、process-timeout（>60）相关的键 -
autoload.classmap如果只含["src/"]这种宽泛路径，直接删掉，改用psr-4 -
require-dev里混进require的包（如"phpunit/phpunit"），它们不参与运行时加载，却强制加深解析树
改完后必须验证的两件事
删减不是目的，确保功能不破才是关键：
- 运行
composer validate，确认语法合法；再跑composer install --dry-run，看是否还报同样错误 - 执行
composer dump-autoload -v，检查输出里是否列出你实际用到的命名空间路径（比如App\→src/），漏了就说明psr-4映射没对齐
最常被忽略的是：删掉 classmap 后，如果项目里真有无法遵循 PSR-4 的全局函数文件（如 src/helpers.php），得单独加进 autoload.files，否则运行时直接报 Call to undefined function。
