答案是所有权问题而非权限位不足，需用chown归还vendor/、composer.lock及~/.composer/cache目录控制权，禁用sudo composer install以防污染。
查清到底是哪个路径被拒绝写入
终端报错里那行带完整路径的提示就是线索，比如 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/cache/ 权限不对；Could not write to /var/www/myapp/composer.lock 就直奔 composer.lock。
立刻执行这三行命令确认归属：
ls -ld vendor/ls -ld composer.lockls -ld $(composer config --global cache-dir)
只要任意一行输出第一列（如 drwxr-xr-x 12 root root）中属主不是你当前用户名（$(whoami)），就坐实是所有权问题，不是权限位（rwx）不够。
用 chown 归还控制权，别碰 chmod -R 777
权限问题本质是“谁拥有它”，不是“它允许谁访问”。chmod -R 777 是临时止痛药，会让 vendor/bin/phpunit 这类可执行文件被 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
sudo 这里只是临时提权执行 chown，不是让你去跑 sudo composer install——后者才是污染源头。一旦误用，vendor/ 下可能混进 root 所有子目录，后续 composer update 可能只失败一半，chown -R 都救不回来，只能删掉 vendor/ 重来。
CI/CD 或 Docker 环境里权限错得更隐蔽
这类环境常以非 root 用户运行，但挂载的宿主机目录默认属 root，容器内用户无权写入 vendor/。
关键处理点：
- Docker 中避免用
root用户执行composer install，改用与宿主机 UID 一致的用户：docker run -u $(id -u):$(id -g) - GitHub Actions 等 CI 工具中，不要在
cache: composer后直接跑composer install，因为缓存解压后可能继承错误权限；加一步chown -R $USER:$USER vendor，或直接删vendor再装 - 如果用
composer create-project初始化项目，注意它默认会把vendor/设为只读（尤其带--no-interaction时），可追加--remove-vcs并手动chmod u+w vendor
global require 报错先盯 COMPOSER_HOME 和执行用户
composer global require 不是“装给所有人用”，只是“装给当前 COMPOSER_HOME 对应的用户”。如果 PHP-FPM 或 cron 用的是 www-data 用户，它根本看不到你个人账户下的 ~/.composer。
查当前生效路径：composer config --global home。如果输出是 /var/www/.composer 或 /root/.composer，就得确认该路径属主是不是当前执行用户。
更稳妥的做法是把全局命令装到用户空间：
mkdir -p ~/bincomposer config -g bin-dir ~/bin- 加入
PATH：export PATH="$HOME/bin:$PATH"
如果之前用过 sudo composer global require，生成的二进制文件（如 laravel）很可能落在 /root/.composer/vendor/bin/，普通用户根本执行不到。
