Workerman需自建HTTP健康端点（如/ready）以支持Kubernetes探针，因默认无内置健康接口；readinessProbe比livenessProbe更关键，须设initialDelaySeconds≥10s并配合startupProbe防启动超时。
Workerman 是常驻内存、多进程、无主循环的 PHP 服务，它不依赖 HTTP Server（如 Nginx/FPM），也不走传统 Web 生命周期。直接套用通用探针配置（比如对 /healthz 发 HTTP GET）大概率会失败或误判——因为默认没暴露这个端点，也**不会自动响应健康请求**。
Workerman 没有内置 HTTP 健康端点，得自己加
默认启动的 Workerman 进程只监听业务端口（如 tcp://0.0.0.0:2345 或 websocket://0.0.0.0:8080），不提供 /healthz、/ready 这类 HTTP 接口。Kubernetes 的 httpGet 探针若直接指向业务端口，要么连接被拒绝（端口不是 HTTP），要么返回非 2xx 状态码（比如 WebSocket 握手失败）。
- 必须在
start.php或独立 worker 中显式启动一个轻量 HTTP server（例如用Workerman\Protocols\Http）来响应探针 - 推荐复用同一 EventLoop，避免额外进程；不要用
exec('curl ...')或 fork 子进程做检查，会干扰主循环 - HTTP handler 应只检查核心状态：Redis 连接是否活跃、主 worker 进程是否存活、关键定时器是否注册
就绪探针（Readiness）比存活探针（Liveness）更关键
Workerman 启动后可能已监听端口，但尚未完成初始化（如加载配置、连接 Redis、预热缓存）。此时流量进来会导致 connection reset 或超时。而 Liveness 对它意义有限——进程卡死极少发生，且 Workerman 自带子进程守护机制，kill 主进程通常会触发重启逻辑。
-
readinessProbe必须设置initialDelaySeconds（建议 ≥10s），给onWorkerStart回调留出执行时间 -
periodSeconds建议设为 5–10s，太长会导致故障实例持续接收流量 - 避免用
tcpSocket检查业务端口作为就绪依据——端口通 ≠ 服务就绪
StartupProbe 能防止滚动更新时“假失败”
Workerman 初始化阶段（尤其加载大配置、建立多个 Redis 连接、预热协程池）可能耗时 10–30 秒。若没配 startupProbe，livenessProbe 或 readinessProbe 在 initialDelaySeconds 后立刻开始探测，极易因超时失败，导致 Pod 被反复重启或跳过就绪，引发部署中断。
- 启用
startupProbe，failureThreshold × periodSeconds应覆盖最大预期启动耗时（例如failureThreshold: 6,periodSeconds: 5→ 最多容许 30 秒启动） - 它的检查方式可和
readinessProbe一致（比如同一个/readyHTTP 端点），只是作用窗口不同 - 一旦
startupProbe成功，liveness和readiness才正式接管
onMessage 或定时器里埋点，再由 HTTP handler 汇总返回，而不是依赖外部命令或端口连通性。 
