答案是先查缓存真实路径再验属主，执行composer config --global cache-dir和ls -ld $(composer config --global cache-dir)，若属主为root则用sudo chown -R $USER:$USER修复，禁用chmod -R 777。
查清缓存目录真实路径和归属
报错里出现 Writing cache file ~/.composer/cache/... 或类似路径，说明问题锁定在全局缓存目录。但 ~/.composer/cache 只是默认值，实际路径以 composer config --global cache-dir 输出为准——它可能被改过，也可能指向 /root/.composer/cache 这种危险位置。
立刻执行这两步：
-
composer config --global cache-dir—— 看输出是不是你期望的路径（比如/home/alex/.composer/cache） -
ls -ld $(composer config --global cache-dir)—— 看第三列（属主）是不是你当前用户名（$(whoami)）
只要输出里写着 root root 或 www-data www-data，就确认是所有权错配，不是权限位不够。
用 chown 修复归属，禁用 chmod -R 777
chmod -R 777 是毒药，不是解药。它会让 vendor/bin/phpunit 这类可执行文件被 CI 工具拒绝，Git 提交时提示 ownership changed，后续 composer update 可能只失败一半。
正确做法是归还控制权：
- 仅缓存目录归属异常：
sudo chown -R $USER:$USER $(composer config --global cache-dir) - 整个
~/.composer都是root的：sudo chown -R $USER:$USER ~/.composer - 顺手加固可写性（防 umask 导致子目录无写权限）：
chmod -R u+rw ~/.composer（注意：不是777）
sudo 这里只是临时提权跑 chown，不是让你去跑 sudo composer install——后者才是污染源头。
CI/CD 或 Docker 中缓存目录更脆，得提前隔离
GitHub Actions、GitLab CI 或本地 Docker 容器中，基础镜像常让 /tmp 或 ~/.composer/cache 默认属 root，或 UID 不匹配。流水线开头加两行防坑：
mkdir -p .composer-cache && chmod 700 .composer-cache- 再用环境变量绑定：
COMPOSER_CACHE_DIR="$PWD/.composer-cache"
这样缓存完全落在项目本地，彻底避开 ~/.composer 污染。GitLab CI 示例：before_script 里先建目录并授权，script 中加 env: COMPOSER_CACHE_DIR: "$CI_PROJECT_DIR/.composer-cache"。
COMPOSER_HOME 被错误配置为 /root/.composer 怎么办
执行 composer config --global home，如果输出是 /root/.composer 或 /var/www/.composer，说明环境已被污染——所有 global require 和插件都会往那里写，普通用户根本碰不到。
临时验证是否正常：COMPOSER_HOME=$HOME/.composer composer global require laravel/installer
长期解法：
- 删掉污染路径（如存在）：
sudo rm -rf /root/.composer - 确保所有
global命令都不带sudo - 重置全局配置：
composer config -g home $HOME/.composer
最易被忽略的是：错误信息里出现的路径未必是你要修的地方——Permission denied 往往是上游某个临时目录（如 ~/.composer/cache/files/ 下的子目录）权限错配，而 ls -ld 查父目录时可能显示正常，必须盯死报错里那个完整路径。
