快速定位composer.json json错误：运行php -r "$j=file_get_contents('composer.json');$d=json_decode($j);if(!$d)echo json_last_error_msg();"`，输出如“parse error on line 12”即指第12行附近存在末尾逗号、中文引号、bom或注释等非法字符。
composer.json 格式报错，90% 是文件本身不合法 JSON，不是 Composer 问题，别折腾 vendor 或重装 Composer。
怎么快速定位哪一行出错
Composer 不会告诉你具体字符位置，但 json_decode() 可以。直接在终端运行：
php -r "$j = file_get_contents('composer.json'); $d = json_decode($j); if (!$d) { echo json_last_error_msg()."\n"; }"
输出类似 Parse error on line 12 at column 5 就说明第 12 行第 5 列附近有问题。常见诱因包括：
- 末尾多一个逗号（
"require": { "foo/bar": "^1.0", }❌） - 用了中文引号或单引号（
'name': "my/app"❌，必须是"name": "my/app"✅） - 键名没加双引号（
name: "my/app"❌） - 文件开头有不可见的 UTF-8 BOM（Windows 记事本保存极易引入）
- 写了
// 注释或/* ... */—— JSON 标准不支持任何注释
用什么工具验证最靠谱
别依赖 IDE 的“格式化”功能，它可能把错误“美化”得更难排查。优先用这些方式闭环验证：
- 粘贴内容到 jsonlint.com：高亮错误、自动标出行列、还能一键格式化
- VS Code 打开后确认右下角显示的是
JSON（不是Plain Text或JSON with Comments），红色波浪线处就是语法破绽 - 终端跑
python3 -m json.tool composer.json（macOS/Linux 自带；Windows 装 Python 即可）：报错直接带行号，比如Expecting property name enclosed in double quotes
注意：php -l composer.json 没用——它只检查 PHP 语法，对 JSON 完全无效。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
为什么 composer validate 有时不报错但 install 还失败
composer validate 只校验 JSON 结构 + 基础 schema（比如 name 是否存在、格式是否为 vendor/name），**不校验字段值是否合法**。典型漏检场景：
-
"version": "dev-main"：validate 通过，但 install 时解析版本约束失败，报Invalid version string -
"repositories": [{ "type": "gitlab", "url": "..." }]：拼错type（应为"vcs"），validate 不报，install 却卡住 -
"autoload": { "psr-4": { "App\": "src//" } }：路径末尾多斜杠，validate 不管，dump-autoload会警告路径不存在 -
"config": { "allow-plugins": { ... } }：该字段仅 Composer 2.2+ 支持，老版本 validate 不认识也不报错，但实际运行会忽略或报错
所以 CI 流程里不能只跑 composer validate，得加 composer install --dry-run 模拟真实依赖解析。
修复后还报错？别忘了清理残留
JSON 修好了，composer install 却仍失败，大概率是旧缓存或 lock 文件污染：
- 删掉
vendor/目录和composer.lock（除非你明确要保留 lock） - 清缓存：
composer clear-cache，或手动删~/.composer/cache - 重装时加
--no-cache：避免读取损坏的缓存层，composer install --no-cache - 如果改了
autoload，务必再跑一次composer dump-autoload -o，并检查它的输出是否真加载了新配置
多人协作项目里，composer.lock 和 composer.json 不一致是最隐蔽的坑——哪怕 JSON 合法，lock 里存着已删除包的元数据，也会触发解析异常。
