报错路径含vendor/说明属主为root，应执行sudo chown -R $USER:$USER vendor/修复所有权，而非chmod 777；若composer.lock也报错则一并修复。
file_put_contents(.../vendor/autoload.php): Permission denied 怎么修
报错路径里明确出现 vendor/，说明问题锁定在项目本地目录，不是全局配置或网络问题。这不是文件没开写权限，而是整个 vendor/ 目录树被 root 占了——常见于误用 sudo composer install 后遗留的归属污染。
- 先确认归属：
ls -ld vendor/，若第三列显示root，就是它了 - 修复所有权（不是改权限）：
sudo chown -R $USER:$USER vendor/（注意末尾斜杠，否则子目录可能漏掉） - 如果
composer.lock也报错，一并加入：sudo chown -R $USER:$USER vendor/ composer.lock - 禁用
chmod -R 777：它会让vendor/bin/phpunit这类可执行文件被 CI 工具拒绝，Git 提交时还会提示 ownership changed
Writing cache file ~/.composer/cache/ 失败怎么定位
错误信息里只要出现 ~/.composer/cache/ 或 /repo/https---packagist.org/，就说明全局缓存目录被 root 污染了。这个路径常被忽略，但一旦出问题，所有后续 composer install、global require 都会静默失败。
- 查真实缓存路径：
composer config --global cache-dir - 检查归属：
ls -ld $(composer config --global cache-dir) - 若属主不是当前用户，直接修复：
sudo chown -R $USER:$USER $(composer config --global cache-dir) - 整片
~/.composer都是 root？执行：sudo chown -R $USER:$USER ~/.composer，再加固：chmod -R u+rw ~/.composer（不是 777）
Docker 或 CI 环境下 vendor 权限反复出问题
基础镜像（如 php:alpine）常让 /tmp 或 ~/.composer/cache 默认属 root，或容器 UID 与宿主机不一致。问题不报在主流程，但会卡住后续脚本执行。
- 流水线开头加两行防坑：
mkdir -p .composer-cache && chmod 700 .composer-cache - 绑定缓存路径：
COMPOSER_CACHE_DIR="$PWD/.composer-cache" - Docker 容器启动时指定 UID：
user:1000（匹配宿主机），或 Dockerfile 中加USER 1001 - 宿主机挂载进容器的目录（如
-v $(pwd):/app）要确保 UID 一致，否则文件在容器内不可写
composer global require 报错但没提示具体路径
这类问题往往不报路径，但本质仍是归属错配——COMPOSER_HOME 被指向了 /root/.composer 或 /var/www/.composer，导致普通用户根本访问不到。
- 查当前生效路径：
composer config --global home - 若输出是
/root/.composer，说明环境已被污染，立刻修复：sudo chown -R $USER:$USER $(composer config --global home) - 避免未来踩坑：改用用户级 bin 目录：
mkdir -p ~/bin && composer config -g bin-dir ~/bin，再把~/bin加入$PATH - 装完命令仍提示
command not found？检查composer config -g bin-dir输出路径是否在$PATH中，不在就补上：export PATH="$HOME/bin:$PATH"
最易被忽略的是嵌套污染：一次 sudo composer install 可能让 vendor/ 下混进个别 root 所有子目录，ls -la vendor/ 才能发现；这种情况下 chown -R 仍有效，但若已破坏 autoload 结构，删掉 vendor/ 重来反而更快。
