Windows不支持swoole_process因无fork()；Mac需调ulimit和max_conn防静默退出；Alpine定时器不准因musl精度低；WSL2需端口转发或升级Swoole 4.8+。
Windows 下 swoole_process 直接报错：不支持
Windows 原生不支持 fork()，而 swoole_process 依赖它，所以只要代码里用了这个类，Windows 上运行会直接抛出 Class 'Swoole\Process' not found 或更底层的 Unsupported OS 错误。
实际场景里，很多人在本地 Windows 开发时顺手写了进程管理逻辑，一上 Linux 测试就崩——不是代码写错了，是根本没加载成功。
- 开发阶段就得规避：用
extension_loaded('swoole')+class_exists('Swoole\Process')双重判断，不能只靠扩展存在就认为能用 - 替代方案优先选
Swoole\Coroutine\Channel+ 协程任务分发，跨平台无感；真需要子进程，改用proc_open()包装外部脚本（但失去 Swoole 进程通信能力） - CI/CD 中若混用 Windows 构建机，记得在
php.ini里禁用 swoole 扩展，避免加载失败导致整个 PHP 启动异常
Mac 上 swoole_server->start() 启动后立刻退出
macOS 默认的 ulimit -n 通常只有 256，而 swoole_server 启动时默认尝试打开 1024 个文件描述符。资源不足会导致启动成功返回 true，但几毫秒内就静默退出，strace 或日志里几乎看不到痕迹。
这不是 Bug，是系统限制和 Swoole 默认配置的冲突，尤其在 M1/M2 芯片 Mac 上更容易复现。
- 启动前先执行
ulimit -n 65535（加到 shell 配置或启动脚本里） - 代码中显式设置
$server->set(['max_conn' => 1024])，避免它按 CPU 核数推算过高值 - 监听地址别用
0.0.0.0，Mac 的网络栈对 IPv6 回环有时有延迟响应，改成127.0.0.1更稳
swoole_timer_tick() 在 Docker Alpine 镜像里不准
Alpine 使用 musl libc，其 clock_gettime(CLOCK_MONOTONIC) 实现精度不如 glibc，加上容器内核时间虚拟化抖动，swoole_timer_tick() 容易出现 2–3 倍延迟，比如设 100ms，实际回调间隔变成 200ms+，且波动极大。
这问题在监控、心跳、限频等对时间敏感的逻辑里特别致命，但错误现象只是“定时器变慢”，很难联想到底层 libc。
- 生产环境别用 Alpine 做 Swoole 定时器核心服务，换 Debian/Ubuntu 基础镜像
- 如果必须用 Alpine，把定时周期拉长到 500ms 以上，避开 musl 的低精度临界点
- 别依赖
swoole_timer_tick()做精确延时，该用swoole_timer_after()就用，后者基于事件循环而非系统时钟
swoole_http_server 在 WSL2 中无法被宿主 Windows 访问
WSL2 是轻量虚拟机，有自己的 IP（如 172.x.x.x），不是桥接在 Windows 网络栈上。所以即使 swoole_http_server 绑定 0.0.0.0:9501，Windows 浏览器也连不上，提示连接被拒绝。
这不是防火墙问题，也不是端口占用，是网络拓扑本身隔开了。
- 手动在 Windows 上添加端口转发：
netsh interface portproxy add v4tov4 listenport=9501 listenaddress=127.0.0.1 connectport=9501 connectaddress=<wsl-ip> - 或者改用
localhost启动（Swoole 4.8+ 支持自动识别 WSL 环境并绑定正确接口） - 检查 WSL2 的
/etc/resolv.conf是否被覆盖，DNS 失败会导致 Swoole 内部某些初始化卡住，间接影响监听行为
ulimit、一行 netsh、甚至 libc 的一个函数实现，都可能让同一段代码在三台机器上表现完全不同。 
