参数化查询能阻断恶意update操作，因为数据库在执行前已固定sql结构，用户输入仅作为纯数据绑定至占位符（如?或%s），不参与语法解析；即使输入' or '1'='1或; drop table users，也仅被当作字符串值写入字段，绝不会触发额外语句。
为什么参数化查询能阻断恶意 UPDATE 操作
因为数据库在执行 UPDATE 前已固定语句结构，用户输入只作为纯数据绑定进占位符，不会参与语法解析。哪怕输入 ' OR '1'='1 或 ; DROP TABLE users，它也只会被当作字符串值写入字段，绝不会触发额外语句或逻辑篡改。
UPDATE 语句必须用 ? 或 %s 占位符，不能拼接变量
常见错误是把用户输入直接插进 SQL 字符串里，比如 Python 中写成："UPDATE users SET name = '" + user_name + "' WHERE id = " + user_id —— 这等于给攻击者递刀。
- ✅ 正确做法：所有动态值（包括
WHERE条件、SET字段）都走参数绑定 - ✅ 占位符类型取决于驱动：
?（SQLite、JDBC）、%s（MySQLdb、PyMySQL）、$1（PostgreSQL 的 psycopg2） - ❌ 错误做法：仅对部分字段参数化，而把表名、字段名、排序方向等拼进去（这些无法参数化，需白名单校验）
Python + SQLite 示例：带 WHERE 和 SET 的完整参数化 UPDATE
注意：参数只能替换值，不能替换列名或表名。下面这个例子覆盖了最常用场景：
cursor.execute(
"UPDATE users SET email = ?, status = ? WHERE id = ? AND tenant_id = ?",
(new_email, new_status, user_id, tenant_id)
)
如果 user_id 是字符串类型（比如 UUID），仍要传原值，不要手动加引号；数据库驱动会按参数类型自动处理转义和类型适配。
容易被忽略的边界情况
参数化不是万能银弹，这几个点不处理好照样翻车：
- 动态表名或字段名：如
"UPDATE ? SET ..."是语法错误，必须用白名单判断后硬编码，比如if table_name in ['users', 'orders']: - ORDER BY 或 LIMIT 后的参数：数据库不支持占位符，需用
int()强转并校验范围，避免注入id ASC; DROP TABLE... - 批量更新多行：不同驱动支持方式不同，SQLite 不支持多参数组一次执行，得用循环 + 单条参数化；PostgreSQL 可用
executemany() - ORM 用户注意：Django 的
.update()、SQLAlchemy 的update().values()默认就是参数化的，但若手写 raw SQL 并用text()执行，仍需显式绑定参数
真正危险的从来不是“会不会用参数化”，而是“哪里没意识到必须用”。表名、排序、分页、条件分支——这些地方一旦松动，前面所有参数化都白做。
