mysqli_ping()是检测mysql连接是否存活的最轻量方法，成功返回true，失败返回false，需在业务sql前调用以确保连接有效。
直接检测连接是否“还活着”，不能只看 mysqli_connect() 是否返回资源，因为连接可能在建立后被 MySQL 主动断开（比如超时、网络抖动、服务重启）。真正有效的检测，得在执行业务 SQL 前做一次轻量级验证。
用 mysqli_ping() 判断连接是否断开
mysqli_ping() 是最贴近原生语义的检测方式：它向 MySQL 发送一个 PING 包，不执行任何业务逻辑，也不影响事务状态。成功返回 true，失败返回 false（此时连接已失效）。
- 必须传入有效的
mysqli资源句柄，否则会警告 - 不能在事务中调用——MySQL 严格模式下会隐式提交，破坏事务一致性
- 如果返回
false，应立即重连，而不是继续用旧句柄
示例：
$conn = mysqli_connect("127.0.0.1", "root", "123456", "test");
if (!$conn || !mysqli_ping($conn)) {
// 连接失败或已断开
die("Connection lost or invalid: " . mysqli_error($conn));
}
// 后续可安全执行查询
用 is_resource() 只能判断“是否是资源”，不能判断“是否有效”
is_resource() 检查的是变量类型，不是连接状态。只要 mysqli_connect() 曾成功返回过资源，哪怕 MySQL 已经断开、连接句柄已不可用，is_resource($conn) 依然返回 true。
- 常见误用：把
is_resource($conn) && $conn !== false当作连接有效性判断，这是错的 - 它适合用在“刚创建完连接后，确认没出语法/参数错误”，但不适合运行时保活检测
- PHP 8+ 中部分扩展（如 ext/hash）已改用对象，
is_resource()对它们永远返回false，需注意兼容性
捕获 SQLSTATE[HY000] [2006] 错误作为兜底手段
很多框架（如 ThinkPHP）并不主动 ping，而是等第一次查询失败后才反应。典型错误是：SQLSTATE[HY000] [2006] MySQL server has gone away。这说明连接在上次使用后被服务端关闭了（受 wait_timeout 控制，默认 8 小时）。
- 这个错误无法靠前置检测 100% 避免——PING 成功后、执行 SQL 前仍可能断连
- 建议在数据库操作外层加
try/catch，捕获PDOException或mysqli_sql_exception，检查getCode()是否为2006或2013 - 捕获到后，应调用
mysqli_close($conn)+ 重新mysqli_connect()，而非复用旧句柄
ThinkPHP 等框架里别依赖 max_idle_time 自动清理
ThinkPHP 的 max_idle_time 不是后台定时器，它只在下次获取连接时对比“上次使用时间”，而且仅在 deploy=1 且启用持久连接时才部分生效。实际项目中它基本不触发。
- Swoole/CLI 长生命周期场景下，
max_idle_time完全失效——连接对象存在几小时，MySQL 早把连接干掉了 - 真正可靠的做法是在每次请求入口（如 Swoole 的
onRequest）或 Db 查询前，显式调用$connection->ping() - 注意：ThinkPHP 5.1 不支持配置项
ping=>true，得手动重写initConnect()或监听Db::listen()回调
连接有效性不是“连上了就完事”，而是一个持续验证的过程。PING 是最轻量的探针，错误捕获是最后防线，两者配合才能覆盖绝大多数断连场景。别省那一次往返开销，否则线上查半天 gone away 却找不到源头。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
