SQLBindParameter本身不防SQL注入，仅当配合预编译语句（如WHERE col = ?）并正确调用SQLPrepare时才有效；字符串拼接构造SQL后调用该函数完全无效。
ODBC绑定变量本身不防SQL注入，只有配合预编译语句（SELECT ... WHERE col = ?）才有效；字符串拼接构造SQL后调用SQLBindParameter等于白忙。
必须用问号占位符，否则SQLBindParameter完全失效
很多人以为只要调了SQLBindParameter就安全了，其实不是。它只负责把值“安全传进去”，但前提是SQL语句里得有?——数据库驱动靠这个识别哪些是参数、哪些是代码。
- 错误写法：
"SELECT * FROM users WHERE name = '" + name + "'"，哪怕后面绑了参数，也根本没走参数化流程 - 正确写法：
"SELECT * FROM users WHERE name = ?"，再调SQLPrepare和SQLBindParameter - 常见现象：输入
' OR 1=1 --直接查出全表，说明SQL仍是拼接执行的 - 老驱动（如旧版 SQL Server Native Client）可能不支持
SQLDescribeParam，需 fallback 到服务端预处理，否则SQLPrepare会静默失败
SQLBindParameter参数配错 = 绑定失效
类型、长度、指示器三者不匹配，会导致截断、越界或NULL误判，表面运行正常，实则埋下数据错乱和绕过校验的风险。
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
-
ParameterValuePtr不能指向局部std::string::c_str()——函数执行时内存可能已释放 -
StrLen_or_IndPtr设为SQL_NULL_DATA表示该列为NULL；设为SQL_NTS表示以\0结尾；负值（如-1）会被当成长度，引发越界读 - 字段是
VARCHAR(50)，却传SQL_C_WCHAR并用sizeof(wchar_t)*50算缓冲区长度？实际只绑定了25个汉字，后半截丢弃 - OEM驱动（如老SQL Server）对
SQL_C_CHAR更稳定；Unicode驱动（如 SQL Server ODBC Driver 17+）优先用SQL_C_WCHAR
复用HSTMT和预编译句柄，否则性能崩、兼容性差
每次查询都重新SQLPrepare，不仅慢，还会让某些驱动（如 PostgreSQL ODBC、MySQL Connector/ODBC 旧版）退化成客户端模拟拼接——防注入形同虚设。
立即学习“C++免费学习笔记（深入）”；
- 高频查询场景下，单次
SQLPrepare在 SQL Server 上可能耗时毫秒级，累积开销明显 - MySQL Connector/ODBC 8.0+ 默认启用服务器端预处理，但若配置
UseServerPrepStmt=0，会静默回退到客户端拼接 - 正确做法：把
SQLPrepare提到循环外，同一SQL模板复用同一个HSTMT - 每次执行前必须先调
SQLFreeStmt(hstmt, SQL_UNBIND)，再重新SQLBindParameter，否则旧绑定仍生效
最易被忽略的是：预编译语句是否真在服务器端执行，不能只看代码有没有?和SQLBindParameter。得确认驱动日志、网络抓包或数据库审计日志里出现的是PREPARE + EXECUTE，而不是拼出来的完整SQL。否则，所谓“防御”只是自我安慰。
