答案是先修复JSON语法错误：运行php -r命令或用jsonlint.com定位第12行第5列附近的非法字符，如末尾逗号、中文引号、BOM头等，确保composer.json为合法JSON后再执行install。
composer.json不是合法JSON怎么办
直接报错 JSON parse error on line 12 at column 5，说明文件根本没通过基础语法校验，composer install 连依赖解析环节都进不去。别急着删 vendor 或换镜像，先修 JSON。
- 用
php -r "json_decode(file_get_contents('composer.json')) || die('JSON error: '.json_last_error_msg());"跑一遍，PHP 8.0+ 会额外输出偏移量（如offset 123），配合编辑器「显示不可见字符」功能，一眼就能定位到那个多出来的逗号、中文引号或 BOM 头 - 粘贴内容到
jsonlint.com，它会高亮标出非法字符：常见的是末尾逗号、全角冒号、零宽空格（U+200B）、UTF-8 BOM（ef bb bf） - 用
jq '.' composer.json（需提前装jq）——失败时直接报行列号，比composer validate更底层、更敏感
为什么composer validate通过了但install还失败
composer validate 只检查 JSON 结构 + 基础 schema（比如 name 是否存在、require 是否为空），它不验证语义合法性。真正暴露问题的是安装阶段。
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+ 稳定支持）
镜像配置写错导致JSON decode error
某些错误看着像 JSON 解析失败，实际是镜像返回了 HTML 页面（比如人机验证页）或带 BOM 的乱码响应，被 Composer 当作 JSON 解析了。
- 确认镜像 URL 正确：
composer config -g repo.packagist输出必须是单数repo.packagist，不是repos.packagist；结尾必须有/，否则拼出/composerpackages.json这种非法路径 - 手动验证镜像可用性：
curl -I https://mirrors.aliyun.com/composer/packages.json必须返回HTTP/2 200；若返回 HTML，说明该镜像不适合自动化场景 - 执行
composer clear-cache，Windows 用户还得手动删%LOCALAPPDATA%Composercache；再删掉vendor/和composer.lock—— 后者硬编码了旧 provider 地址，不删就一直重试失败路径
改了config.json却没生效的隐藏原因
手动编辑 ~/.composer/config.json 没效果？大概率是 Composer 优先读了另一个位置。
- 新版 Composer 优先读
~/.config/composer/config.json，旧文件会被静默忽略 - JSON 格式非法（多逗号、单引号、未转义斜杠）会导致整个配置文件被跳过，不报错也不提示
- 设置了
COMPOSER_HOME环境变量但指向空目录或权限不足目录，composer config --global写入失败却不报错 - 某些字段（如
process-timeout）只在命令执行时读取，改完需重启终端或清除 opcache（PHP 8.0+ CLI 默认启用）
validate 阶段暴露，得靠 --dry-run 或真实请求才能揪出来。 
