composer.lock 文件必须为纯 ASCII 编码，出现中文或非 ASCII 字符（如 æ–‡、BOM）即被污染；应删除后通过 composer update --lock 重建，而非手动转码。
composer.lock 文件本身不该出现乱码——它是一个由 Composer 自动生成的 JSON 文件，内容应全为 ASCII 字符（包括引号、冒号、逗号、方括号等），不含任何中文或 UTF-8 多字节序列。一旦看到中文、问号、 或类似 æ–‡ 这样的符号，说明文件已被错误地用非 UTF-8 编码保存过，或者被文本编辑器以错误编码打开后又覆盖保存。
为什么 composer.lock 会出现“乱码”？
根本原因不是文件损坏，而是人为干预破坏了它的原始编码状态。常见场景包括：
- 用 Windows 记事本打开
composer.lock，并点击“另存为”，选了“ANSI”或“UTF-8-BOM”——记事本会把原本纯 ASCII 的文件强行加上 BOM 或转成 GBK 字节，导致后续composer install报JSON decode error - 在 VS Code 或其他编辑器中，右下角状态栏显示编码为
GBK或GB18030，误点“通过编码重新打开”，再保存 - 某些老旧 IDE（如早期 PHPStorm）在项目编码设为 GBK 时，会自动将所有文本文件（含 lock）按该编码写入
- Git 提交时因 core.autocrlf 或 encoding 配置异常，导致换行符或字节被改写（较少见，但可能）
注意：composer.lock 的合法内容永远只包含 ASCII 字符；任何非 ASCII 字节（比如中文、BOM EF BB BF）都是污染。
如何快速确认是否真乱码？
别靠眼睛看，用命令行验证原始字节：
- 运行
file -i composer.lock：正常应输出charset=us-ascii或charset=utf-8（因为 ASCII 是 UTF-8 子集）；若显示charset=gbk或charset=iso-8859-1，基本可判定被污染 - 运行
xxd composer.lock | head -n 3：检查开头是否有ef bb bf（UTF-8 BOM），或ff fe（UTF-16 LE），这些都不该存在 - 运行
composer install --dry-run：如果报错JSON parse error: syntax error, malformed JSON，且错误位置指向中文字符或非 ASCII 符号，就是编码问题
修复步骤：从污染到干净，一步到位
核心原则：不手动编辑，不尝试“转编码”，直接重建。因为 lock 文件本质是可再生快照，不是手写配置：
- 先备份当前文件：
cp composer.lock composer.lock.bak - 删掉当前被污染的文件：
rm composer.lock - 确保
composer.json是干净的（无语法错误、无非法字符）：运行php -l composer.json - 重新生成 lock：
composer update --lock（推荐）或composer install（仅当已有 vendor 且想严格复现原依赖） - 验证：
composer install --dry-run应无报错；file -i composer.lock应返回us-ascii
⚠️ 不要用 iconv 或在线工具转换它——你无法安全地把一个被 GBK 写坏的 JSON “转回” ASCII；唯一可靠路径是丢弃并重建。
怎么防止下次再乱？
关键在编辑器和团队约定：
- VS Code：在工作区设置中加
"files.encoding": "utf8"，并禁用"files.autoGuessEncoding": false - Notepad++：设置“格式 → 转为 UTF-8 无 BOM”为默认，关闭“以 UTF-8-BOM 格式保存”选项
- Git：全局执行
git config --global core.autocrlf true（Windows）或false（macOS/Linux），避免换行污染间接影响编码判断 - CI/CD：在构建脚本开头加
test -z "$(file -i composer.lock | grep -o 'charset=[^;]*')" || exit 1，强制拦截非 ASCII 文件
真正麻烦的从来不是修复一次乱码，而是让编辑器、IDE、Git 和人，都默认把 composer.lock 当作不可编辑的二进制快照——它只该由 Composer 碰，别的角色越界就会留坑。
