SQL中单引号字符串报错的根源是嵌入单引号未转义，标准解法为双单引号转义（如'It''s a test'）并优先采用参数化查询，避免拼接风险。
SQL中单引号字符串报错：常见错误现象
执行类似 SELECT * FROM users WHERE name = 'O'Connor'; 时直接报错，提示语法错误或“unclosed quotation mark”。这是因为 SQL 把第一个单引号当成字符串起始，遇到 O' 中的第二个单引号就认为字符串意外结束，后续的 Connor' 变成非法语法。
标准写法：用两个单引号转义
SQL 标准规定，字符串内嵌单引号必须写成连续两个单引号 ''，而不是反斜杠 \'（后者在 MySQL 某些模式下可能临时生效，但不跨数据库兼容）。
-
INSERT INTO logs (msg) VALUES ('User ''admin'' logged in');→ 存入的是User 'admin' logged in -
WHERE title = 'It''s a test';→ 匹配It's a test - 注意：不是
\'、不是\"、也不是 Unicode 字符，就是原样敲两个 ASCII 单引号
参数化查询才是根本解法（尤其在应用层）
硬拼字符串永远有风险，哪怕你手动双写单引号，也难防逻辑分支漏处理或编码不一致。真正安全的做法是交由数据库驱动做参数绑定。
- Python + psycopg2：
cursor.execute("SELECT * FROM users WHERE name = %s", ["O'Connor"]) - Java + JDBC：
preparedStatement.setString(1, "O'Connor"); - Node.js + pg：
client.query("SELECT * FROM users WHERE name = $1", ["O'Connor"]) - 此时传入的值完全不参与 SQL 解析，单引号、分号、甚至
OR 1=1都不会触发注入
不同数据库对字符串转义的容忍度差异
虽然双单引号是 SQL 标准，但部分数据库在特定配置下允许其他形式，容易让人误以为“可用”，结果换环境就崩：
- MySQL 默认启用
ANSI_QUOTES时，双引号才表示标识符，单引号仍必须双写；若关闭该模式，又可能接受\'（但仅限于NO_BACKSLASH_ESCAPES关闭时） - PostgreSQL 严格遵循标准，
\'默认不识别，除非开启standard_conforming_strings = off（已废弃） - SQL Server 支持双单引号，也支持前缀
N'...'表示 Unicode 字符串，但内部单引号仍需双写 - 结论：别依赖数据库扩展行为，坚持双单引号 + 参数化，兼容性最稳
实际开发里，最常被忽略的是动态拼接日志条件或导出 SQL 脚本这类“非主流程”场景——这里往往绕过 ORM 或参数化，直接字符串拼接，结果一遇到姓 O’Reilly 或 Mc’Alister 的用户就查不到数据。盯住这些边缘路径，比纠结某条语句怎么写更重要。
