唯一可靠解法是用参数化查询，别拼字符串；手动替换'为''只防单引号却漏分号、注释符等注入点，且跨数据库转义不一致、多层嵌套易出错。
WHERE 条件里写 O'Reilly 会直接报错，这不是数据问题，是 SQL 解析器在第一个 ' 就结束了字符串——唯一可靠解法是用参数化查询，别拼字符串。
为什么手动替换 ' 为 '' 是高危操作
看似能过语法关，但实际埋了两个雷：
只处理单引号，漏掉分号、--、/* 等注入点，攻击者仍可执行任意语句
不同数据库转义规则不一致：PostgreSQL 默认禁用 \'，MySQL 在 NO_BACKSLASH_ESCAPES 模式下也不认反斜杠
多层嵌套时极易漏转，比如 JSON 字段里再套 SQL 片段，replace("'", "''") 会把整个 JSON 的引号全干掉
psycopg2、JDBC、PDO 等驱动怎么用参数化
所有主流驱动都原生支持，你只需传值，转义由服务端自动完成：psycopg2：使用 %s 占位，cursor.execute("SELECT * FROM users WHERE name = %s", ["O'Reilly"])JDBC：用 ? 占位，stmt.setString(1, "O'Reilly")PDO：命名参数，$stmt->execute(['name' => "O'Reilly"])
注意：Oracle 用 ?，不是 :name；SQL Server 支持 @name，但必须显式声明类型（如 SqlDbType.NVarChar），否则隐式转换可能失败
静态 SQL（建表、视图、脚本）中必须手写时怎么处理
仅限完全可控场景（如初始化脚本、日志模板），且必须满足：
只用于字符串字面量，绝不能用于表名、列名（那些该用双引号或方括号）
严格按 SQL 标准：每个 ' 替换为 ''，不是 \'，也不是 "
示例：WHERE title = 'O''Reilly & Associates'——这里 & 不用转，只有单引号要双写
MySQL 提供 QUOTE() 函数辅助生成安全字面量，但仅限服务端使用，无法替代应用层参数化
真正棘手的从来不是单引号本身，而是你不确定输入来源是否干净、是否经过其他中间件预处理、是否在日志或监控中又被二次解析——这些边界场景下，只有参数化查询能守住底线。
