Hyperf启动报Permission denied需先查错误日志定位被拒路径，90%为runtime/、storage/或vendor/bin/hyperf.php；再用ps aux | grep swoole确认Swoole进程用户，接着ls -ld检查目录属主，若不匹配则chown -R对应用户，并chmod +x vendor/bin/hyperf.php。
Hyperf 启动报 Permission denied 怎么快速定位
直接看错误日志里写的是哪个路径被拒绝访问，90% 是 runtime/、storage/ 或 vendor/bin/hyperf.php。别急着改整个项目权限，先确认 Swoole 进程实际用的用户是谁：ps aux | grep hyperf 或 ps aux | grep swoole，通常不是 root，而是 www-data、nginx 或镜像里预设的低权限用户。
接着检查对应目录归属：ls -ld runtime storage vendor/bin/hyperf.php。如果属主是 root 或构建时的开发用户，Swoole 就写不进去。
- 若属主不匹配，执行
chown -R www-data:www-data runtime storage（按实际用户名调整） -
vendor/bin/hyperf.php必须有执行权限：chmod +x vendor/bin/hyperf.php - 不要只改目录权限（如
chmod 777），优先调属主；755 对目录、644 对文件足够，过度开放反而触发安全机制拦截
Docker 构建时 vendor 权限错乱怎么预防
问题根源几乎都来自在容器内或宿主机上用 root 执行了 composer install。生成的 vendor/ 下部分可执行脚本（比如 bin 文件）属主为 root，非 root 用户的 Swoole 进程就无法加载或执行。
推荐做法是：宿主机用普通用户运行 composer install --no-dev --optimize-autoloader，再 COPY 进镜像；或者在 Dockerfile 多阶段构建中，显式切换用户执行：
- 第一阶段用完整 PHP 镜像，但加
RUN sudo -u www-data composer install --no-dev -o - 第二阶段 COPY 时，确保
COPY --from=builder /app /app不带 root 权限残留 - 构建后验证：
docker run --rm -it your-image ls -l vendor/bin/ | head -3，确认属主是目标运行用户
docker-compose 挂载代码时 runtime 目录总变只读
这是 bind mount 的典型副作用：宿主机目录挂进容器后，继承宿主机的权限和 UID/GID 映射。如果宿主机 runtime/ 属主是 root，容器里即使以 www-data 启动，也写不了——尤其在 macOS 或 Windows + WSL2 环境下更常见。
解决思路不是硬改宿主机权限，而是绕过挂载冲突：
- 开发时只挂载源码，不挂载
runtime和storage：volumes: ["./app:/app/app", "./config:/app/config:ro"] - 让容器自己初始化 runtime 目录：在
ENTRYPOINT或启动脚本里加mkdir -p runtime storage && chown -R www-data:www-data runtime storage - 生产环境彻底禁用 bind mount，改用
COPY构建，仅挂载日志或上传目录（如/app/storage/upload）
Alpine 镜像里 Swoole 扩展没启用导致启动失败
错误信息通常是 Swoole extension not loaded 或 Class swoole_http_server not found。Alpine 镜像默认不带 Swoole，必须手动编译安装，且容易漏掉启用步骤。
关键检查点：
- 确认
pecl install swoole后是否执行了docker-php-ext-enable swoole - 验证扩展是否真在 PHP 配置里：
docker run --rm your-image php -m | grep swoole - 注意 Alpine 的 Swoole 版本要求：Hyperf ≥ 3.0 需
swoole >= 5.1.0，而pecl install swoole默认可能装旧版，应指定：pecl install swoole-5.1.0 - 避免在
php.ini里手动加extension=swoole.so—— Alpine 的docker-php-ext-enable会自动处理路径，手写容易错位
权限问题从来不是框架缺陷，而是用户、进程、文件三者 UID/GID 对不齐的信号。最易被忽略的是：容器内用户 UID 和宿主机挂载目录 UID 不一致时，chown 在宿主机执行根本无效——得在容器启动前用 init 容器或 entrypoint 脚本重设。
