根本原因是目录属主为root而非当前用户，需用sudo chown -r $user:$user修复vendor/、composer.lock或~/.composer归属，禁用chmod 777和sudo composer install。
vendor/ 或 composer.lock 报 Permission denied 是谁的问题
不是你没权限，是目录“认错了主人”——vendor/ 或 composer.lock 的属主（owner）是 root，而你现在以普通用户运行 composer install。系统一看：这目录不归你管，拒绝写入。
报错里一定带路径，比如：
-
file_put_contents(/home/me/project/vendor/autoload.php): Permission denied→ 锁定vendor/ -
file_put_contents(/home/me/project/composer.lock): Permission denied→ 锁定composer.lock
立刻验证：ls -ld vendor/ composer.lock。若第三列显示 root root，就是它了。
~/.composer 被锁死会导致全局命令失败
所有 composer global require、composer self-update 或缓存操作卡住，大概率是因为 ~/.composer 目录或其子目录（如 cache-dir、bin-dir）属主不是你。
查归属：ls -ld ~/.composer 和 ls -ld $(composer config --global cache-dir)。若任一输出 owner 不是 $(whoami)，就确认污染。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
常见诱因：
- 曾经执行过
sudo composer global require laravel/installer - CI 流水线用 root 用户跑了
composer install，又挂载到宿主机 -
COMPOSER_HOME被设成/root/.composer或/var/www/.composer
为什么 chmod 777 和 sudo composer install 都是错的
chmod -R 777 vendor/ 解不了问题，还引入新风险：
- CI 工具会直接拒绝执行
vendor/bin/phpunit这类 world-writable 可执行文件 - Git 提交时提示
ownership changed，干扰 diff - 它改的是“能不能读写”，但真正卡住你的是“这东西归不归你”
sudo composer install 更危险：
- 它把整个
vendor/目录树设为root所有，后续composer update可能只写一半就失败 - IDE 自动索引、
git status、甚至rm -rf vendor/都可能被拒 - 修复成本飙升：有时
chown -R都救不回 autoload 结构，只能删掉重来
Docker / CI / Windows 下的隐性所有权错配
这些环境不报错在明面，但一样中断流程：
- Docker：宿主机 UID 是 1000，容器默认用 UID 0（root）启动 → 挂载卷后文件不可写。应加
user:1000或修复时用数字 UID：sudo chown -R 1000:1000 vendor/ - GitHub Actions：默认非 root 用户，但缓存复用可能带入 root 所有旧
vendor/→ 开头加rm -rf vendor/ composer.lock最稳 - Windows + WSL：错误出现在生成
.bat文件时？大概率是 Windows Defender 实时防护拦截，临时禁用即可
最容易被忽略的是嵌套污染：一次 sudo composer install 可能让 vendor/composer/ 下某个子目录悄悄变成 root 所有，ls -la vendor/ 才看得见。这种情况下 chown -R 仍有效，但若 autoload 已损坏，删掉重装反而更快。
