优先使用数据库驱动的参数化查询而非手动转义，因手动转义易漏边界情况、破坏预编译逻辑并引发sql注入；仅在动态ddl等极少数场景下按具体方言（mysql/postgresql/sqlite）定制转义策略。
SQL字符串转义为什么不能只靠std::string::replace
直接遍历替换单引号、反斜杠等字符看似简单，但容易漏掉边界情况：比如'要变成''（SQL Server）或'（MySQL启用NO_BACKSLASH_ESCAPES时无效），而 、、
等控制字符在不同SQL方言中处理方式不同。更麻烦的是，如果数据库连接启用了预编译语句（prepared statement），手动转义反而可能破坏参数绑定逻辑，导致SQL注入风险不降反升。
优先用数据库驱动的参数化查询而非手写转义
绝大多数现代C++数据库库（如sqlite3、libpqxx、mysqlcppconn）都支持占位符绑定，这才是真正安全的做法：
// libpqxx 示例（PostgreSQL）
pqxx::work txn{conn};
auto stmt = txn.prepared("insert_user")("name", pqxx::sql_quote(name));
txn.exec_prepared("insert_user", name);
-
sql_quote会根据当前连接的服务器配置自动选择''或'风格，并处理嵌入的 - 使用
prepared语句时，驱动内部确保二进制安全，不经过SQL解析器，彻底规避注入 - 不要自己拼接
"INSERT INTO t VALUES ('" + escape(s) + "')——哪怕escape()看起来很完善
真需要手动生成转义字符串时，按后端方言选策略
仅在极少数场景下（如动态生成DDL、日志记录原始SQL、调试输出）才需手动转义。此时必须明确目标数据库类型：
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- MySQL：启用
NO_BACKSLASH_ESCAPES时，'→''；否则'→'，→\，std::string(data, size)构造） - PostgreSQL：默认用
''，但若启用了standard_conforming_strings=off，还需额外转义为\ - SQLite：只认
''，且不支持反斜杠转义（'会被当作字面量'）
别硬编码一套“通用转义”，不同后端对LIKE中的%、_是否转义也不同，这些必须由执行SQL的上下文决定。
自定义转义函数容易忽略的三个细节
如果项目强制要求手写escape_sql_string，这几个点几乎必踩坑：
- 输入字符串含
c_str()会提前截断——必须用data()和size()遍历 - Unicode多字节字符（如UTF-8中的中文）不能按字节逐个判断，否则可能把一个汉字拆成多个转义，应先验证是否为合法UTF-8再操作
- 某些驱动（如ODBC）要求转义后的字符串长度不超过字段定义长度，而双单引号会让字符串变长，可能触发
data truncation错误
最稳妥的方式仍是让数据库驱动自己处理——它知道连接参数、服务端版本、当前SQL模式，你写的函数不知道。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
