std::format 在 SQL 拼接中根本不能用
它不安全，也不该被用来构建 SQL 查询语句——std::format 是为格式化输出设计的，不是 SQL 注入防护工具。哪怕你传入的全是 int 或 std::string_view，只要原始数据来自用户输入或外部系统，直接插进 SQL 字符串里，就等于把单引号、--、; 全部交由数据库执行。
为什么 std::format 看似“类型安全”却实际危险
类型安全 ≠ SQL 安全。std::format 确实能避免 printf 风格的参数错位，但它对字符串内容完全不做转义或上下文感知：
-
std::format("SELECT * FROM users WHERE name = '{}'", user_input)—— 若user_input是O'Reilly，结果就是语法错误；若是admin'--，就绕过认证 - 它无法区分“字面量字符串”和“SQL 标识符”（如表名、列名），而后者需要反引号或双引号包裹，且有保留字冲突风险
- 没有运行时绑定机制，所有替换都在 C++ 层完成，数据库完全看不到参数结构
真正安全的做法：用参数化查询（Prepared Statement）
把动态部分交给数据库驱动处理，而不是在 C++ 里拼字符串。主流方案依赖具体数据库客户端库：
- PostgreSQL +
libpqxx：用prepared_statement+bind()，参数自动转义并按类型送入协议 - MySQL +
mysqlcppconn：调用sql::PreparedStatement::setString()等类型化 setter - SQLite +
sqlite3_bind_*系列 C API：手动绑定，但类型明确（sqlite3_bind_text/sqlite3_bind_int） - 不要自己写“转义函数”：比如对单引号加反斜杠——不同数据库规则不同，且容易漏掉 Unicode 边界、NUL 字节等
如果非得生成 SQL 字符串（调试/日志/DDL），至少隔离用途
仅限可信上下文，比如单元测试中固定数据、或生成迁移脚本。此时需严格限定输入源，并手动约束类型：
立即学习“C++免费学习笔记（深入）”；
- 列名/表名：只允许 ASCII 字母、数字、下划线，用正则验证（
std::regex_match(name, std::regex{"^[a-zA-Z_][a-zA-Z0-9_]*$"})） - 字面量值：用数据库对应转义函数，如 PostgreSQL 的
pg_escape_string（C API），而非自己 replace - 数值类：可放心用
std::format，但必须确认变量是int/double等非字符串类型，且不参与拼接标识符 - 永远不要把
std::string或std::string_view直接塞进std::format的 SQL 模板里
最常被忽略的一点：即使你控制了全部输入，只要 SQL 字符串最终被 exec 或 execute 执行（而非 bind），就回到了字符串注入的老路。安全不在格式化函数，而在执行路径是否分离数据与结构。
