Webman部署到Linux服务器流程_Webman生产环境上线配置【指南】

Webman在Linux生产环境能稳定运行，必须同时满足五个硬性条件：PHP 8.0+、pcntl/posix/event真启用（需php --ri验证未被disable_functions屏蔽）、debug关闭、runtime目录权限与systemd用户严格一致、Nginx反代透传Connection/Upgrade头且proxy_pass不带尾部斜杠。 Webman 能不能在 Linux 生产环境跑起来，不取决于你写了多少路由，而取决于五个硬性条件是否全部满足：PHP 8.0+、 / / 真启用、 关闭、 目录权限匹配 systemd 用户、Nginx 配置里没漏掉 和 头。缺一个，服务就可能“启动成功但实际不可用”。 检查 pcntl/posix/event 是否真可用，不是只看 php -m 很多部署失败卡在这一步：执行 看起来都加载了，但 一运行就退出，日志也没报错。 必须验证扩展是否被 屏蔽：运行 ，如果输出里有 行，才算真激活；若只有模块名，大概率是 或 被禁用了 不是可选：Ubuntu/Debian 需额外装 包；CentOS/RHEL 得用 编译，且系统级 库必须已安装（ 可查） 别信宝塔面板 PHP 设置页的“已启用”勾选框——进去手动翻 ，确认 里没写 Nginx proxy_pass 必须透传真实 IP 和 WebSocket 头 只写 是最常见错误配置。它会导致两个后果： 拿到全是 ，所有基于 IP 的限流/风控失效；WebSocket 连接建立后几秒就断开，因为 Upgrade 请求被静默降级。 真实 IP 传递必须加这三行： 、 、 WebSocket 支持必须加这三行： 、 、 后面不能带斜杠： 会把路径前缀吃掉，比如你 route 定义的是 ，实际收到的是 systemd 服务配置必须和 runtime/ 目录归属严格一致 服务能启动、也能 curl 通，但第二天发现日志不写了、session 文件消失、缓存不命中——90% 是因为 systemd 启动进程的用户和 所有者不一致。Linux 权限机制不会报错，只会默默拒绝写入。 Docker Desktop（linux） 当前 Docker 最新稳定版本之一，主要针对稳定性和兼容性进行了修复优化，适合生产环境与日常开发使用。该版本继续强化 AI 开发支持、容器日志管理以及 Docker Engine 的安全能力，对 Windows/macOS/Linux 平台兼容性进行了进一步优化。 下载 Ubuntu/Debian 下，设 ，同时执行： CentOS/RHEL 下，设 ，对应执行： 务必检查 指向项目根目录（如 ），否则 读不到 config 别漏掉 和 ，否则 worker 崩溃后不会自动拉起 启动后必须三步验证，不能只看命令返回 success 执行完就关终端？这是最危险的操作。Webman 启动是异步 fork 多进程，主进程退出不代表 worker 起来了。 查进程： ，应看到至少两个进程： （master）和若干 子进程 查端口： （或你自定义的端口），确认监听地址是 而非 （后者 Nginx 无法反代） 查日志： ，重点看有没有 或 字样；如果 log 目录为空，先检查 权限 最容易被忽略的点是 和 尾部斜杠——它们不报错，但让整个服务处于“半瘫痪”状态。上线前拿一台测试机，按这四步走一遍，比上线后再救火快十倍。