MySQL C++ Connector中判断NULL必须先调用isNull()等显式检查方法：mysqlx::Row用isNull(i)，mysqlpp::Row用is_null()，原生C API需检查row[i]==nullptr；不可依赖默认值或类型转换，否则丢失SQL语义。
MySQL C++ Connector 查询结果中 NULL 的判断方式
MySQL 官方 C++ Connector（mysqlx）和传统 C API 封装（如 mysqlpp 或原生 libmysqlclient + MYSQL_BIND）对 NULL 的处理逻辑完全不同，不能混用判断方法。最常见错误是直接对字段值解引用或调用 .toString() 而不先检查是否为 NULL，导致段错误或未定义行为。
以官方 mysqlx 为例，查询返回的 Row 中每个字段需用 isNull() 显式判断：
auto row = result.fetchOne();
if (!row.isNull(0)) {
std::string val = row[0].get<std::string>();
} else {
// 处理 NULL
}
mysqlpp::Row 中 operator[] 返回值的空安全访问
mysqlpp::Row 的 operator[] 返回的是 mysqlpp::Value，它内部已封装了 is_null() 状态，但不会自动转换为 C++ std::optional 或抛异常。直接取值前必须检查。
-
row[0].is_null()是唯一可靠的NULL判断方式；row[0].c_str() == nullptr不成立，因为c_str()对NULL字段会返回空字符串指针而非nullptr - 类型转换函数如
as_int()、as_string()在字段为NULL时返回默认值（如0、空字符串），不报错也不提示，极易掩盖逻辑缺陷 - 若需强约束，建议封装一层：用
std::optional<int>包装as_int()结果，并在is_null()为真时返回std::nullopt
使用原生 libmysqlclient 时 mysql_fetch_row() 的 NULL 检测陷阱
原生 C API 中，mysql_fetch_row() 返回的 MYSQL_ROW 是 char **，其中任意元素可能为 nullptr —— 这才是真正的 NULL 标识。但新手常误以为只要字段长度非零就一定有值，忽略了 lengths 数组与 row 的对应关系。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
立即学习“C++免费学习笔记（深入）”；
- 必须同时检查
row[i] == nullptr和lengths[i] == 0：前者表示NULL，后者仅表示空字符串（非NULL） - 调用
mysql_fetch_lengths()获取lengths前，必须确保已调用过mysql_store_result()或mysql_use_result() - 如果用了
mysql_stmt_bind_result()，则需通过is_null参数（my_bool *类型）接收NULL标志，不能只依赖绑定的缓冲区内容
为什么不能依赖 std::string 或数值类型的默认构造来识别 NULL
NULL 是 SQL 层语义，不是 C++ 层的空值。把数据库 NULL 映射成 std::string{} 或 int{0} 会丢失语义区分能力，尤其在涉及聚合、条件更新或 ORM 映射时，会导致业务逻辑错误。
- 例如：用户注册时间字段为
NULL（未设置）和'0000-00-00'（非法时间）在 MySQL 中含义不同，但都可能被转成空std::string - 数值字段若映射为
double，NULL和0.0在内存中无法区分，除非额外维护一个布尔标志位 - 现代做法是统一用
std::optional<T>表达可空性，但所有 MySQL 绑定层都不原生支持，必须手动桥接
真正麻烦的不是怎么读出 NULL，而是后续所有业务代码是否一致遵循“先判空再取值”的链路。漏掉一次，就可能让 NULL 流入计算、拼接或序列化环节，问题延后暴露，调试成本陡增。
