答案是归属错乱而非权限位不足，需用sudo chown -r $user:$user修复vendor/、composer.lock或~/.composer缓存目录属主，禁用chmod -r 777。
报错里带 Permission denied 就不是权限位问题，是归属错乱
根本不是当前用户没“读写权”，而是目录“不认你这个人”。sudo composer install 之后再切回普通用户，vendor/ 和 composer.lock 的属主已经是 root，操作系统直接拒绝你写入——哪怕 chmod 设成 777 也没用。
立刻定位：看报错行里明确写出的路径，比如 file_put_contents(/home/me/myapp/vendor/autoload.php): Permission denied → 问题就在 vendor/；Could not write to /home/me/.composer/cache/... → 是全局缓存目录被 root 占了。
- 执行这三行查归属：
ls -ld vendor/、ls -ld composer.lock、ls -ld $(composer config --global cache-dir) - 只要任意一行第一列显示
root（如drwxr-xr-x 12 root root），就确认是归属问题，不是权限位不够 - 别碰
chmod -R 777：它会让vendor/bin/phpunit这类可执行文件被 CI 工具拒收，Git 提交时还报ownership changed
chown -R $USER:$USER 才是唯一解药
chown 是改“谁拥有它”，chmod 是改“它允许谁访问”——前者治本，后者掩耳盗铃。
- 修复项目内目录：
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、global require 的隐性坑
这些场景下权限问题常藏在后台，不报在主流程里，但一样卡住。
- Docker 中宿主机 UID 是 1000，容器却以 UID 0（root）运行 → 挂载卷时加
user:1000或 Dockerfile 里加USER 1001 -
composer global require报错？先查composer config --global home，如果输出是/root/.composer或/var/www/.composer，说明环境已被污染 - 插件干扰：加
--no-plugins --no-interaction试试，composer install --no-plugins成功，大概率是某个全局插件（比如hirak/prestissimo）在/tmp创建 socket 后没释放权限
嵌套权限混乱最容易被忽略
一次 sudo composer install 可能让 vendor/ 下混进个别 root 所有子目录，ls -la vendor/ 就能发现。这时候别硬修，直接 rm -rf vendor/ 再重装更省事——前提是确认当前用户对项目根目录有写权限。
Windows 下报 Access is denied 多半不是归属问题，而是杀软拦截 .bat 文件生成，或 PowerShell 权限模型卡住；Linux/macOS 上，www-data 和 CLI 用户不一致时，得靠 chgrp -R www-data + chmod -R g+w 解决 Web 写入冲突。
