vendor目录报permission denied，90%是被root占用而非rwx权限不足；应先用ls -ld vendor确认属主，若为root则删掉vendor和composer.lock后以当前用户重装，或至少chown $user:$user vendor并chmod u+w vendor。
vendor目录报Permission denied，90%是它被root占了，不是权限位（rwx）不够——别急着chmod -R 777，先用ls -ld vendor看属主。
怎么看是不是vendor被root污染了
终端报错里如果出现类似file_put_contents(/path/to/project/vendor/autoload.php): Failed to open stream: Permission denied，问题就锁定在vendor/。立刻执行：
-
ls -ld vendor—— 看输出第一列，比如drwxr-xr-x 12 root root，只要属主是root，就是它 -
ls -l vendor | head -n 3—— 扫一眼前几行子目录归属，确认是否全被root带偏 - 别只查
vendor本身：如果composer.lock也属root（ls -l composer.lock），那整个项目初始化阶段就被污染过
删vendor比chown -R更安全
很多人想用sudo chown -R $USER:$USER vendor强行改回来，但风险高：
- 某些包（如Phar格式的
phpunit）自带只读资源，递归chown可能破坏内部权限标记 - vendor里若有符号链接（比如指向全局bin），
chown -R会把软链目标也拖进去改，引发意外 - 一旦之前混入过root所有子目录，
composer update可能只失败一半，修不干净
更稳妥的做法是清掉重来：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
rm -rf vendor composer.lock-
composer install（确保当前用户能写项目根目录，先touch test && rm test试下） - 如果不能删
composer.lock（如生产部署），至少保证vendor目录本身归属正确：sudo chown $USER:$USER vendor+chmod u+w vendor
Docker或CI里vendor权限错得更隐蔽
宿主机目录挂进容器后默认属root，但容器内以非root用户（如UID 1001）运行，vendor/自然写不了。常见于：
- Docker中直接
docker run -v $(pwd):/app php:8.3 composer install→ 容器内UID和宿主机不一致 - GitHub Actions用了
actions/cache缓存vendor/，解压后继承了错误UID -
composer create-project --no-interaction生成的vendor/默认设为只读
对应解法：
- Docker运行时强制对齐UID：
docker run -u $(id -u):$(id -g) -v $(pwd):/app php:8.3 composer install - CI脚本里加修复步骤：
chown -R $USER:$USER vendor或干脆rm -rf vendor && composer install - create-project后手动放开：
chmod u+w vendor
别忽略缓存目录这个“上游病灶”
有时候vendor/本身没问题，但composer install卡在「Writing cache file」，说明问题出在缓存路径。查它：
-
composer config --global cache-dir→ 得到路径（如~/.composer/cache） -
ls -ld $(composer config --global cache-dir)→ 如果属主是root，连带整个安装流程都会被拦住 - 修复方式二选一：
sudo chown -R $USER:$USER ~/.composer/cache，或换路径：composer config --global cache-dir ~/.cache/composer && mkdir -p ~/.cache/composer && chown $USER:$USER ~/.cache/composer
真正容易被忽略的是：错误信息里写的路径（比如vendor/autoload.php）只是“症状”，真实病灶可能在上游缓存目录或COMPOSER_HOME本身——尤其当composer config --global home返回/root/.composer或/var/www/.composer时，说明全局配置早就跑偏了。
