webman 原生 crontab 不适合可视化调度，因其无后台管理、任务需重启生效、不支持运行时操作与分布式锁；毫秒级任务须用 timer::tick()；监控需自建 prometheus+grafana；告警必须异步解耦。
Webman 原生 Crontab 不适合可视化调度
Webman 没有内置任务管理后台，其 workerman/crontab 是进程内定时器，任务写死在 PHP 类里（如 app/process/Task.php），改一次就得 php start.php reload ——restart 会中断所有任务。它不支持运行时增删改查、无状态监控、无失败重试、无分布式锁。Crontab 表达式是 6 位（秒 分 时 日 月 周），写成 * * * * * 实际被解析为「每小时执行一次」，极易踩坑。
毫秒级任务必须用协程 Timer，别碰 Crontab 组件
想做 500ms 级别的轮询或采样？workerman/crontab 根本不支持毫秒粒度，底层以秒对齐，精度上限约 100ms。正确路径是：在独立 Worker 进程中启用 Swoole 或 Swow 驱动，然后直接调用 Workerman\Coroutine\Timer::tick()。
- 确认已装
Swoole（v5.0+）或Swow（v1.4+），并在config/process.php中显式指定eventLoop为Workerman\Events\Swoole::class或Workerman\Events\Swow::class - 禁用
Fiber驱动——它在高并发下调度漂移严重 -
Timer::tick(500, fn() => {...})可稳定触发；Timer::add()在协程环境下可能降级为低精度，慎用 - 回调内禁止同步 I/O（如
file_get_contents、sleep），必须加try-catch防止单次异常阻塞整个 tick 循环
生产环境监控不能靠 monitor 进程
app/process/Monitor.php 只做两件事：每秒扫文件修改时间、每分钟读 /proc/[pid]/status 查内存，结果全打到 runtime/log/monitor.log，不暴露 HTTP 接口，也不提供 UI。你以为访问 :5555 看到的是 Webman 监控页？其实是 Workerman 的原生状态页（需手动开启且仅限开发），它不包含 SQL 耗时、中间件耗时、Trace 链路等应用层指标。
Webman 2.2.0版本强化了 TCP/UDP 服务支持，优化路由组管理，并增强异步任务处理能力。结合协程与连接池技术，Webman 能轻松应对高并发场景，适用于网站、接口服务、即时通讯、物联网及游戏开发，兼具高性能、灵活扩展与稳定可靠，是多场景 PHP 服务开发的理想选择。
- 真要实时看 P95 耗时或错误率，得自己搭
Prometheus + Grafana，用几行代码写个 Exporter 暴露/metrics -
CollectorRegistry必须全局单例，放在app/Bootstrap.php初始化；每个 Worker 进程 new 一个会导致指标错乱 -
$gauge->observe($duration)传null或非法标签（含空格、斜杠）会直接让/metrics返回 500，上线前务必用curl -v验证响应头是否为Content-Type: text/plain; version=0.0.4
告警和异步任务必须解耦出主流程
Zabbix、钉钉、邮件这类通知逻辑绝不能在请求中同步执行——curl 或 mail() 会卡住主线程，拖慢所有接口。正确做法是把告警 payload 写入 Redis 队列，另起一个专用 Worker 进程消费。
- Zabbix Webhook 回调里只做校验（比如检查
X-Zabbix-Signature）和redis.lpush('alert:queue', $payload) - 告警消费者进程用
while(true) { $payload = $redis->rpop('alert:queue'); ... }模式，失败可重试，不影响主业务 - 不要在
onWorkerStart里启动多个长周期协程任务——它们共享事件循环，一个卡住，全部延迟
Webman 的调度与监控本质是“去中心化”的：原生能力只管基础存活，所有可视化、精准调度、可靠告警都得靠外置服务兜底。最容易被忽略的点是——CollectorRegistry 单例、Timer::tick 替代 Crontab、以及告警逻辑彻底异步化，这三处一旦漏掉，轻则指标失真，重则服务雪崩。
