ODBC防注入关键在于正确使用SQLPrepare+?占位符，而非驱动自动过滤；必须避免字符串拼接、复用语句句柄、严格校验SQLBindParameter参数及内存有效性。
ODBC 本身不提供防注入能力，所谓“安全驱动库”只是帮你正确使用 SQLPrepare + SQLBindParameter 的封装层；真正起作用的是你是否用 ? 占位符、是否避免字符串拼接、是否复用语句句柄。
必须用 SQLPrepare + ? 占位符，否则所有绑定都白搭
这是最常被忽略的前提：防注入不是靠驱动“自动过滤”，而是靠数据库服务端预编译 SQL 模板。如果写的是 "SELECT * FROM users WHERE name = '" + name + "'"，哪怕后面调了 SQLBindParameter，参数根本没进绑定流程——因为语句里根本没有 ?。
- 正确写法：
"SELECT * FROM users WHERE name = ? AND age > ?"，之后再调SQLPrepare和多次SQLBindParameter - 错误写法：
"SELECT * FROM users WHERE name = '" + name + "'"，此时SQLBindParameter对name完全无效 - 验证方法：执行前用
SQLDescribeParam检查占位符数量；若返回SQL_ERROR或参数数为 0，说明驱动没识别到?（常见于老版驱动或拼接后传入）
SQLBindParameter 参数配错 = 绑定失效，且不易察觉
类型、长度、指示器三者不匹配时，SQLBindParameter 可能静默失败或只绑定部分数据，导致查询逻辑异常，甚至掩盖注入漏洞。
-
ParameterValuePtr必须指向**全程有效**的内存：不能是局部std::string的c_str()，出作用域后指针悬空 -
StrLen_or_IndPtr若指向SQLLEN变量，值为SQL_NULL_DATA表示 NULL，SQL_NTS表示以\0结尾，负值（如-1）会被某些驱动误判 - 字段是
VARCHAR(50)，却传SQL_C_WCHAR+sizeof(wchar_t) * 50当缓冲区长度？结果只绑了前 25 个中文字符 - OEM 驱动（如旧版 SQL Server Native Client）对
SQL_C_CHAR更稳定；Unicode 驱动优先用SQL_C_WCHAR，但需确保宽字符字符串以L'\0'结尾
语句句柄复用不当会退化成客户端模拟拼接
高频查询下每次重新 SQLPrepare 不仅慢，还会让部分 ODBC 驱动（如 PostgreSQL ODBC、MySQL Connector/ODBC 旧版本）跳过服务端预处理，转而由驱动在客户端做字符串替换——等于把防注入机制整个绕开。
- 同一 SQL 模板（如
"INSERT INTO log(msg, ts) VALUES (?, ?)"）应复用一个HSTMT，而不是每次分配新句柄 - 每次执行前必须先调
SQLFreeStmt(hstmt, SQL_UNBIND)解绑旧参数，再调SQLBindParameter绑新值 - MySQL ODBC 8.0+ 默认启用服务端预处理，但若连接字符串含
UseServerPrepStmt=0或驱动不支持，会静默回退，建议连接后检查mysql_stmt_attr_get（MySQL）或日志
真正难的不是调用哪个函数，而是让整个调用链不出现“拼接→准备→绑定→执行”的断点。比如从 HTTP 请求解析出用户名，中间经过任何一次 std::string::append、sprintf 或 std::format 插入到 SQL 字符串里，就前功尽弃。防注入的边界不在驱动层，而在你构造 SQL 字符串的那一行代码。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
