根本原因是目录归属错误而非权限位不足，vendor/、composer.lock或~/.composer被sudo污染致属主为root，需用sudo chown -R $USER:$USER修复，禁用chmod -R 777。
根本不是权限位（rwx）不够，而是目录“主人不对”——vendor/、composer.lock 或 ~/.composer 被 sudo composer install 污染过，属主变成 root，而你正以普通用户运行后续命令。
看报错路径，立刻定位问题目录
终端输出的错误行里一定带完整路径，比如：file_put_contents(/home/user/project/vendor/autoload.php) 或 Writing cache file ~/.composer/cache/repo/https---packagist.org/。这行就是线索。
- 执行
ls -ld vendor/：如果输出第一列含root root，问题就在vendor/ - 执行
ls -ld composer.lock：同理，属主是root就得一起修 - 执行
ls -ld $(composer config --global cache-dir)：查全局缓存归属，常被忽略但一样卡住
用 chown 修复所有权，别碰 chmod -R 777
chmod 控制“能不能读写”，chown 才决定“这东西归不归你”。误用 chmod -R 777 会触发 CI 工具拒绝、安全扫描告警、Git 提示 ownership changed。
- 修复项目内目录：
sudo chown -R $USER:$USER vendor/ composer.lock - 修复全局缓存：
sudo chown -R $USER:$USER $(composer config --global cache-dir) - 整个
~/.composer都属root？直接重置：sudo chown -R $USER:$USER ~/.composer
Docker / CI / 嵌套污染场景怎么处理
这些地方权限问题不报在主流程，但一样中断后续步骤，且修复方式不同。
- Docker 中宿主机 UID 是 1000，容器却以 UID 0 运行 → 启动时加
user:1000，或修复时用数字 UID：sudo chown -R 1000:1000 vendor/ - CI 流水线（如 GitHub Actions）默认非 root 用户 → 开头加
mkdir -p .composer-cache && chmod 700 .composer-cache，再设COMPOSER_CACHE_DIR="$PWD/.composer-cache" - 嵌套污染最难排查：一次
sudo composer install可能让vendor/下混进个别root所有子目录，ls -la vendor/就能发现；这种情况下chown -R仍有效，但若已破坏 autoload 结构，删掉vendor/重来反而更快
最容易被忽略的是缓存目录里的插件和 auth.json ——它们常因镜像源 token 配置被 sudo 写入而卡住，得单独检查 ~/.composer/cache/plugins/ 和 ~/.composer/auth.json 的属主。
