Windows终端默认GBK编码与Composer的UTF-8输出不兼容导致中文乱码；需执行chcp 65001切换编码，升级Composer至2.5.8+修复检测逻辑，并确保composer.json为无BOM的UTF-8格式。
Windows CMD/PowerShell 中执行 composer 显示中文乱码
根本原因是 Windows 终端默认使用 GBK 编码，而 Composer 输出（尤其是错误提示、包描述、composer.json 注释）通常是 UTF-8。终端无法正确解码，就显示问号或方块。
临时解决最直接：在运行前切换终端编码为 UTF-8。
- CMD 下先执行
chcp 65001（启用 UTF-8），再运行composer install - PowerShell 更稳妥：启动时加参数
powershell -ExecutionPolicy RemoteSigned -Command "chcp 65001 | Out-Null; composer install" - 注意：
chcp 65001不会持久生效，关掉窗口就重置
PHP 内部输出中文被截断或乱码（如 composer dump-autoload 后的提示）
这和 PHP 的默认输出编码无关，而是 Composer 自身依赖的 symfony/console 组件对 Windows 控制台的支持逻辑问题——它会检测 STDOUT 是否支持 UTF-8，但有时误判为不支持，于是自动降级为 ANSI 转义，导致中文崩坏。
强制让 Symfony Console 走 UTF-8 路径：
- 设置环境变量：
set COMPOSER_NO_INTERACTION=1+set PHP_BINARY=php（避免某些封装脚本干扰） - 更可靠的是升级到 Composer 2.5.8+，该版本修复了 Windows 下
isUtf8Terminal()检测逻辑 - 若仍异常，可临时加
--no-ansi参数绕过颜色和 Unicode 控制符：composer update --no-ansi
composer.json 里写中文注释或包描述，安装时报 JSON decode error: Syntax error
不是 Composer 本身问题，是编辑器保存文件时用了带 BOM 的 UTF-8。PHP 的 json_decode() 对 BOM 敏感，一读就报错。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
检查并修正文件编码：
- 用 VS Code 打开
composer.json，右下角看编码显示，如果是UTF-8 with BOM，点它 → 选择Save with Encoding→UTF-8 - Sublime Text：菜单
File → Save with Encoding → UTF-8 - 命令行快速验证：
file -i composer.json（Linux/macOS）或xxd composer.json | head -n1看前几个字节是否为ef bb bf（BOM）
Git Bash 中 composer 中文正常，但粘贴命令后乱码
Git Bash 默认终端模拟的是 MinTTY，它对 UTF-8 支持较好，但“粘贴”行为受剪贴板编码影响。Windows 剪贴板本身不带编码标记，粘贴时容易按当前终端 locale 解码失败。
稳定做法只有两个：
- 粘贴前手动确保 Git Bash 终端编码为 UTF-8：右键标题栏 →
Options → Change Locale → Character set: UTF-8 - 彻底规避粘贴：用
cat > composer.json手动输入，或从 VS Code 复制纯 UTF-8 内容（确认无 BOM） - 别依赖 Ctrl+V 粘贴含中文的长命令，尤其带
--name或--description参数时
实际项目里最容易被忽略的，是团队共用同一份 composer.json 但各自编辑器编码设置不同——有人存成 GBK，有人存成 UTF-8 with BOM，CI 流水线一跑就挂。统一用 VS Code + EditorConfig 插件，强制 charset=utf-8 和 strip_bom=true 是最省事的防线。
