webman本身不提供代码编译能力，但因其常驻内存、事件驱动、支持自定义进程及协程等特性，成为构建安全可控在线编译器后端的理想载体；需通过proc_open+setrlimit+低权用户+tmpfs沙箱+seccomp等多重隔离机制，规避exec阻塞、资源耗尽与沙箱逃逸风险。
Webman 本身不提供代码编译能力，但它是构建高性能在线编译器后端的极佳载体——关键不在“能不能编译”，而在于如何安全、隔离、可控地调用外部编译器（如 gcc、php、node），并规避进程阻塞、资源泄漏和沙箱逃逸风险。
为什么不能直接用 exec() 或 shell_exec()
在线编译器最常踩的第一个坑：在控制器里随手写 exec("gcc -o a.out main.c 2>&1")。这看似能跑通，但会立刻触发三重危机：
- 阻塞事件循环：Webman 基于 Workerman 的单线程事件循环，
exec是同步阻塞调用，一个慢编译（比如超时或死循环）会让整个 Worker 进程卡死，所有连接停滞 - 无资源限制：没设置
ulimit，恶意用户提交无限循环的 C 程序，可能耗尽 CPU 或内存，拖垮整台服务器 - 路径与权限失控：临时文件写入
/tmp未清理，或编译产物残留被后续请求读取，造成信息泄露甚至 RCE
必须用异步子进程 + 超时控制
Webman 没有内置进程管理器，但 Workerman 提供了 Process 类，这是唯一安全可行的方案。核心逻辑是：把编译任务丢进独立子进程，主 Worker 继续处理其他请求，靠信号或管道通信。
Webman 2.2.0
下载
Webman 2.2.0版本强化了 TCP/UDP 服务支持，优化路由组管理，并增强异步任务处理能力。结合协程与连接池技术，Webman 能轻松应对高并发场景，适用于网站、接口服务、即时通讯、物联网及游戏开发，兼具高性能、灵活扩展与稳定可靠，是多场景 PHP 服务开发的理想选择。
- 子进程必须显式设置资源上限：
setrlimit(RLIMIT_CPU, 3)（最多运行 3 秒）、setrlimit(RLIMIT_AS, 100 * 1024 * 1024)（内存 ≤100MB） - 禁止使用
system()或反引号，一律用proc_open()配合stream_select()实现非阻塞读取 stdout/stderr - 临时目录必须动态生成且带随机后缀：
/tmp/compile_{$uuid}，子进程退出后立即rrmdir()（递归删除） - 编译命令需白名单过滤：
['gcc', 'g++', 'clang', 'php', 'python3']，禁止传参拼接，参数全部通过数组传入proc_open
如何防止多租户环境下的资源争抢
当多个用户同时提交编译请求，若共用同一组 Worker 进程，CPU 和磁盘 I/O 会成为瓶颈。Webman 支持自定义进程，这里必须拆开：
- 启动一个专用的
CompileWorker进程（在start.php中 new Process），只负责编译，不处理 HTTP 请求 - HTTP 控制器收到请求后，将代码、语言、超时时间序列化为 JSON，通过
Redis::lPush('compile:queue', $payload)投入队列 -
CompileWorker用Redis::brPop('compile:queue', 0)阻塞监听，拿到任务后执行编译，结果写回Redis::set("compile:result:{$id}", $json) - 客户端轮询或 SSE 订阅
compile:result:{$id}，避免长连接堆积
沙箱逃逸比想象中更近
即使加了 setrlimit，C 代码仍可能通过 /dev/mem、ptrace 或 unshare(CLONE_NEWNS) 尝试提权。生产环境必须额外加固：
- 编译子进程必须以低权限用户运行：
posix_setuid(1001)（非 root）、posix_setgid(1001) - 挂载
tmpfs作为工作目录：mount -t tmpfs -o size=512M tmpfs /tmp/compile_*，避免磁盘写满 - 禁用危险系统调用：用
seccomp-bpf（通过libseccomp扩展）过滤openat、socket、clone等 30+ 系统调用 - PHP 编译任务要禁用
disable_functions中的pcntl_fork、dl、shmop_*，否则用户代码可绕过限制
真正难的不是让代码跑起来，而是让成百上千个不受信的用户代码，在同一台机器上互不干扰、不出错、不越界——Webman 提供了高性能底座，但每一道防线都得你亲手焊死。
