参数化查询能防止sql注入，因为它将sql语句结构与用户输入数据彻底分离：数据库先预编译固定模板，再以二进制方式绑定参数值，使恶意输入（如' or '1'='1）仅被视作普通字符串而非可执行代码，从根本上阻断注入链。
为什么直接拼接搜索输入会触发SQL注入
因为数据库无法区分“用户想查的内容”和“用户想执行的命令”。比如搜索关键词 ' OR '1'='1，如果后端代码写成："SELECT * FROM products WHERE name LIKE '%" + userInput + "%'"，最终拼出的语句就变成：
SELECT * FROM products WHERE name LIKE '%' OR '1'='1%'
单引号提前闭合了字符串，OR '1'='1 变成布尔条件，整个 WHERE 永远为真——结果返回全表数据，甚至可能被用于拖库。
安全替代符（即参数占位符）如何切断攻击链
它让数据库驱动在发送查询前就固定语句结构，所有用户输入只作为纯数据传入，不参与 SQL 解析。数据库收到的是两段独立信息：预编译好的模板 + 二进制绑定值，中间没有字符串拼接环节。
-
?（MySQL/SQLite）、$1（PostgreSQL）、:name（Oracle）这些都不是字符串替换，而是协议级参数绑定 - 即使输入含
;、--、UNION，数据库也只当它是普通字节流，不会尝试解析执行 - 某些驱动（如 Go 的
database/sql）默认启用预处理，但需确认连接参数未设interpolateParams=true（这会退化为客户端拼接）
搜索场景下容易被忽略的陷阱
LIKE 查询带通配符时，很多人误以为加了 % 就得拼接，其实完全可以用参数+服务端拼接：
- 错误做法：
"WHERE name LIKE '%" + userInput + "%'"→ 仍可注入 - 正确做法：用
WHERE name LIKE ?，然后绑定"%" + userInput + "%"—— 这个拼接发生在应用层，不进入 SQL 解析 - 若需转义 LIKE 中的
%或_，应在绑定前对userInput调用strings.ReplaceAll或数据库专用函数（如 MySQL 的ESCAPE），而不是靠前端过滤 - 全文检索（
MATCH ... AGAINST）同样支持参数化，不要因函数名复杂就退回拼接
不是所有“看起来像参数”的写法都安全
有些框架或封装层会伪装成参数化，实则内部仍做字符串替换。关键看是否真正交由数据库驱动处理：
- MyBatis 中用
${}是字符串替换，#{}才是预编译 →${username}危险，#{username}安全 - PHP PDO 开启
PDO::ATTR_EMULATE_PREPARES = true时，prepare()只是模拟，仍可能被绕过 - Node.js 的
mysql2默认禁用模拟预处理，但若手动开启flag: 'FOUND_ROWS'等非标准选项，需确认不影响绑定逻辑
真正的防护不在语法糖，而在确认那条 SQL 到达数据库前，有没有被驱动拆成“结构+数据”两路传输。一旦走通这条路，搜索框就不再是注入入口。
