Windows CMD中chcp 65001只管用一次，因其为会话级设置，关闭窗口即失效；需手动重输或通过注册表Autorun永久配置，且须配合支持中文的字体（如Microsoft YaHei）才能彻底解决Composer等工具的中文乱码问题。
Composer中文控制台输出乱码，不是 Composer 本身出错，而是 Windows 终端默认用 GBK 解码它发出的 UTF-8 字节流——解码方和编码方没对上，必然显示为问号、方块或乱码序列。
Windows CMD 中 chcp 65001 为什么只管用一次？
因为 chcp 65001 是会话级设置，关掉窗口就失效。它只是临时把当前 CMD 窗口的代码页切到 UTF-8，不改系统默认行为。
- 每次新开 CMD 都得手动输一遍
chcp 65001，再运行composer install - 双击 .bat 脚本启动时不会自动执行该命令，除非你在脚本开头显式写上
@chcp 65001 >nul - PowerShell 默认不识别
chcp，得用powershell -Command "chcp 65001 | Out-Null; composer install" - 某些老旧工具（如 MobaXterm）在启用 UTF-8 后反而目录名变乱码，说明其内部解析逻辑未适配，这类终端建议换用 Windows Terminal
Git Bash 下中文显示为 \344\273\245 这类八进制，怎么修？
这是 Git Bash 把 UTF-8 字节当 Latin-1 解析的结果，本质是终端解码逻辑错位，不是文件问题。
- 右键 Git Bash 窗口标题栏 → Options… → Text → 把
Locale设为zh_CN或en_US，Character set显式选UTF-8 - 检查当前环境变量：
echo $LANG应输出类似zh_CN.UTF-8；若为空或C，在~/.bashrc末尾加export LANG=en_US.UTF-8并执行source ~/.bashrc - 字体必须支持中文：Options → Text → Font → 换成
Microsoft YaHei或Fira Code，避免用默认的Consolas（部分版本不渲染中文） - 不要依赖“粘贴后自动识别”——Windows 剪贴板无编码标记，粘贴含中文的命令前，先确认当前终端已设好 UTF-8
升级 Composer 到 2.5.8+ 还要加 --no-ansi？
加 --no-ansi 不是为了“让中文显示”，而是绕过 ANSI 控制符引发的二次解码失败。新版 Composer（2.5.8+）修复了 isUtf8Terminal() 检测逻辑，能更准识别 Windows 控制台是否真正支持 UTF-8，但仍有边界情况。
- 某些远程桌面连接、旧版 ConEmu 或 VS Code 集成终端仍可能被误判为不支持 UTF-8，此时
composer update --no-ansi可强制禁用颜色和 Unicode 控制符，换来稳定输出 -
--no-ansi不影响中文内容本身，只是去掉高亮、进度条等 ANSI 序列，避免它们和 UTF-8 字节混在一起被错误解析 - 如果连
--no-ansi下中文仍乱码，说明问题不在 Composer，而是终端根本没切换到 UTF-8（比如chcp没生效，或字体不支持）
最易被忽略的一点：即使所有设置都对了，如果终端字体不支持中文，照样显示为空格或方块——别只调编码，记得去 Options 里换字体。
