答案是直接运行php -r命令或使用jsonlint.com定位：执行php -r "json_decode(file_get_contents('composer.json')) || die('JSON error: '.json_last_error_msg());"可获精确错误提示，PHP 8.0+附带偏移量；粘贴内容至jsonlint.com则高亮标出非法字符，如末尾逗号、中文引号、BOM头或全角符号。
Composer 配置文件格式错误，90% 以上不是网络或权限问题，而是 composer.json 本身语法非法、编码污染或字段值违规 —— 直接修复比重装 Composer 或换镜像更有效。
怎么快速定位 composer.json 的具体错误位置
报错里那句 JSON parse error on line 12 at column 5 就是精确坐标，别扫全文件。问题一定在第 12 行第 5 列附近。
- 直接运行：
php -r "json_decode(file_get_contents('composer.json')) || die('JSON error: '.json_last_error_msg());"，PHP 8.0+ 还会附带偏移量（如offset 123），配合编辑器「显示不可见字符」就能秒定位 - 粘贴内容到 jsonlint.com：高亮标出非法字符，比如末尾逗号、中文引号、全角冒号、零宽空格（
U+200B）、UTF-8 BOM 头（ef bb bf） - 用
jq '.' composer.json（需先brew install jq或apt install jq）：失败时直接输出行列号，比composer validate更底层、更敏感
composer validate 为什么通过了但 install 还失败
composer validate 只校验 JSON 结构 + 基础 schema（比如 name 是否存在、require 是否为空），它不检查依赖是否真实存在、版本约束是否合法、autoload 路径是否存在。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 典型漏检：
"require": { "monolog/monolog": "dev-main" }——validate通过，install报Could not find package -
"autoload": { "psr-4": { "App\": "src/" } }，但项目里根本没有src/目录 ——validate通过，dump-autoload却警告路径不存在 - 用了
"config": { "platform": { "php": "8.3" } }，但本地 PHP 是 8.1 ——validate不检查运行时兼容性 - 真正暴露语义问题的命令是：
composer install --dry-run --no-interaction（Composer 2.5+ 稳定支持）
镜像配置写在哪儿？怎么验证它没写错
镜像配置不在 composer.json，而在 config.json（全局：~/.composer/config.json；项目级：composer.json 的 config 字段）。composer validate 完全不校验它。
- 验证
config.json的 JSON 语法：php -r "$j = file_get_contents('config.json'); $d = json_decode($j); if (!$d) { echo 'JSON error: ' . json_last_error_msg() . \"\n\"; }" -
repositories数组里每个对象必须含type和url字段，缺一不可；type只能是composer、package、vcs等白名单值 -
url必须是完整可访问地址，以https://或http://开头；packagist 镜像不能写成https://mirrors.aliyun.com/composer/后少斜杠 - 配了多个镜像，必须显式禁用原源：
"packagist.org": false，否则 Composer 仍会回源 - 字段名大小写敏感：
repositores（少个r）会被忽略，不报错也不生效
Windows 记事本保存的 composer.json 为什么总报错
因为记事本默认保存为 UTF-8 with BOM，而 Composer 要求严格 UTF-8 无 BOM。BOM 是开头三个不可见字节 ef bb bf，json_decode() 把它当非法字符直接崩。
- 确认方法：
file -i composer.json，输出含charset=utf-8才对；若为charset=utf-8-with-bom，说明有问题 - Linux/macOS 修复：
sed -i '1s/^\xEF\xBB\xBF//' composer.json（GNU sed）或gsed -i '1s/^\xEF\xBB\xBF//' composer.json（macOS） - Windows 下：Notepad++ → 编码 → 转为「UTF-8 无 BOM」；VS Code 右下角点击编码名 →「Save with Encoding」→选「UTF-8」（注意不是「UTF-8 with BOM」）
- VS Code 用户可安装「JSON Tools」插件，右键「Prettify JSON」——格式化失败即暴露隐藏问题
最常被忽略的一点：编辑器自动保存时可能把 composer.json 存成带 BOM 或混入零宽字符的版本，哪怕肉眼看不出任何异常 —— 这类问题只能靠命令行工具验证，不能只信编辑器高亮。
