Composer 报 JSON 解析错误本质是 PHP json_decode() 失败，常见于末尾缺括号、中文标点、BOM 或不可见字符；validate 不校验字段值和 schema，需用 php -r 或 jsonlint 快速定位。
Composer 的 composer.json 写错，90% 不会直接告诉你“字段拼错了”，而是抛出模糊的 JSON 解析失败提示——它根本没机会读到你写的逻辑，就在第一关卡死了。
报错典型长这样：JSON parse error、unexpected ','、unexpected end of file
这些不是 Composer 特有的错误，是 PHP json_decode() 报的底层解析失败。常见表现：
-
JSON parse error: syntax error, unexpected end of file→ 文件末尾缺大括号}或中括号]，或粘贴时截断了 -
JSON parse error on line 12 at column 5→ 第 12 行第 5 列附近有非法字符（大概率是中文逗号、全角引号、末尾多逗号） -
file_get_contents(): Failed to open stream: No such file or directory→ 看似路径问题，实则是 JSON 解析失败后 Composer 误判了文件结构，导致后续路径推导出错 -
Could not load package xxx in <code>composer.json→ 并非包不存在，而是解析中途崩溃，连require都没读完
为什么 composer validate 有时不报错，但 install 却崩了
composer validate 默认只做两件事：基础 JSON 解析 + 检查顶层必需字段（如 name、require）是否存在。它完全不管值合不合理。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
-
"type": "lib"→ JSON 合法，validate通过；但 schema 要求只能是"library"，--strict才报错 -
"autoload": {"psr-4": {"App": "src//"}}→ 双斜杠路径 JSON 合法，validate不拦；dump-autoload才会警告目录不存在 -
"repositories": [{"type": "gitlab", "url": ""}]→type应为"vcs"，validate完全不校验，install卡在 fetch 阶段 -
"config": {"allow-plugins": {}}→ 该字段仅 Composer 2.2+ 支持，老版本validate视而不见，运行时直接忽略或报未定义
用 php -r 快速验证纯 JSON 语法，绕过所有干扰
别等 composer validate 绕弯子，直接调 PHP 原生解析器，秒出真因：
php -r "$j = file_get_contents('composer.json'); $d = json_decode($j); if (!$d) { echo json_last_error_msg()."
"; }"
- 输出
Syntax error→ 确认是 JSON 结构问题（逗号、引号、BOM） - 输出
Control character error→ 锁定不可见字符（零宽空格、BOM 头），用xxd composer.json | head查ef bb bf - 输出
Unexpected control character→ 多半是 Windows 记事本保存带 BOM，或复制粘贴进去了隐藏符号 - 这个命令不依赖 Composer、不联网、不查 schema，CI 中可作为兜底校验步骤
编辑器和编码陷阱比语法更难排查
VS Code 显示“无波浪线”，不代表文件安全。很多问题藏在元数据里：
- 右下角必须显示
JSON（不是Plain Text或JSON with Comments），否则不触发语法高亮和 schema 校验 - 编码必须是
UTF-8 without BOM：Windows 记事本默认带 BOM，file -i composer.json（Linux/macOS）或 Notepad++ 的“编码”菜单可确认 - 别信“格式化”按钮：它可能把
"App": "src/"自动补成"App\": "src/"—— 看似整齐，但反斜杠转义反而非法 - 粘贴内容到 jsonlint.com 是最省力的闭环验证方式：高亮错误、标出行列、还能一键格式化
真正麻烦的从来不是“怎么写对”，而是“为什么看起来对，却跑不通”——BOM、不可见字符、schema 和 runtime 的校验层级错位，才是日常翻车的主因。
