mysql c api预处理语句必须先调用mysql_stmt_init()初始化句柄，再prepare、bind、execute；未初始化或复用已关闭句柄会导致崩溃或“commands out of sync”错误，且参数绑定、结果绑定、资源释放等均需严格遵循生命周期与类型契约。
MySQL C API预处理语句必须先调用 mysql_stmt_init()
直接传入 SQL 字符串给 mysql_stmt_prepare() 会崩溃或返回 NULL——因为没初始化语句句柄。正确流程是：先用 mysql_stmt_init() 创建句柄，再准备，再绑定参数，最后执行。
常见错误现象：mysql_stmt_prepare() 返回非零值，mysql_stmt_error() 报 “Commands out of sync” 或空字符串；本质是句柄非法或复用已关闭句柄。
-
mysql_stmt_init()返回NULL表示内存分配失败（极少见），需检查mysql连接是否有效 - 每个预处理语句应独占一个
MYSQL_STMT*句柄，不能多个线程共用同一句柄 - 若连接断开后未重连，继续用旧句柄调用任何
mysql_stmt_*函数都会导致未定义行为
参数绑定必须严格匹配类型和数量，mysql_stmt_bind_param() 不校验 SQL 中 ? 个数
SQL 里有 3 个 ?，但只绑了 2 个参数？程序不会报错，而是执行时出错或读取垃圾内存——mysql_stmt_bind_param() 只按你传的 bind 数组长度操作，不反查 SQL。
典型陷阱：C++ 中用 std::string 绑定 VARCHAR 字段，忘记设置 buffer_length 和 is_null 字段，导致截断或乱码。
- 对字符串类型，
buffer指向c_str()、buffer_length设为str.length()、is_null指向bool变量（即使非 NULL 也要设为false） - 对整数类型（如
INT），buffer指向int变量地址，buffer_length必须为 0（否则被当作文本长度处理） - 每次执行前，若参数值改变，必须重新调用
mysql_stmt_bind_param()；仅修改变量值不生效
查询结果需用 mysql_stmt_bind_result()，且字段顺序/类型必须与 SELECT 列严格一致
SELECT 语句返回 4 列，但只绑了 3 个变量？第 4 列数据会被丢弃，后续调用 mysql_stmt_fetch() 可能触发越界读。C API 不做元数据比对，全靠开发者手动保证。
容易忽略的细节：MySQL 的 TINYINT(1) 默认映射为布尔，在 C++ 中应绑定为 char 类型（而非 bool），否则 mysql_stmt_fetch() 可能写入越界字节。
- 调用
mysql_stmt_bind_result()前，必须先执行mysql_stmt_execute()并确认成功 - 对可空字段，
is_null数组必须单独分配并传入，否则无法判断某列为 NULL - 字符串结果的
length字段（在MYSQL_BIND中）必须有效，否则mysql_stmt_fetch()不会填充实际长度
资源释放顺序不能颠倒：mysql_stmt_close() 必须在 mysql_close() 之前
先关连接再关语句句柄，会导致 mysql_stmt_close() 内部访问已释放内存，轻则 crash，重则静默损坏堆。MySQL C API 文档明确要求：所有语句句柄必须在连接关闭前销毁。
更隐蔽的问题：若使用连接池，每次归还连接前漏掉 mysql_stmt_close()，该连接下次复用时会残留无效句柄，引发 “Commands out of sync” 错误。
- 每个
mysql_stmt_init()对应一次mysql_stmt_close()，哪怕mysql_stmt_prepare()失败也应关闭句柄 - 不要在异常路径中遗漏
mysql_stmt_close()，C++ 中建议用 RAII 封装（如std::unique_ptr+ 自定义 deleter） -
mysql_stmt_reset()仅重置语句状态，不释放资源；真正释放必须用mysql_stmt_close()
is_null 字段、晚关一句柄、多绑一个参数，都可能让程序在某个边缘场景下突然失效。大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
