Composer不处理编码差异，问题根源是composer.lock或composer.json被错误保存为非ASCII编码（如GBK、UTF-8-BOM）或含中文注释，导致JSON解析失败；正确做法是删除损坏文件并重建：rm composer.lock && composer update --lock，且composer.json须纯ASCII、无注释、无BOM。
Composer 本身不处理“共享依赖的编码差异”——它根本不会读取、解析或校验 PHP 文件的字符编码。所谓“编码差异导致的问题”，99% 是 composer.lock 文件被错误保存为非 ASCII 编码（如 GBK、UTF-8-BOM），或开发者在 composer.json 里手写了中文注释/路径，触发了 JSON 解析失败。
composer.lock 出现中文或乱码就是被污染了
合法的 composer.lock 必须是纯 ASCII 编码：所有键名、版本号、哈希值、URL 都只含英文字符、数字、标点和空格。一旦出现 æ–‡、中文、 或开头有 EF BB BF（UTF-8 BOM），说明文件已被文本编辑器（如 Windows 记事本、旧版 PHPStorm）用错误编码覆盖保存。
- 不要尝试用编辑器“转 UTF-8 无 BOM”——手动改编码极易残留非法字节
- 不要用
iconv或dos2unix处理 lock 文件——它不是文本格式问题，而是内容已损坏 - 运行
file -i composer.lock确认编码；若输出charset=gbk或含BOM，直接重建 - 正确做法：
rm composer.lock && composer update --lock（前提是composer.json本身干净）
composer.json 里写中文注释会直接报错
JSON 标准不支持注释，但 Composer 允许在 composer.json 末尾加 // 或 /* */ 注释（仅限部分版本，且非常脆弱）。一旦用了中文字符，PHP 的 json_decode() 就会返回 null，报错如 file could not be loaded: JSON error: Syntax error。
- 删除所有中文字符、全角符号、BOM、不可见控制符（如
\u200b） - 用
php -l composer.json检查语法，它比 Composer 自己的校验更早暴露编码问题 - 团队应统一用 VS Code + “Save with Encoding → UTF-8”（不带 BOM），并禁用自动插入中文注释插件
vendor/autoload.php 路径分隔符不是编码问题，是跨平台兼容问题
你看到 vendor/autoload.php 里全是 /，却能在 Windows 正常运行，这不是编码功劳，而是 PHP 7.4+ 在 Windows 上原生支持正斜杠作为目录分隔符。真正危险的是你在自定义代码里硬编码了 \ 或混用路径拼接逻辑。
- 所有
autoload、bin、scripts字段中的路径必须只用/，禁止DIRECTORY_SEPARATOR动态生成 - 检查
vendor/composer/autoload_static.php是否含反斜杠字符串——若有，说明某个依赖包未适配 PSR-4，需升级或替换 - CI 构建失败常因某包在
composer.json的autoload.files里写了src\Foo\Bar.php，这种必须改成src/Foo/Bar.php
真正需要关注的不是“编码”，而是文件是否被人为破坏了原始 ASCII 结构。Composer 只信任自己生成的内容，任何外部编辑器介入都可能让 lock 或 json 文件失效——修复动作永远是重建，不是修正。
