根本原因是目录归属错误而非权限位不足，需用sudo chown -R $USER:$USER修复vendor/、composer.lock或~/.composer归属，禁用chmod -R 777，避免sudo composer install造成污染。
根本不是权限位（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（
root）运行 → 启动时加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且错误出现在生成.bat文件时 → 大概率是杀软拦截，临时禁用 Windows Defender 实时防护，或改用 Git Bash 运行
最容易被忽略的是嵌套污染：一次 sudo composer install 可能让 vendor/ 下混进个别 root 所有子目录，ls -la vendor/ 才能发现；这种情况下 chown -R 仍有效，但如果 autoload 已损坏，删掉 vendor/ 和 composer.lock 重来反而更快。
