Composer重写composer.json或生成composer.lock报错，99%因PHP、终端、文件三者UTF-8编码未对齐；需确保php.ini中default_charset=UTC-8、mbstring.internal_encoding=UTC-8，终端LANG环境变量正确，且文件保存为UTF-8无BOM。
Composer 重写 composer.json 或生成 composer.lock 时报错，99% 是本地字符编码没对齐——不是文件内容写错了，而是 PHP、终端、文件三者 UTF-8 链路断在某一处。
为什么 composer update 会偷偷改坏 composer.json 的编码
Composer 在读取并重写配置文件时，会用当前 PHP 环境的默认编码读入内容，再以相同编码写出。如果 php.ini 里 default_charset 不是 UTF-8，或终端输入/输出编码不一致，它可能把原本 UTF-8 的中文读成乱码字节，再原样写回去，导致 BOM 消失、引号变乱码、甚至插入不可见控制字符。
- 典型现象：你没动过文件，但
git diff显示composer.json多了ef bb bf或整行中文变成\u4f60\u597d形式 - 触发条件：执行
composer update、composer require、甚至composer validate --strict（后者会尝试重写注释） - 关键验证：运行
file -i composer.json，若输出不是charset=utf-8，说明已被污染；再对比xxd composer.json | head -n1和上次提交的哈希值
php -i | grep default_charset 必须返回 UTF-8，不是 utf8
PHP CLI 的 default_charset 决定了 json_encode()、file_get_contents() 等函数的默认行为。大小写错误或拼写错误（如写成 utf8）会导致输出强制转为 Latin-1，直接破坏中文。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 检查命令：
php -i | grep -E "(default_charset|mbstring\.internal_encoding)" - 必须同时满足：
default_charset => UTF-8且mbstring.internal_encoding => UTF-8 - 修改位置：不是 Apache/Nginx 的
php.ini，而是 CLI 专用配置，通常在php --ini输出的Loaded Configuration File路径下 - 改完必须关掉所有终端窗口重开，否则
php -v看到的仍是旧值
终端输入/输出编码不一致，会导致粘贴进来的中文被二次转义
即使文件和 PHP 都是干净 UTF-8，你在 Git Bash 或 PowerShell 里复制一行含中文的 composer require 命令，也可能因粘贴时解码错位，在 composer.json 中写入 GBK 字节或零宽空格（U+200B），后续 composer update 就会把它当非法字符处理。
- Git Bash 检查：
echo $LANG应输出zh_CN.UTF-8或en_US.UTF-8；若为空或C，运行export LANG=UTF-8临时修复 - PowerShell 检查：
[console]::OutputEncoding和[console]::InputEncoding都得是System.Text.UTF8Encoding - Windows Terminal 用户：确认设置里
"fontFace": "Cascadia Code"或"Fira Code"，并关闭"experimental.retroTerminalEffect"（该选项会干扰 UTF-8 渲染）
composer.json 被重写后出错，别急着重装，先做三件事
一旦发现重写后的文件异常，不要直接 git checkout 回退——Composer 可能已基于错误内容生成了 composer.lock，强行覆盖会导致 vendor 不一致。
- 第一步：用
php -r "json_decode(file_get_contents('composer.json')) || die(json_last_error_msg());"确认是否还能解析；若失败，说明已混入非法字节 - 第二步：用
xxd composer.json | head -n5查看开头是否有ef bb bf，再用grep -P "[\x80-\xFF]" composer.json | head -n3找非 ASCII 字节位置 - 第三步：从上一次 clean 提交中提取原始内容，用 VS Code 新建空白文件 → 粘贴 → 右下角点编码名 →
Save with Encoding→ 选UTF-8（注意不是UTF-8 with BOM）→ 保存覆盖
复杂点在于：BOM、终端输入编码、PHP default_charset 这三环只要漏检一个，下次 composer update 就可能再次污染。排查不能跳步，得按顺序一个个验证。
