参数化查询是唯一能同时防语法错误和sql注入的做法；手动将单引号替换为双单引号仅处理字符串字面量，漏掉分号、注释符等注入点，且跨数据库转义规则不一致，多层嵌套易出错，而参数化由驱动自动完成类型绑定与转义。
直接用参数化查询，别拼字符串——这是唯一能同时防语法错误和SQL注入的做法。
为什么手动替换 ' 为 '' 是高危操作
看似能解决 ERROR: unterminated quoted string，但实际埋了两个雷：
- 只处理单引号，漏掉分号、反斜杠、注释符（
--、/*）照样触发注入 - 不同数据库对转义规则不一致：PostgreSQL 默认禁用
\'，MySQL 兼容但需开启NO_BACKSLASH_ESCAPES模式 - 多层嵌套时容易漏转，比如 JSON 字段里再套 SQL 片段，
replace("'", "''")会把整个 JSON 的引号全干掉
PreparedStatement / 参数占位符才是标准解法
所有主流驱动都原生支持，数据库服务端自动完成类型绑定与字符转义，你不用管单引号在哪、有几个：
- Java JDBC：
SELECT * FROM users WHERE name = ?+stmt.setString(1, userInput) - Python psycopg2：
cursor.execute("SELECT * FROM users WHERE name = %s", [userInput]) - C# ADO.NET：
cmd.Parameters.AddWithValue("@name", userInput) - PHP PDO：
$stmt->execute(['name' => $userInput])
注意：Oracle 用 ? 占位，不是 :name；SQL Server 支持 @name，但必须显式声明类型（如 SqlDbType.NVarChar）避免隐式转换失败。
实在要拼字符串时，'' 是唯一可接受的转义形式
仅限调试、日志、静态配置等完全可控场景，且必须满足：
- 只用于字符串字面量，不能用于表名、列名（那些该用双引号或方括号）
- 严格按 SQL 标准：把每个
'替换为''，不是\'，也不是" - 示例：
WHERE title = 'O''Reilly & Associates'—— 这里&不用转，只有单引号要双写
MySQL 提供 QUOTE() 函数辅助生成安全字面量，但仅限服务端使用，无法替代应用层参数化。
真正棘手的从来不是单引号本身，而是你不确定输入来源是否干净、是否经过其他中间件预处理、是否在日志或监控中又被二次解析——这些边界场景下，只有参数化查询能守住底线。
