根本原因是PHP-FPM容器中用户UID与vendor目录属主UID不匹配，导致权限拒绝；正确做法是在构建阶段用非root用户预装依赖并多阶段复制，禁止在运行时容器内执行composer install。
别在PHP-FPM容器里跑composer install，这是权限问题的根源，不是修复能解决的。
为什么PHP-FPM容器里执行Composer必出权限问题
PHP-FPM进程默认以非root用户（如www-data）运行，而composer install需要写vendor/、composer.lock、缓存目录等——这些路径若由root创建（比如用sudo docker run或构建时未切换用户），FPM用户根本无权覆盖或追加文件。报错如file_put_contents(.../autoload.php): Permission denied，本质是UID不匹配，不是chmod没调够。
- 容器内UID 0（root）写的
vendor/，FPM以UID 1001运行 → 拒绝访问 - 宿主机挂载的
vendor/属UID 1000，容器内FPM用UID 82（www-data）→ 权限失效 -
sudo composer install在容器内执行一次，整个vendor/就变成root所有，后续所有FPM请求都可能因autoload.php不可读而500
正确做法：构建阶段预装 + 多阶段剥离
所有依赖必须在Docker构建时完成，且严格控制用户与权限边界：
OpenClaw Docker Setup
下载
在 Linux 上通过 Docker 运行 OpenClaw，并使用 Tailscale 实现远程访问。⚠️ 涉及 sudo、Docker、Tailscale和凭证挂载——请先查阅安全章节...
- 第一阶段用
php:8.3-cli-alpine执行：composer install --no-dev --prefer-dist -o -a - 第二阶段用
php:8.3-fpm-alpine，只COPY --from=0 /app/vendor /var/www/html/vendor - 第二阶段必须加
USER www-data，并验证：ls -l /var/www/html/vendor/autoload.php输出属主为www-data或至少属组可读（-rw-r--r-- 1 root www-data+g+r） - 禁止把
/usr/bin/composer或vendor/bin/phpunit带入生产镜像——它们会污染OPcache、触发安全扫描告警
如果已经污染了vendor/，怎么救
别试图chown -R www-data:www-data vendor/在运行中容器里修——FPM worker可能正加载类，强制改属主易导致OPcache不一致或500。优先走重建流程：
立即学习“PHP免费学习笔记（深入）”；
- 删掉本地
vendor/和composer.lock，确保Dockerfile里没有RUN sudo composer之类命令 - 构建时显式指定用户：
RUN set -eux; useradd -u 82 -m www-data; chown -R www-data:www-data /app，再切用户执行install - 若必须现场修复（如调试环境），进容器后执行：
chown -R www-data:www-data /var/www/html/vendor && chmod -R g+rX /var/www/html/vendor && chmod 644 /var/www/html/vendor/autoload.php - 验证是否生效：
su -c 'php -r "require \"/var/www/html/vendor/autoload.php\";"' -s /bin/sh www-data，不报错才算真正可读
Docker部署时最容易被忽略的点
权限问题常在看似“跑通了”的时候埋雷：
-
docker run -v $(pwd)/vendor:/var/www/html/vendor挂载时，宿主机vendor/属主必须和容器内FPM UID一致，否则ls -l看到的是drwxr-xr-x 1 1000 1000，但容器里id -u www-data返回82 → 读不了 -
COMPOSER_HOME被设成/root/.composer（常见于sudo docker build），导致全局缓存路径归属错误，影响composer global require类命令 - Alpine镜像里
www-dataUID默认是82，Debian系是33，跨基础镜像复制vendor/前没统一UID，就会静默失败
