根本原因是目录归属错误而非权限位不足，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): Permission denied→ 问题在vendor/ -
Could not write to /home/user/project/composer.lock→ 修composer.lock -
Writing cache file ~/.composer/cache/repo/https---packagist.org/→ 查全局缓存目录
立刻执行这三行确认归属：
ls -ld vendor/ ls -ld composer.lock ls -ld $(composer config --global cache-dir)
只要任意一行输出第三列不是你当前用户名（$(whoami)），就是所有权错配。
用 chown 修复归属，别碰 chmod -R 777
chmod 控制“能不能读写”，chown 才决定“这东西归不归你”。误用 chmod -R 777 会触发 CI 拒绝、Git 提示 ownership changed、后续 dump-autoload 静默失败。
正确操作是归还控制权：
- 项目内目录：
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
sudo 这里只是临时提权跑 chown，不是让你去跑 sudo composer install——后者才是污染源头。
Docker / CI / Windows 下的隐性坑
这些场景下权限问题不报在主流程，但一样中断后续步骤，且修复方式不同：
- 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" - Windows 下报
Access is denied且路径指向%APPDATA%\Roaming\Composer\Cache→ 用管理员 PowerShell 执行：icacls "$env:APPDATA\Roaming\Composer\Cache" /grant "$env:USERNAME:(OI)(CI)F" /t
最容易被忽略的是嵌套污染：一次 sudo composer install 可能让 vendor/ 下混进个别 root 所有子目录，ls -la vendor/ 才能发现；这种情况下 chown -R 仍有效，但如果 autoload 结构已破坏，删掉 vendor/ 重来反而更快。
