sql中单引号报错是因为其作为字符串定界符，未转义的'会提前终止字符串，如'o'connor'被解析为'o'+'connor'导致语法错误；标准解决法是用两个单引号''代替一个，且优先使用参数化查询彻底规避风险。
SQL插入含单引号的字符串时为什么会报错
因为单引号是SQL字符串的定界符，未转义的 ' 会提前结束字符串字面量，导致语法错误。比如执行 INSERT INTO users(name) VALUES('O'Connor');，数据库会把 O' 当作字符串结尾，后面 Connor 变成非法语法。
最直接的解决方式是用两个单引号代替一个： O''Connor。这是SQL标准定义的转义方法，所有主流数据库（PostgreSQL、SQL Server、SQLite）都支持。MySQL默认也支持，但需确认 sql_mode 中未启用 NO_BACKSLASH_ESCAPES。
- 不要用反斜杠
'—— 这在标准SQL中不合法，仅MySQL在宽松模式下容忍 - 如果字符串来自用户输入，绝不能拼接后直接执行，必须用参数化查询
- JSON字段或XML内容里嵌套单引号，同样适用双单引号规则，无需额外处理外层
使用参数化查询避免手动转义的必要性
手动替换 ' → '' 看似简单，但容易漏掉边界情况：比如字符串末尾的单引号、连续单引号、或配合 LIKE 中的通配符一起出现时逻辑混乱。真正可靠的方案是把值交给驱动层处理。
例如Python + psycopg2：
cursor.execute("INSERT INTO logs(msg) VALUES(%s)", ("User's input: isn't safe",))
这里 %s 占位符由驱动自动完成类型适配和字符转义，连二进制数据、NULL、甚至含 或 " 的字符串都不用操心。
- 所有语言的主流数据库驱动（如Java的JDBC、Node.js的pg、PHP的PDO）都支持命名或位置参数
- ORM如Django ORM、SQLAlchemy默认走参数化，但显式写
raw_query时仍可能绕过，需警惕 - 存储过程内部的动态SQL（如PostgreSQL的
EXECUTE ... USING）也应优先用USING传参，而非字符串拼接
MySQL中反斜杠转义与SQL_MODE的实际影响
MySQL默认允许用 ' 表示字面单引号，但这依赖于 sql_mode 配置。一旦服务器启用了 NO_BACKSLASH_ESCAPES，反斜杠就失去转义能力，' 会被当作普通字符处理，而 \ 才表示单个反斜杠。
查当前模式：SELECT @@sql_mode;；临时修改：SET sql_mode = 'NO_BACKSLASH_ESCAPES';。生产环境不应依赖反斜杠，因为模式可能被DBA统一调整。
- 跨库迁移时（如从MySQL迁到PostgreSQL），含
'的硬编码SQL必然失败 -
mysql_real_escape_string()这类旧函数已废弃，它依赖连接状态且无法防御所有编码绕过 - 若必须用字符串拼接（极不推荐），应调用驱动提供的
escape()方法（如PHP的PDO::quote()），而非自己实现
LIKE语句中下划线和百分号的双重转义陷阱
在 WHERE name LIKE '%John%' 中，% 是通配符；但如果要查真实包含 % 的名字（如“100% Pure”），就得转义它。但转义字符本身也可能需要转义——比如你选 作转义符，那字符串里真有反斜杠时，就得写成 \。
正确写法（标准SQL）：WHERE desc LIKE '%100% Pure%' ESCAPE ''。注意：这里的 % 是告诉数据库“这个 % 不是通配符”，而 ESCAPE '' 声明了转义符。
- PostgreSQL还支持用
ESCAPE ''（空字符串）禁用转义，此时所有字符都按字面匹配 - MySQL中若启用了
NO_BACKSLASH_ESCAPES，就得换别的转义符，比如WHERE name LIKE '%100|%' ESCAPE '|' - 参数化查询对
LIKE同样有效：用WHERE name LIKE %s，然后传入'%100% Pure%'（Python中注意字符串字面量的反斜杠需写两遍）
psql -v var="'O''Connor'" -c "INSERT ..." 或类似方式，而不是在SQL里硬塞转义逻辑。
