参数化INSERT是防止SQL注入最可靠的方式，它将用户输入严格作为数据绑定，不参与SQL语法解析，即使输入恶意payload也仅被视作字符串；而字符串拼接INSERT会使输入进入语法树构建阶段，导致闭合字段、执行多语句等风险，表名、列名等非值动态内容须白名单校验。
参数化 INSERT 是防止 SQL 注入最可靠的方式，它把用户输入当作纯数据处理，而不是可执行代码。只要参数绑定正确，哪怕输入 ' OR 1=1 -- 或 ; DROP TABLE users，数据库也只当它是字符串值，不会触发额外逻辑。
为什么拼接 INSERT 字符串必然危险
直接用字符串拼接构造 INSERT 语句，等于把用户输入放进 SQL 解析器的“语法树构建阶段”。一旦输入含单引号、分号、注释符或括号，就可能提前闭合字段值、插入新语句或篡改结构。
- 常见错误写法：
"INSERT INTO users (name, email) VALUES ('" + name + "', '" + email + "')" - 攻击示例：若
name = "Robert'); DROP TABLE students; --"，整条语句变成：INSERT INTO users (name, email) VALUES ('Robert'); DROP TABLE students; --', '...') - 后果：语句被截断执行，
DROP TABLE真的会运行
不同语言中 INSERT 参数化的标准写法
核心原则一致：SQL 模板里只出现占位符，所有变量通过独立参数传入，由驱动/库完成类型绑定和转义。
-
Python + pymysql / sqlite3：用
%s（MySQL）或?（SQLite）占位，传元组或列表cursor.execute("INSERT INTO users (name, email) VALUES (%s, %s)", (name, email)) -
PHP + PDO：用
?或命名参数:name，调用bindValue()或execute()$stmt = $pdo->prepare("INSERT INTO users (name, email) VALUES (?, ?)");<br>$stmt->execute([$name, $email]); -
C# + ADO.NET：用
@param命名参数，显式指定类型更安全cmd.CommandText = "INSERT INTO users (name, email) VALUES (@name, @email)";<br>cmd.Parameters.Add(new SqlParameter("@name", SqlDbType.NVarChar).Value = name);
INSERT 中容易被忽略的注入点
很多人只防字段值，却漏掉表名、列名、ORDER BY 或 LIMIT 后的动态部分——这些不能参数化，必须白名单校验。
-
INSERT INTO后的表名不能用参数，必须硬编码或从预设枚举中取：if table_name not in ['users', 'orders', 'logs']: raise ValueError -
INSERT INTO ... (col1, col2)中的列名也不能参数化，需提前定义合法字段列表 -
LIMIT ?在 MySQL/PostgreSQL 中支持参数化，但ORDER BY ?不行——排序字段必须走白名单：order_col = 'created_at' if order_col in ['id', 'created_at', 'name'] else 'id'
存储过程里 INSERT 的参数化陷阱
在存储过程中，INSERT 本身用参数是安全的，但若内部拼接了动态 SQL（比如用 CONCAT() 构造表名），参数就完全失效。
- ✅ 安全写法：
INSERT INTO users (name, email) VALUES (@name, @email); - ❌ 危险写法：
SET @sql = CONCAT('INSERT INTO ', @table_name, ' (name) VALUES (', @name, ')'); EXEC(@sql);—— 这里@name被直接拼进字符串，参数化无效 - 如果真要动态表名，只能用
QUOTENAME()（SQL Server）或QUOTE_IDENT()（PostgreSQL）做标识符转义，且仍需白名单兜底
真正难的不是写对一行 execute()，而是确保所有动态拼接点都被识别、隔离、校验——尤其是那些看似“不重要”的上下文，比如日志表名、临时表前缀、分表路由字段。
