根本原因是windows终端（cmd/powershell）默认gbk编码（chcp 936）与composer的utf-8输出不匹配，导致中文解码错位；临时方案为cmd执行chcp 65001或powershell设置[console]::outputencoding = [system.text.encoding]::utf8，永久方案需修改注册表autorun值或powershell配置文件。
为什么 composer install 输出中文乱码？
根本原因是 Windows 命令提示符（CMD）或 PowerShell 默认使用 GBK 编码，而 Composer（基于 PHP）在调用 `curl` 或输出日志时，多数情况下按 UTF-8 编码生成中文内容。两者不匹配，导致显示为方块、问号或错位字符。
这不是 Composer 配置问题，也不是镜像源本身的问题——哪怕你切到阿里云、腾讯云等中文镜像，只要终端编码没对齐，照样乱码。
- 常见现象：
正在安装依赖...显示成жЩЇг…ЄеП‘еЌЂдѕќиї›иЎЊдё...或一堆 - 注意：WSL、Git Bash 不在此列，它们默认 UTF-8，基本无此问题
- PowerShell 7+ 默认 UTF-8，但旧版 PowerShell（5.1）和 CMD 仍默认 GBK
临时修复：启动 CMD/PowerShell 前切换代码页
最轻量、无需改配置的方法：每次打开终端后先执行编码切换命令，再运行 Composer。
- CMD 下运行：
chcp 65001（65001 = UTF-8），然后再执行composer install - PowerShell（5.1）下运行：
[Console]::OutputEncoding = [System.Text.Encoding]::UTF8，再运行composer install - 如果用了
composer create-project等带交互的命令，也建议提前设置，否则中文提示可能被截断或无法识别输入
⚠️ 注意：chcp 65001 只对当前窗口生效；关闭后重开又得再输一次。
永久生效：修改系统控制台默认代码页（仅限 CMD）
想一劳永逸解决 CMD 乱码，可修改 Windows 注册表让 CMD 启动即用 UTF-8 ——但要谨慎操作，避免影响其他 GBK 依赖程序（如某些老 DOS 工具）。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 打开注册表编辑器，定位到：
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Command Processor - 新建一个字符串值（REG_SZ），命名为
AutoRun - 双击它，把数值数据设为：
chcp 65001 >nul - 重启 CMD 即生效；之后所有新打开的 CMD 窗口都会自动切换 UTF-8
PowerShell 不支持该方式，需靠配置文件（见下一条）。
PowerShell 永久设置 UTF-8 输出编码
PowerShell 的编码行为由启动脚本控制，推荐写入用户级配置文件，不影响系统全局。
- 运行
$PROFILE查看配置文件路径（通常为：C:\Users\{用户名}\Documents\PowerShell\Microsoft.PowerShell_profile.ps1） - 若路径不存在，用
New-Item -Path $PROFILE -Force创建目录和文件 - 用文本编辑器打开该文件，添加一行：
[Console]::OutputEncoding = [System.Text.Encoding]::UTF8 - 保存后重启 PowerShell，
composer输出中文就正常了
⚠️ 如果你用的是 VS Code 内置终端，默认调用的是 PowerShell，记得确认它加载的是你改过的 profile；可通过 $PROFILE 在终端里检查路径是否一致。
真正麻烦的不是改哪一行代码，而是不同终端（CMD/PowerShell/VS Code 终端/ConEmu/Terminal App）各自维护一套编码逻辑。盯住你实际用的那个终端，只改它，别试图“统一全部”。
