绝大多数情况不是 json 本身写错，而是 composer.json 混入不可见 unicode 字符（如零宽空格、bom）或中文标点；可用 php -r 命令或 jq 精确定位错误位置，避免依赖 ide 格式化。
composer install 报错 JSON decode error 怎么快速定位
绝大多数情况不是 JSON 本身写错了，而是 composer.json 里混入了不可见的 Unicode 字符（比如零宽空格、BOM 头），或者用了中文标点（全角逗号、冒号）。编辑器自动补全或从网页复制内容时特别容易中招。
实操建议：
- 用命令行直接检查：
php -r "json_decode(file_get_contents('composer.json')); var_dump(json_last_error_msg());"—— 输出不是JSON_ERROR_NONE就说明有问题 - 别依赖 IDE 的“格式化”功能来纠错，它可能把错误格式“美化”得更难排查；改用
jq：运行jq '.' composer.json，报错位置会精确到行和列 - Windows 记事本保存的
composer.json极大概率带 BOM，换 VS Code 或 Vim，并确认右下角显示编码是UTF-8（不是UTF-8 with BOM）
composer validate 命令为什么有时不报错但 install 还失败
composer validate 只校验 JSON 结构 + 基础 schema（比如 name、require 是否存在），**不校验字段值是否合法**。例如："version": "dev-main" 在 validate 阶段能过，但 install 时会因版本约束解析失败而报 Invalid version string。
常见漏检场景：
-
repositories里写了不存在的 type（比如拼成"type": "gitlab"，正确是"type": "vcs"） -
autoload中的psr-4映射路径末尾多了斜杠（"App\": "src/"✅，"App\": "src//"❌） -
config下用了新版本才支持的选项（如"allow-plugins"在 Composer 2.2+ 才生效），老版本 validate 不认识但也不报错
如何让 CI 流程提前发现 composer.json 问题
不能只跑 composer validate，得模拟真实安装行为，又不能真下载包拖慢构建。推荐组合命令：
- 结构校验：
composer validate --no-check-publish --strict（--strict启用额外规则，比如禁止未声明的顶级字段） - 依赖解析校验（不下载）：
composer install --dry-run --no-progress --no-interaction—— 它会解析composer.lock或重新计算依赖图，暴露版本冲突、平台约束不满足等问题 - 如果项目有
composer.lock，加一步比对：composer update --lock --dry-run，防止手动改了composer.json却忘了更新 lock 文件
注意：--dry-run 在 Composer 2.5+ 才稳定支持所有场景，旧版本可能跳过某些校验。
PHP 版本不匹配导致的 JSON 相关错误怎么区分
Composer 自身对 PHP 版本有要求，但更隐蔽的问题是：你在 composer.json 的 config.platform.php 里写的版本，和实际运行环境不一致，会导致依赖解析结果不同，进而引发看似随机的 JSON 错误（比如某包在 PHP 8.1 下 require 一个扩展，而 platform 设成 8.0 就被忽略，install 时却因扩展缺失崩溃）。
判断方法：
- 看错误是否出现在
Resolving dependencies阶段之后，且伴随ext-xxx not found或class not found—— 很可能是 platform 配置误导了依赖决策 - 临时删掉
config.platform，再跑composer install --dry-run，如果不再报错，基本就是它的问题 - CI 中务必显式指定 PHP 版本（如 GitHub Actions 用
php-version: '8.2'），并确保与config.platform.php一致
platform 不是“兼容模式”，它是告诉 Composer：“就当这台机器装了这个 PHP 版本和这些扩展”，填错等于主动引入不一致。
