单纯将单引号替换成双引号（' → ''）仅对SQL Server字符串值有效，无法防护数字型、标识符、注释符等注入点，且MySQL/PostgreSQL等主流数据库不支持该转义；真正有效的防御是全程使用参数化查询，彻底消除字符串拼接。
单纯将单引号替换成双引号（即 ' → ''）只在极少数数据库（如 SQL Server）的字符串字面量中有效，且仅限于特定上下文；它对绝大多数现代 Web 应用场景完全无效，甚至会制造虚假安全感。
SQL Server 的 '' 转义仅适用于字符串值，不覆盖其他注入点
SQL Server 确实支持用两个单引号表示一个字面量单引号，例如 WHERE name = 'O''Connor' 是合法的。但这个机制：
- 只作用于被单引号包裹的字符串值内部，对数字型参数（如
id=1 OR 1=1）完全无感 - 无法防护标识符注入（如表名、列名），这些位置不能加引号，
ORDER BY ${user_input}中填入name; DROP TABLE users--会直接执行 - 不处理分号、括号、注释符（
--、#、/* */），攻击者可借此截断后续逻辑或堆叠语句 - 若后端使用
sp_executesql但未绑定参数，仍可能拼接执行——''替换挡不住EXEC('SELECT * FROM '+@table)
MySQL、PostgreSQL 等主流数据库根本不认 '' 作为转义方式
MySQL 默认用反斜杠转义（\'），PostgreSQL 用 quote_literal() 或标准 SQL 的 E'...' 语法。'' 在它们眼里只是空字符串拼接，不是转义序列：
- MySQL 执行
WHERE name = 'O''Connor'会报错：语法错误，因为第二个'被当作字符串结束符 - 攻击者在 MySQL 场景下直接输入
1 OR SLEEP(5)，没单引号，Replace("'","''")根本不触发，查询变成WHERE id = 1 OR SLEEP(5) - 即使你强行适配多库，在连接字符集为
gbk的旧 MySQL + PHP 组合中，宽字节绕过（如%A1%BF'）会让mysql_real_escape_string漏掉真正的引号，''替换更无从谈起
所有基于字符串替换的防御都败给“上下文错位”
开发者常误以为“只要把用户输入里的 ' 干掉就安全了”，但 SQL 注入的本质是**上下文混淆**——把数据当代码执行。而替换操作无法感知当前输入落在哪个 SQL 位置：
- 出现在
WHERE字符串里？→ 可能需要\'或'' - 出现在
ORDER BY后？→ 必须白名单校验（如['name', 'email', 'created_at']），不能转义 - 出现在
LIMIT后？→ 必须强制转为整型并范围检查，字符串替换毫无意义 - 出现在 JSON_EXTRACT 或正则函数参数里？→ 可能需双重编码或完全禁用
一旦输入落到非字符串上下文，任何单引号替换都自动失效。
真正该做的：用参数化查询替代所有拼接
不是“加强替换”，而是彻底移除字符串拼接机会：
- PHP mysqli：必须用
$stmt = $mysqli->prepare("SELECT * FROM users WHERE id = ? AND status = ?")+$stmt->bind_param("is", $id, $status)，禁用"WHERE id = $id" - Python psycopg2：用
cursor.execute("SELECT * FROM logs WHERE level = %s", (level,))，严禁.format()或%插值 - Java JDBC：只允许
PreparedStatement+setString()/setInt()，拒绝Statement.executeUpdate("... " + input + " ...") - MyBatis：只许用
#{param}，全局搜索并删除所有${param}实例
最危险的不是没做转义，而是做了 Replace("'","''") 后，还在同一段代码里用 id = " . $_GET['id'] . " 拼数字参数——那行代码根本没进替换逻辑，却已裸奔。
