Webman数据库连接需显式配置break_reconnect=true防MySQL空闲断连，禁用persistent，Nginx需调大proxy超时，高并发必须用连接池并监控连接数。
Webman 本身是常驻内存的框架，但数据库连接不会自动续命——MySQL 空闲超时（wait_timeout 默认 8 小时）一到，连接就被服务端静默关闭；下次查库时直接抛 PDOException: SQLSTATE[HY000]: General error: 2006 MySQL server has gone away，不是“偶尔断”，而是“必断”，只是时间早晚问题。
Webman 里 break_reconnect 必须显式开启，且只对单次查询生效
Webman 没有默认启用断线重连。哪怕你用的是 think-swoole 或 webman/database，只要底层是 PDO，就必须在数据库配置中写明：
'break_reconnect' => true,
这个开关只在「执行 SQL 报错时」触发重连，不是保活机制。也就是说：
- 第一次查询失败仍会暴露给业务层（需自己
try/catch） - 重连后原 SQL 会重试，但事务上下文已丢失 ——
Db::transaction()内断线，重连后继续执行会报错或数据不一致 - 它不作用于已断开的旧连接对象，只影响当前正在执行的语句
持久连接（persistent）在 Webman 中反而更危险
很多人以为开 'persistent' => true 能省资源，但在 Webman 这种长生命周期进程里，它容易放大问题：
立即学习“PHP免费学习笔记（深入）”；
- 每个 Worker 进程会独占一个底层 socket，空闲时仍卡在 MySQL 的
wait_timeout计时器上 - 一旦被 MySQL 主动踢掉，PDO 不会自动感知，后续查询直接失败（
break_reconnect也救不了，因为连接对象还“活着”） - 连接数容易无声增长，直到打满 MySQL 的
max_connections
真实稳的组合是：关 persistent + 开 break_reconnect + 请求前主动探活。比如在中间件或任务入口加一句：
Db::connection()->query('SELECT 1');
Nginx 反向代理必须调大超时，否则 WebSocket 和长轮询都白搭
Webman 常配合 Nginx 暴露 HTTP/WebSocket 接口。如果只优化了 PHP 层，Nginx 默认 60 秒超时仍会强制切断连接：
-
proxy_read_timeout和proxy_send_timeout必须设为远大于业务预期空闲时间（如86400） - WebSocket 场景还需加
proxy_http_version 1.1和proxy_set_header Upgrade $http_upgrade - 漏配任意一项，客户端看到的就是“连接突然关闭”，日志里找不到 PHP 错误
连接池不是可选项，而是 Webman 高并发下的刚需
Webman 单进程能扛住大量请求，但所有请求复用同一个数据库连接会成瓶颈；全靠 break_reconnect 重试又掩盖了连接泄漏。生产环境应引入轻量连接池，例如：
- 用
webman-pool或自建PdoPool类，在连接归还时执行PING检测 - 连接获取失败时拒绝请求，而不是无限等待或 fallback 到新连接
- 监控
SHOW STATUS LIKE 'Threads_connected'，防止连接数缓慢爬升却不报警
最易忽略的一点：Webman 的定时任务、WebSocket 回调、队列消费者都是独立协程/进程，它们各自持有的数据库连接状态互不影响——断连排查要分场景，不能只看 Web 请求日志。
