答案是应使用参数化查询而非驱动的escape函数。因escape函数依赖字符集和sql mode、不处理边界情况且已被弃用；而参数化查询由mysql协议层安全传参，彻底规避sql注入与转义失效风险。
直接用驱动程序的 escape 函数不安全，也基本不存在这种通用函数。MySQL 官方驱动（如 mysql-connector-python、PyMySQL、mysql2 for Ruby）都不提供名为 escape 的独立字符串转义函数——这不是标准接口，也不是推荐路径。
为什么找不到可靠的 escape 函数？
所谓“驱动自带 escape”常是误解：早期某些 ORM 或封装库（比如旧版 Django 的 connection.escape_string()，或 PHP 的 mysql_real_escape_string()）确实暴露过类似接口，但它们：
• 严重依赖当前连接的字符集和 SQL mode 配置，换环境就失效
• 不处理二进制数据、NULL 字节、多字节边界等边界情况
• 已被官方弃用（例如 PHP 7+ 移除了 mysql_* 系列函数）
• 在现代异步驱动（如 aiomysql）或连接池场景下根本不可用
真正安全的做法：只用参数化查询
所有主流语言驱动都原生支持预处理语句（prepared statement），这才是唯一被 MySQL 服务端直接解析、完全绕过字符串拼接的机制：
-
mysql-connector-python：用%s占位符 +cursor.execute("INSERT ...", (value,)) -
PyMySQL：同上，%s是唯一受支持的占位符，不认? -
mysql2（Ruby）：用?占位符，client.query("SELECT ... WHERE name = ?", name) -
node-mysql2：默认开启namedPlaceholders: true，支持:name语法
关键点：占位符不是字符串替换，而是由 MySQL 协议层将值作为独立参数传入执行计划，单引号、双引号、反斜杠、NULL 字节全无需处理。
如果真要手动转义（仅限极少数调试/日志场景）
必须严格匹配当前连接的实际配置，且仅用于生成可读 SQL 日志（绝不能用于拼接执行）：
- 确认是否启用了
ANSI_QUOTES模式：SELECT @@sql_mode；若启用，双引号也需转义 - 查当前连接字符集：
SELECT @@character_set_client；非utf8mb4时，\'可能被截断 - Python 中模拟（仅供理解，勿用于生产）：
value.replace("\", "\\").replace("'", "\'")—— 但这个结果仍可能在宽字符或特殊 mode 下出错
实际项目里，只要出现“需要 escape 字符串再拼 SQL”的需求，说明架构已偏离安全基线。
最易被忽略的一点：即使你写了看似正确的 replace("'", "''")（SQL Server 风格）或 replace("'", "\'")（MySQL 风格），只要没同步校验连接的 sql_mode 和 character_set_client，这条语句在另一台服务器上大概率执行失败或被注入。
