根本原因是宿主机挂载目录UID/GID与容器用户不匹配，导致vendor/属主混乱；应通过docker run -u或docker-compose user指定与宿主机一致的UID/GID，避免bind mount vendor本身及chmod等危险操作。
vendor 权限冲突在 Docker 镜像里为什么总报 Permission denied
根本不是镜像里缺权限，而是宿主机挂载目录的 UID/GID 和容器内用户不一致。Docker 默认以 root 运行容器，但你用 docker run -v $(pwd):/app 挂进去的 vendor/ 在宿主机上属 $USER（比如 UID 1001），进容器后却变成 UID 0（root）视角下的“不可写目录”——file_put_contents(/app/vendor/autoload.php) 直接失败。
常见错误现象：
- CI 构建时
composer install卡在Writing cache file或failed to open stream - 本地
docker-compose up启动后 PHP 报Class not found，但ls -l vendor/显示文件全在 -
composer install成功，但phpunit执行时报Permission denied（其实是 bin 脚本被挂载成只读）
用 -u 参数对齐 UID 是最直接有效的解法
别改 chmod，也别在 Dockerfile 里 RUN chown -R www-data:www-data vendor/——那只是把问题从运行时挪到构建时，且破坏 layer 缓存。
正确做法是让容器内进程以和宿主机相同的 UID 启动：
- 构建阶段：在
Dockerfile中用USER 1001（或你宿主机的 UID）声明非 root 用户 - 运行阶段：启动时显式指定 UID：
docker run -u $(id -u):$(id -g) -v $(pwd):/app php:8.3 composer install - Compose 场景：在
docker-compose.yml的 service 下加user: "${UID}:${GID}"，并在 shell 中export UID=$(id -u) GID=$(id -g)
这样 vendor/ 在容器内看到的属主就是它自己，无需额外 chown，也不会污染镜像层。
CI 和缓存场景下 vendor 权限错得更隐蔽
GitHub Actions 或 GitLab CI 常用 actions/cache 缓存 vendor/，但解压后文件继承的是 runner 的 UID（如 1001），而你的 job 可能以不同用户运行（比如 www-data），导致权限错配。
应对策略：
- 缓存前先统一属主：
chown -R $USER:$USER vendor/再压缩上传 - 缓存后强制修复：
chown -R $USER:$USER vendor/作为 restore 后的第一步 - 更稳妥：不缓存
vendor/，改缓存 Composer 全局 cache（~/.composer/cache），它不依赖项目路径，且composer install --no-dev --optimize-autoloader本身已足够快
注意：composer clear-cache 在 CI 中必须由同用户执行，否则会因 cache-dir 属主不对而静默失败。
不要 bind mount vendor 目录本身
有人想“加速”，直接 -v $(pwd)/vendor:/app/vendor，这是高危操作：
- 容器内生成的
autoload.php会硬编码__DIR__为/app/vendor，但宿主机上该路径可能指向完全不同结构 - Windows/macOS 上 symlink 行为不一致，
vendor/bin/phpunit可能变成死链 - PHP 版本或扩展差异会让
vendor/里的二进制（如php-cs-fixer）直接崩溃
真正该缓存的只有 composer.json 和 composer.lock，然后在 RUN 阶段跑 composer install --no-dev --optimize-autoloader——这才能保证 vendor 完全适配当前镜像环境。
最常被忽略的一点：Docker 构建时若用了 COPY . /app，而宿主机 vendor/ 已存在，它会被一并 COPY 进镜像，且属主是宿主机用户。这个“脏 vendor”会在后续 RUN composer install 时触发 There are uncommitted changes in vendor/ 中止——此时 --discard-changes 是唯一安全出口，而不是删掉再重装。
