参数化查询从根本上阻断sql注入，是通过数据库协议层实现代码与数据的物理分离：先编译sql模板，再以二进制/独立字段方式绑定参数，使用户输入恒为纯数据、永不参与语法解析。
因为参数化查询从执行机制上切断了“用户输入被当作SQL代码执行”的路径，不是靠过滤、转义或猜攻击意图，而是让数据库引擎天然拒绝把参数当语法解析。
参数化查询如何从根本上阻断注入链路
SQL注入能成功，本质是数据库把拼接进字符串的用户输入（比如 admin' OR '1'='1）当作可执行的语法片段去解析。参数化查询强制把 SQL 结构（SELECT * FROM users WHERE username = ?）和数据（admin' OR '1'='1）分两步传给数据库：先编译语句骨架，再绑定值。数据库此时只把参数当纯数据处理，哪怕内容含单引号、分号、注释符，也不会触发语法重解析。
这跟 addslashes() 或正则过滤完全不同——后者是在应用层做“文本擦除”，而参数化是数据库层的“语义隔离”。
不同语言里参数化写法差异与常见误用
占位符和传参方式因驱动而异，但核心逻辑一致；错用会导致形同虚设：
- Python（sqlite3）用
?，传参必须是元组或列表：cursor.execute("WHERE id = ?", (user_id,))——漏掉逗号写成(user_id)就变成整数，报错 - PostgreSQL（psycopg2）用
%s，但不能直接用%格式化字符串：query = "WHERE name = %s" % user_input是拼接，完全不安全 - PHP（PDO）支持
?和:name，但若用PDO::exec()执行非查询语句，仍需确保参数化，不能 fallback 到mysql_query() - Java（JDBC）必须用
PreparedStatement+setString()等方法，直接调statement.executeQuery(sql)就是裸拼接
为什么其他方案无法替代参数化
很多做法看起来“也防注入”，但都有明确短板：
-
htmlspecialchars()是防 XSS 的，对 SQL 解析毫无作用 - WAF 规则匹配关键词（如
UNION SELECT）容易被编码绕过，且无法覆盖定制化攻击变种 - 存储过程若内部用
EXEC(@sql)动态拼接，照样中招；只有配合sp_executesql+ 参数才安全 - ORM 如 Django 或 SQLAlchemy 默认安全，但一旦调用
.extra()、.raw()或手写 SQL 字符串，就退出保护层
参数化是唯一在协议层就确立“数据不可执行”原则的方案，其余都是补充手段。
动态字段（表名、列名、ORDER BY）无法参数化的现实
占位符只能用于值（WHERE 条件、INSERT 值、UPDATE SET 右侧），不能用于标识符（表名、列名、GROUP BY 字段、ORDER BY）。这类场景必须用白名单校验：
- 排序字段只允许
['id', 'name', 'created_at']中的值，不能直接拼ORDER BY $_GET['sort'] - 多租户表名若按客户 ID 分片，需映射到预定义表名列表，而非字符串拼接
- 任何涉及标识符的动态 SQL，都意味着你正在绕过参数化防线，必须人工兜底
真正难的不是写对 ?，而是识别出哪些地方根本不能用 ? —— 那些地方才是最常被忽略的漏洞入口。
