SQL Server中单引号未转义或LIKE下划线未用ESCAPE子句导致Incorrect syntax near错误；应使用sp_executesql参数化而非字符串拼接，并统一处理转义逻辑。
直接结论：报错通常不是因为参数本身含特殊字符，而是你把参数拼进了 SQL 字符串里——尤其是单引号没转义、或 LIKE 里下划线被当通配符用了。
SQL Server 存储过程中单引号导致 Incorrect syntax near 错误
错误现象：Incorrect syntax near 'Reilly' 或语句提前截断，本质是动态 SQL 拼接时没处理好字符串边界。
- 别在存储过程里写
SET @sql = 'SELECT * FROM t WHERE name = ''' + @name + ''''—— 这种拼法要求 @name 里的单引号必须已是O''Reilly格式，但应用层传入的原始值几乎不可能满足 - 正确做法是彻底避开拼接：用
sp_executesql+ 参数占位符，SQL 字符串里只出现@name，不出现任何引号 - 示例：
EXEC sp_executesql N'SELECT * FROM users WHERE last_name = @name', N'@name NVARCHAR(50)', @name = @input；注意类型声明N'@name NVARCHAR(50)'缺一不可，否则可能隐式转换失败
MySQL 存储过程里 CONCAT 拼接含单引号的字符串
MySQL 没有原生参数化执行接口，PREPARE + EXECUTE 只认变量名，不接受运行时值绑定，所以必须手动转义——但方式和 SQL Server 完全不同。
- 别用
REPLACE(@str, "'", "''")（这是 SQL Server 写法，MySQL 不认） - 推荐用内置函数
QUOTE()：SET @sql = CONCAT('SELECT * FROM t WHERE name = ', QUOTE(@name))；它自动加外层单引号，并转义内部所有危险字符（'、"、\、NULL字节等） - 注意：
QUOTE()返回的是带引号的字符串，拼接时不能再额外加引号，否则变成'''abc'''导致语法错误
LIKE 查询中 _ 和 % 被当成通配符匹配错数据
参数化查询防不了这个——WHERE name LIKE @pattern 传入 'user_name'，下划线仍会匹配任意单字符，这不是注入问题，是 LIKE 语义本身。
- SQL Server 必须显式用
ESCAPE子句，且两端一致：比如用!当转义符，就得写WHERE name LIKE '%user!_name%' ESCAPE '!'，同时应用层或 SQL 层要把原始输入的_替换成!_ - PostgreSQL 的
ILIKE同样要ESCAPE；但正则~里_是字面量，.才是通配符，规则翻转了 - 最常踩的坑：在存储过程里对
@input做了REPLACE(@input, '_', '!_')，却忘了在LIKE后补ESCAPE '!'，结果要么报错，要么逻辑完全不对
为什么参数化查询有时还“失效”
不是参数化本身有问题，而是你没用在关键位置，或者 ORM/驱动悄悄绕过了它。
- Java JDBC 必须用
PreparedStatement并调用setString()；用Statement执行拼接字符串，等于裸奔 - PHP PDO 默认开启
PDO::ATTR_EMULATE_PREPARES，会退化为客户端模拟预编译，失去防护能力，务必设为false - Django 的
extra()、SQLAlchemy 的text()若未显式绑定参数，生成的 SQL 仍是字符串拼接，%s占位符会被直接展开
真正容易被忽略的点：LIKE 的转义逻辑必须贯穿全程——从应用层构造 pattern，到 SQL 层声明 ESCAPE，再到驱动不二次解析转义符。少一环，数据就错一片。
