根本原因是vendor/、composer.lock或全局缓存目录属主为root而普通用户运行命令；需用ls -ld定位问题目录，再执行sudo chown -R $USER:$USER修复归属，禁用sudo composer update和chmod 777。
根本原因不是 Composer 不能更新，而是它试图往某个目录写文件时被操作系统拦住了——90% 的 case 都是 vendor/、composer.lock 或全局缓存目录的属主变成了 root，而你正以普通用户身份运行 composer update。
看报错路径，别猜是哪个目录出问题
错误信息里明确带路径的那一行才是线索，比如：
-
file_put_contents(/path/to/myapp/vendor/autoload.php): Permission denied→ 问题在vendor/ -
Could not write to /path/to/myapp/composer.lock→ 问题在composer.lock -
Writing cache file ~/.composer/cache/repo/https---packagist.org/ failed→ 问题在全局缓存目录
立刻执行这三行命令确认归属：
ls -ld vendor/ ls -ld composer.lock ls -ld $(composer config --global cache-dir)
只要任意一行输出中第三列（属主）不是你当前用户名（$(whoami)），就坐实是所有权错配，不是权限位不够。
chown 是解药，sudo composer update 是毒药
用 chmod -R 777 临时放行只会埋雷：CI 工具拒收可执行文件、Git 提示 ownership changed、后续 composer 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 update——后者会让新生成的 vendor/ 子目录混入 root 所有者，下次再 update 可能只失败一半，连 chown -R 都救不回来。
Docker、CI 和 global require 的隐性坑
这些场景下权限问题往往不直接报在 composer update 主流程里，但一样卡住：
- 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 update --no-plugins成功，大概率是某个全局插件（比如hirak/prestissimo）在加载时触发了权限检查
真正容易被忽略的是：一旦 vendor/ 下出现混合属主（部分 root、部分你的用户），composer update 就可能中途静默失败，错误日志里甚至不报权限相关字样——这时候删掉 vendor/ 和 composer.lock 再重来，反而比硬修更可靠。
