答案是权限错配而非权限不足，核心在于目录属主为root，需用chown归还所有权而非chmod加权；先据报错路径定位vendor/、composer.lock或缓存目录，再执行sudo chown -R $USER:$USER精准修复。
别用 sudo composer install，这是绝大多数权限错误的起点。 问题不在 Composer 本身，而在它写入的目录（vendor/、composer.lock、~/.composer/cache/）被 root 占有，普通用户自然没权改——修复核心是归还所有权，不是加权限。
报错路径就是线索，三秒定位问题目录
终端报错里带完整路径的那一行，直接告诉你该修哪儿。比如：
-
file_put_contents(/home/alex/myapp/vendor/autoload.php): Failed to open stream: Permission denied→ 锁定vendor/ -
Writing cache file ~/.composer/cache/repo/https---packagist.org/...→ 锁定$(composer config --global cache-dir) -
Could not write to /var/www/myapp/composer.lock→ 锁定composer.lock
立刻执行这三行查归属：
ls -ld vendor/ ls -ld composer.lock ls -ld $(composer config --global cache-dir)
只要任意一行第一列显示 root（如 drwxr-xr-x 12 root root），就坐实是所有权问题。
chown 是解药，chmod -R 777 是毒药
改权限 ≠ 改归属。chmod 控制“能不能读写”，chown 才决定“这东西归不归你”。误用 chmod -R 777 会带来实际后果：
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
-
vendor/bin/phpunit这类可执行文件被 CI 工具或安全扫描器直接拒收 - Git 提交时提示
ownership changed - 后续
composer update可能只失败一半，chown -R都救不回来
正确做法是归还控制权：
- 修复项目内目录：
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 就可能让 vendor/ 下混进 root 所有子目录，后续 composer update 可能只失败一半，chown -R 都救不回来，只能删掉 vendor/ 重来。
