Composer报parse error本质是JSON文件语法非法，需用jq或python3 -m json.tool精准定位行列错误，再检查BOM、中文引号、末尾逗号、Git冲突残留等；validate仅提示大致位置，不可靠。
Composer 报 parse error，99% 是 JSON 文件本身语法非法，不是 Composer 解析器坏了——它连第一行都读不进去，根本没机会“解析依赖”。别改配置、别清缓存，先让文件合法。
composer.lock 或 composer.json 报 parse error 怎么定位具体行
PHP 自带的 php -l 对 JSON 文件完全无效；真正能报出行号的只有标准 JSON 解析器：
-
jq empty composer.lock：输出空行即合法；报错时明确指出第几行第几列（如parse error: Invalid string: control characters from U+0000 through U+001F must be escaped at line 45, column 8） -
python3 -m json.tool composer.json > /dev/null：没报错即合法；报错也带行列信息，适合没装jq的环境 - 在编辑器里开启「显示不可见字符」：重点查 BOM（
EF BB BF开头）、零宽空格、混用的\r\n和\n、中文引号“”、Unicode 转义不全（如张三没写成\u5f20\u4e09）
报 parse error 但文件看着没问题？查 Git 冲突残留
Git 合并后手动删了 <<<<<< HEAD 却没删干净，或只调了缩进没删标记，JSON 就直接非法：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 哪怕
jq偶然通过，字段顺序错乱、空行位置变动也会导致content-hash校验失败 - 运行
composer install可能静默装错包，或报Invalid argument supplied for foreach() - 执行
composer update --lock是唯一安全重建方式：它完全忽略旧 lock，只读composer.json重新计算哈希和依赖快照 - 执行前必须确保
composer.json已无冲突（git checkout --theirs composer.json或手动整合完）
validate 说 parse error on line X，但打开文件那行是空的
问题往往不在那行本身，而在它前面——JSON 不允许末尾多逗号、不允许注释、不允许单引号字符串：
- 检查上一行末尾是否有逗号：
"php": "^8.1",→ 删掉这个逗号 - 检查是否误用了中文引号：
"name": “my-app”→ 改成英文双引号 - 检查是否写了注释：
// this is a comment→ JSON 不支持，删掉 - 用
file -i composer.json（Linux/macOS）或 Notepad++ 的「编码 → 转为 UTF-8 无 BOM」确认真实编码，Windows 记事本保存极易带 BOM
为什么 php -r "json_decode(...)" 只报 Parse error on line 12，不说列
因为 PHP 的 json_last_error_msg() 只提供粗略位置，它不解析整棵树，只在解析器崩溃那一刻记下行号。真正的错误可能在第 12 行开头、中间或结尾，甚至第 11 行末尾少了个 } 导致第 12 行被当成新语句解析失败。
这种模糊提示最容易让人反复修改第 12 行却毫无进展——必须切到 jq 或 python3 -m json.tool 才能拿到精确列号，否则就是在猜。
