结论是问题不在Composer本身，而在宿主机与容器/虚拟机间UID/GID不匹配或挂载点文件系统不支持权限位；应先用ls -ld定位被拒路径及属主，再针对性修复UID映射或改用容器内可写路径（如/tmp）。
直接说结论：问题不在 Composer，而在宿主机与容器/虚拟机之间 UID 不匹配，或挂载点文件系统不支持权限位 —— 别急着 chmod，先用 ls -ld 看清哪个路径被拒、属主是谁。
为什么 Docker 或 Vagrant 里 vendor/ 总是 Permission denied
典型现象是本地 composer install 没问题，一进容器就报 file_put_contents(./vendor/autoload.php): failed to open stream: Permission denied。根本不是 Composer 配置错了，而是：宿主机上项目目录（比如 /path/to/myapp）挂载进容器后，文件的 UID/GID 没映射对。容器内用户 UID 是 1001，但挂载进来的文件属主是 0（root）或 1000（宿主机另一个用户），导致无写权限。
常见于以下情况：
- Docker 默认以
root用户运行，但挂载的宿主机目录属主是普通用户（如 UID 1001），而容器内没建同 UID 用户 - Vagrant/VirtualBox 共享文件夹默认禁用
chmod和chown，vendor/创建失败后不会报错，只静默卡在写文件阶段 - NFS 挂载时配置了
no_root_squash或 UID 映射规则冲突，导致容器内看到的文件属主永远是 root
修复 Docker 容器内权限：必须指定 UID/GID 启动
不要在容器里 sudo chown -R，那只是临时掩盖；要让挂载进来那一刻文件就“认你”。关键是在 docker run 或 docker-compose.yml 中显式声明用户身份：
- 查宿主机当前 UID/GID：
id -u和id -g，比如输出是1001和1001 - 启动时加
-u 1001:1001：docker run -u 1001:1001 -v $(pwd):/app php:8.3-cli sh -c "cd /app && composer install" - Docker Compose 写法：
services: app: user: "1001:1001" volumes: - .:/app - 如果基础镜像没提前建好对应 UID 的用户（比如 Alpine），得在
Dockerfile里补一句：RUN addgroup -g 1001 -f www && adduser -S www -u 1001
VirtualBox/Vagrant 或 NFS 下无法 chown 怎么办
这类共享文件系统通常不支持 POSIX 权限位，chmod 和 chown 命令会静默失败，ls -l 看起来权限全绿，实际就是不能写。这时不能靠修归属，得绕开：
- 把
vendor/移出共享目录：用COMPOSER_VENDOR_DIR指向容器内可写路径，比如COMPOSER_VENDOR_DIR=/tmp/vendor composer install - 或者改用缓存导向模式：先在容器内干净路径装好依赖，再 rsync 回共享目录（适合 CI 场景）
- VirtualBox 用户可在
Vagrantfile加配置：config.vm.synced_folder ".", "/vagrant", mount_options: ["dmode=777,fmode=666"]
，但这只对新文件生效，已有vendor/还得删掉重来 - 避免在共享目录里跑
composer create-project—— 它解压 tar 包时依赖文件系统权限继承，NFS/VB 下极易生成只读vendor/，后续chmod u+w vendor无效
最常被忽略的一点：错误路径可能不在 vendor/
报错信息里写的路径才是真相。如果看到的是 Writing cache file ~/.composer/cache/repo/... 被拒，说明问题在全局缓存，和挂载点无关；此时应优先执行：composer config -g cache-dir /tmp/composer-cache，再 mkdir -p /tmp/composer-cache。共享环境里，~/.composer 往往落在挂载路径下，而 /tmp 是容器内独立文件系统，天然可写。别让一个缓存路径拖垮整个流程。
