webman本质是workerman的应用层封装，其“奇怪行为”源于常驻内存、多进程与事件驱动三重特性：onworkerstart初始化数据库连接会导致子进程继承同一句柄而引发mysql报错；路由404常因中间件顺序错误或未放行options预检请求；定时任务不准时系因单进程串行执行所致；热更新需区分reload（业务代码）与restart（进程文件）。
Webman 不是 Laravel 或 ThinkPHP 的平替，照搬 FPM 习惯会直接崩在启动阶段——它本质是 Workerman 的应用层封装，所有“奇怪行为”都源于常驻内存 + 多进程 + 事件驱动这三重特性。
onWorkerStart 里初始化数据库连接？别碰
这是新手最常翻车的位置。Workman 在 onWorkerStart 中 fork 出多个子进程，而你在该回调里执行 new PDO() 或 Db::connect()，会导致同一个连接句柄被所有子进程继承。结果就是 MySQL 报错 MySQL server has gone away，或者连接数暴涨超出配置上限。
- 正确做法：数据库连接必须放在请求生命周期内初始化，比如控制器方法、中间件或自定义服务的构造函数中
- 若要用连接池（如
webman/database），确保max_connections配置 ≥worker_num，否则高并发时连接直接耗尽 - 检查
config/database.php中是否误设了'persistent' => true—— Webman 场景下持久连接毫无意义，反而加剧复用冲突
路由 404？先看中间件顺序和 OPTIONS 请求
Webman 路由是严格前缀匹配，且中间件执行顺序直接影响请求能否抵达路由层。常见现象是 GET /api/user 返回 404，但 curl -v 显示实际发出了 OPTIONS 预检请求。
Webman 2.2.0版本强化了 TCP/UDP 服务支持，优化路由组管理，并增强异步任务处理能力。结合协程与连接池技术，Webman 能轻松应对高并发场景，适用于网站、接口服务、即时通讯、物联网及游戏开发，兼具高性能、灵活扩展与稳定可靠，是多场景 PHP 服务开发的理想选择。
- 问题根源：鉴权类中间件（如
AuthMiddleware）放在了路由分组外，且未对OPTIONS方法放行 - 修复方式：把 CORS 相关中间件（如
CorsMiddleware）提前到鉴权之前，或在鉴权中间件中显式允许OPTIONS - 注意
route.php中写法：必须用数组形式传入中间件，->middleware([CorsMiddleware::class])，不能写成字符串->middleware('cors') - 静态资源（如
/static/xxx.js）也受同一路由规则约束，建议直接交给 Nginx 托管，别让 Webman 处理
定时任务不准时？不是 Crontab 有问题，是进程卡住了
Webman 的 workerman/crontab 组件在单个进程内串行执行任务。一个耗时 8 秒的任务，足以让后面所有秒级任务全部延迟甚至跳过周期。
- 典型错误：把报表生成、健康检查、日志清理全塞进同一个
process/Task.php的onWorkerStart - 正确拆分：高频/低延迟任务（如心跳检测）单独起一个进程；耗时任务（如导出 Excel）独立进程 + 设置超时：
set_time_limit(30) - 务必用
php start.php reload更新定时任务代码，restart会导致 Crontab 实例未重新注册而“静默失效” - Cron 表达式必须带秒位：写成
'* * * * *'是每小时执行一次，正确格式是'* * * * * *'（6 位）
热更新不生效？reload 和 restart 的区别很关键
Webman 常驻内存，代码加载后以 opcode 形式驻留。改完控制器或路由后，只执行 php start.php restart 是无效的——它会杀死旧进程再拉起新进程，但部分全局状态（如已注册的 Crontab、自定义进程）可能未被重建。
- 业务代码变更（如控制器、中间件、路由）：用
php start.php reload - 进程文件变更（如
process/Task.php）、新增 Composer 包、修改start.php：必须用php start.php restart - 开发阶段可启用
monitor进程自动 reload，但仅限调试模式（不加-d启动）；Windows 用户需运行windows.bat才能触发 -
opcache.enable_cli=0必须在 php.ini 中显式关闭，否则 CLI 模式下 OPcache 可能缓存旧代码，导致 reload 失效
真正难处理的从来不是语法或配置，而是那些“看起来正常却偶尔出错”的问题——比如某个中间件在 99% 请求里没问题，但在并发压测时突然阻塞整个事件循环。这种问题必须回到 Workerman 的多进程模型和事件循环机制去定位，而不是盯着 Webman 封装层打转。
