INSERT INTO ... VALUES (...), (...)更危险，因其天然需拼接多组值，若用字符串拼接，攻击者在任一字段注入"); DROP TABLE users; --即可终止插入并执行恶意命令，尤其JSON/CSV unpack后直接拼接时风险指数级上升。
表单批量提交时，为什么INSERT INTO ... VALUES (...), (...)更危险？
因为这类语句天然需要拼接多组值，一旦用字符串拼接构造 SQL，攻击者只要在任一字段中注入); DROP TABLE users; --，就能终止当前插入、执行恶意命令。尤其当后端把整个 JSON 数组或 CSV 行直接 unpack 后拼进 SQL，风险指数级上升。
常见错误现象：sqlite3.OperationalError: near "DROP": syntax error看似报错就安全了，但某些数据库（如 MySQL）默认允许堆叠查询，;后的语句仍会被执行。
- 避免手写
VALUES列表拼接：哪怕做了简单替换（如把'换成''），也挡不住1', (SELECT password FROM users LIMIT 1), 'x这类绕过 - 改用参数化批量插入：SQLite 支持
executemany()，MySQL/PostgreSQL 支持INSERT ... VALUES ?配合多参数元组 - 若必须动态生成列名（如导表字段不固定），先白名单校验
column_name是否在预设集合内，再拼接
executemany()和execute()在批量场景下的关键区别
execute()只传一组参数，executemany()才是批量安全的正确姿势——它底层仍调用单条预编译语句，只是复用执行计划，不会把数组“展开”成字符串塞进 SQL。
示例对比：
cursor.execute("INSERT INTO logs (url, status) VALUES (?, ?)", ["'https://x.com", 200]) # 错误：只插1行，且参数类型错cursor.executemany("INSERT INTO logs (url, status) VALUES (?, ?)", [
["https://a.com", 200],
["https://b.com", 404],
["'); DROP TABLE logs; --", 500] # 这个恶意值会被当纯字符串处理
])注意：executemany()不支持返回自增 ID，如需主键反馈，得改用execute()循环 + 事务包裹，或启用数据库的RETURNING语法（PostgreSQL）。
前端传来的 JSON 数组，后端怎么防住id字段里的1 OR 1=1？
问题不在 JSON 解析，而在后续如何把data[0].id塞进 SQL。很多开发者以为“JSON 已解析就安全”，结果还是拼进"WHERE id = " + data.id。
必须坚持：所有用户输入，无论来源（form、JSON、URL query），一律走参数化路径。
- 禁止用
str.format()或%拼接 SQL，哪怕只拼一个值 - 对数字型字段（如
id），额外加类型强转：int(data.get("id", 0))，再传给?占位符；非数字则直接拒收 - 如果业务真要支持表达式（如
id > 100），必须用独立 DSL 解析器，而非放行到 SQL 层
为什么限制LIMIT不能代替参数化？
DELETE FROM orders WHERE status = 'pending' LIMIT 100看起来安全，但前提是status值本身已参数化。如果写成"... WHERE status = '" + user_input + "' LIMIT 100"，攻击者仍可闭合引号注入OR 1=1，让LIMIT失效。
真正起作用的是两层防护：第一层用?堵死拼接入口，第二层用LIMIT兜底防误操作。前者防黑客，后者防自己手抖。
容易被忽略的点：ORM 框架（如 Django ORM、SQLAlchemy）默认开启参数化，但一旦调用.extra()、.raw()或text()，就退出安全区——这些 API 的字符串内容必须人工确保无用户输入混入。
