Composer报JSON decode error或中文乱码，90%是编码链断裂所致：文件含BOM、终端用GBK解码UTF-8输出、PHP运行时未对齐；需分别验证并统一为UTF-8无BOM、chcp 65001及正确环境配置。
Composer 报 JSON decode error 或命令行中文变问号，90% 不是 Composer 本身的问题，而是编码链断在了某一处：文件保存用了 UTF-8 BOM、终端用 GBK 解码 UTF-8 输出、或 PHP 运行时没对齐——改错地方只会白忙活。
composer.json 文件带 BOM 头导致解析失败
PHP 的 json_decode() 遇到 UTF-8 BOM（EF BB BF）会直接报 JSON decode error: Syntax error，错误信息里不提示 BOM，只说“语法错”，容易误判为标点问题。
- 用
xxd composer.json | head -n1（Linux/macOS）或 VS Code 右下角编码显示确认是否为UTF-8 with BOM - VS Code 修复：右下角点击编码名 →
Save with Encoding→ 选UTF-8（注意不是UTF-8 with BOM） - 命令行批量清理（Windows/Linux 均可用）：
sed -i '1s/^\xEF\xBB\xBF//' composer.json - Git 提交前防复发：在
.gitattributes加一行composer.json text eol=lf encoding=utf-8
终端输出中文乱码，本质是解码错位
Composer 输出的是 UTF-8 字节流，但 Windows CMD 默认用 chcp 936（GBK）去读，结果每个中文都变成两个问号或方块——这不是 Composer 能控制的，得调终端。
- CMD 临时修复：
chcp 65001（切换为 UTF-8 代码页），再运行composer install - PowerShell 更可靠：启动时加参数
powershell -ExecutionPolicy RemoteSigned -Command "chcp 65001 | Out-Null; composer install" - Git Bash：右键标题栏 →
Options→Text→Character set设为UTF-8；再执行export LANG=UTF-8 - 长期建议换
Windows Terminal，它默认支持 UTF-8，无需手动切码页
编辑器保存方式偷偷埋雷
记事本、WPS、某些 CMS 后台编辑器默认用 GBK 或 UTF-8 with BOM 保存，复制粘贴进来的中文引号“”、全角冒号：、零宽空格等，都会让 json_decode() 拒绝解析。
- 别信编辑器右下角写的“UTF-8”——用
file -i composer.json（Linux/macOS）或 Notepad++ 的“编码 → 转为 UTF-8 无 BOM”验证真实编码 - 禁用所有 JSON 自动格式化插件（尤其
JSON Beautifier），它可能在对象末尾加逗号或把合法结构重排成非法格式 - 从网页复制配置时，先粘贴到记事本（清掉隐藏控制符），再转到代码编辑器
- 新增依赖优先用
composer require vendor/package自动生成条目，避免手写引入标点失误
validate 通过 ≠ 能正常 install
composer validate 只校验 JSON 语法和基础 schema，不检查字段值是否被当前 Composer 版本支持、不验证 PHP 环境兼容性、也不管路径是否存在——所以它绿了，install 仍可能崩。
-
"allow-plugins": true在 Composer 2.1 以下版本会被忽略，2.2+ 才真正生效；老版本静默跳过，插件未加载，后续报错却找不到原因 -
"repositories"中 URL 含未编码空格或&（如https://git.example.com/foo?token=abc&ref=main），必须 URL 编码为& -
"autoload"的psr-4映射路径末尾多斜杠："App\": "src//"是非法的，必须是"App\": "src/" - 验证更严苛的场景，用
composer validate --strict，它能揪出拼写错误（如requre）、废弃字段（如已移除的archive）
真正麻烦的不是单点修复，而是团队里有人用记事本改完直接提交——那个 BOM 会混进 Git 历史，之后所有人的 composer install 都可能随机失败。编码问题从来不是“修一次就完”，而是要卡在编辑器、Git、CI 三层上同步设防。
