windows控制台运行composer install中文乱码，根本原因是终端默认gbk编码（chcp 936）与composer的utf-8输出不匹配；临时方案为cmd执行chcp 65001或powershell启动时加chcp 65001命令，长期应升级composer至2.5.8+并确保composer.json为utf-8无bom格式。
Windows 控制台运行 composer install 显示问号、方块或乱码，不是 Composer 坏了，而是终端用 GBK 解码它发出来的 UTF-8 字节流——解码错位，结果必然崩。
为什么 CMD/PowerShell 默认显示中文就乱码
Windows 控制台（CMD 和 PowerShell）默认代码页是 chcp 936（GBK），而 Composer（基于 PHP）所有输出（包名、错误提示、进度条）都是 UTF-8 编码。两者没对上，就像拿英文词典查中文词——字节还在，意思全丢。
- 执行
chcp查看当前代码页，若输出活动代码页: 936，就是它 -
chcp 65001可临时切到 UTF-8，但仅限当前窗口，关掉即失效 - PowerShell 比 CMD 更可靠：启动时加
powershell -ExecutionPolicy RemoteSigned -Command "chcp 65001 | Out-Null; composer install" - VS Code 集成终端需三处同步：
terminal.integrated.defaultProfile.windows设为PowerShell，$PROFILE加$OutputEncoding = [console]::OutputEncoding = New-Object System.Text.UTF8Encoding，设置里补"terminal.integrated.shellArgs.windows": ["-NoExit", "-Command", "chcp 65001 > $null"]
Git Bash 中 composer 输出正常但粘贴命令后乱码
Git Bash（mintty）本身支持 UTF-8，但 Windows 剪贴板不带编码标记，粘贴时按当前 locale 错误解码，尤其容易把中文路径或含 @ 的 Git URL 粘成乱码。
在 Windows 上执行终端命令，或对比 Windows 与 Linux 的 Shell 语法时使用。建议先检测当前 Shell 是 PowerShell 还是 cmd.exe，再给出相应命令……
- 右键终端标题栏 → Options… → Text → Character set 改为
UTF-8（不是 Default） - 检查
echo $LANG，应输出类似zh_CN.UTF-8或en_US.UTF-8；若为C或空，编辑~/.bashrc追加：export LANG=en_US.UTF-8和export LC_ALL=UTF-8，再source ~/.bashrc - 字体必须支持中文：Options → Text → Font 改为
Microsoft YaHei或Consolas，SimSun 容易渲染异常 - 实在不稳定，直接换 Windows Terminal，原生支持 UTF-8 和现代字体
composer.json 文件带 BOM 导致 JSON decode error
99% 的 JSON decode error: Syntax error 不是语法写错，而是文件开头藏了不可见的 BOM（EF BB BF）。PHP 的 json_decode() 把它当非法字符直接拒掉，且不报行号。
- VS Code 打开
composer.json，右下角看编码名：若显示UTF-8 with BOM，点击 → Save with Encoding → UTF-8（注意选“UTF-8”，不是“UTF-8 with BOM”） - 命令行验证：
xxd composer.json | head -n1，若开头是00000000: efbb bf就有 BOM - Linux/macOS 清除 BOM：
sed -i '1s/^//' composer.json - Windows PowerShell 清除：
(Get-Content composer.json -Raw) -replace "uFEFF", "" | Set-Content composer.json -Encoding UTF8
工作目录或 path 仓库含中文触发 Invalid argument
Composer 调用的 PHP 底层函数（如 realpath()、scandir()）在 Windows 上对中文路径处理极不稳定。GUI 能打开 ≠ Composer 能解析——这是两套路径解析逻辑。
- 运行
echo %cd%（CMD）或pwd（PowerShell/Git Bash），路径含中文、空格、&、(、)就立刻改掉，比如从D:我的项目pp改为D:devmyapp - 检查
composer.json里的name和autoload.psr-4：命名空间不能含/（得用），路径不能以../开头，也不能含?、*、"等 Windows 非法字符 - 若用了
"type": "path"仓库，运行composer config repositories找出对应url，确保是纯 ASCII 路径，比如"url": "../mylib"，而非"C:Users张三lib" - Windows 长路径限制（260 字符）有时会伪装成字符问题：启用
LongPathsEnabled策略或改用\?前缀（但 Composer 不直接支持，优先清空中文路径）
真正麻烦的从来不是单点乱码，而是终端、PHP 运行时、文件编码、系统路径四者之间任意一环没对齐——看似修一个地方，其实只是把问题推到下一个环节。动手前先跑一遍 chcp、echo %cd%、xxd composer.json | head -n1，比盲目改配置快得多。
