问题根源是目录属主被sudo污染为root，而非权限位不足；需用chown修复属主，如sudo chown -R $USER:$USER vendor/ composer.lock及全局缓存目录。
根本不是权限位（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 /path/to/composer.lock→ 问题在composer.lock -
Writing cache file ~/.composer/cache/repo/https---packagist.org/→ 问题在全局缓存目录
别猜，直接拿这个路径执行 ls -ld /path/to/parent/dir，看输出第三列是不是你的用户名（$(whoami)）。第一列是权限位，第三列才是属主——看串行就白查。
用 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，再补一句chmod -R u+rw ~/.composer防umask导致子目录不可写
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且错误出现在生成.bat文件时 → 大概率是杀软拦截，临时禁用 Windows Defender 实时防护，或改用 Git Bash 运行
真正难搞的不是第一次修复，而是嵌套污染：一次 sudo composer install 可能让 vendor/ 下混进个别 root 所有子目录，ls -la vendor/ 才能发现；这种情况下 chown -R 仍有效，但如果已破坏 autoload 结构，删掉 vendor/ 重来反而更快。
