SQL字符串拼接危险因用户输入直接混入SQL，导致注入攻击；须用参数化查询并禁用模拟预处理，严格匹配占位符与参数类型及顺序。
为什么 string + SQL 拼接是危险的
问题的根源在于，当用户输入被直接“揉”进SQL语句字符串时，数据库引擎根本无法分辨哪些是预设的逻辑，哪些是不可信的数据。一个经典的例子是，如果用户输入了 ' OR 1=1 --，拼接后的语句就会变成 SELECT * FROM users WHERE name = '' OR 1=1 --'。结果呢？整个用户表的数据都可能被泄露。
下面这些写法，是不是看着很眼熟？mysql_query("SELECT * FROM user WHERE id = " . $_GET['id'])，或者 f"SELECT * FROM log WHERE msg = '{user_input}'"。必须指出，即便你在拼接前加了 trim() 或 intval() 这类过滤，也未必能防住多字段组合注入或时间盲注等高级攻击手法。
- 一个核心原则是：所有动态值——无论是数字、字符串，甚至是极少情况下需要动态指定的列名或排序方向——都绝对不应该通过字符串拼接的方式进入SQL。
- 列名和表名本身无法使用参数占位符。如果业务逻辑必须动态指定，那么唯一安全的做法是采用白名单校验，例如只允许从
['name', 'email', 'created_at']这个预设列表中选择。 - 排序方向（
ASC/DESC）同样不能参数化。安全的做法是使用类似in_array($dir, ['ASC', 'DESC'])的代码进行严格过滤。
PHP 中用 PDO::prepare() 和 bindValue() 的硬性姿势
这里有个常见的误区：不是调用了 prepare() 方法就万事大吉了。真正的安全关键在于确保“数据值不进入SQL字符串”。你知道吗？PDO默认是开启模拟预处理模式的（PDO::ATTR_EMULATE_PREPARES = true）。在某些版本或特定查询（如包含 LIKE 子句或类型不匹配）时，它可能会在底层退化成字符串拼接，让所有的防护努力前功尽弃。
因此，实操中务必遵循以下几点：
- 创建PDO实例后，第一件事就是显式关闭模拟预处理：
$pdo->setAttribute(PDO::ATTR_EMULATE_PREPARES, false)。 - 优先使用
bindValue()而非bindParam()，除非你确实需要变量引用的特性。bindValue()的行为更直观，类型控制也更明确。 - 绑定参数时，务必明确指定类型。例如，数字用
PDO::PARAM_INT，这能避免字符串被意外当作数字解析而引发错误。 - 来看一个标准示例：
$stmt = $pdo->prepare("SELECT * FROM posts WHERE status = ? AND created_at > ?"); $stmt->bindValue(1, 'published', PDO::PARAM_STR); $stmt->bindValue(2, $since, PDO::PARAM_STR);
Python 的 sqlite3 和 psycopg2 参数占位符别混用
不同的数据库驱动，其参数占位符的语法也各不相同。这是一个极易踩坑的地方：用错一个符号，参数化查询就可能悄无声息地退化为危险的字符串拼接，而且系统往往不会报错。比如，sqlite3 只认 ? 或 :name 这种命名占位符，而 psycopg2（用于PostgreSQL）则使用 %s（注意，这里统一用 %s，而不是 %d 或 %f）。一旦混淆，SQL注入的大门就敞开了。
常见的翻车现场包括：
- 在
psycopg2中写成"WHERE id = %d" % user_id—— 这其实是Python的字符串格式化，并非数据库驱动的参数化绑定。 - 使用
f-string提前构造语句：f"WHERE name = '{name}'"—— 即便后续将这个字符串传给cursor.execute(...)，也为时已晚，数据已经拼接进去了。 - 误以为
sqlite3的命名参数可以用于列表：WHERE name IN (:names)是无效的。正确做法是将列表展开为多个?，如WHERE name IN (?, ?, ?)，再进行绑定。 - 正确示例（psycopg2）：
cursor.execute("SELECT * FROM orders WHERE user_id = %s AND status = %s", (uid, 'shipped'))
Node.js 里 pg 和 mysql2 的参数位置不能手滑
Ja vaScript作为一种动态语言，缺乏编译期的严格检查。这意味着，如果占位符和传入的参数数组对不上号，轻则导致查询不到预期数据，重则可能完全绕过参数化机制。例如，在PostgreSQL的 pg 驱动中，如果你写了两个 $1 却只传一个值，它会报错；但如果你不小心写成了字符串模板拼接，它就会默默地执行那个不安全的查询。
以下几个细节必须盯紧：
pg驱动使用$1,$2这种位置占位符，其顺序必须严格对应参数数组的元素位置，不能跳号，也不能重复。mysql2驱动使用?占位符，同样是按从左到右的顺序替换。它虽然支持通过配置开启命名占位符模拟（namedPlaceholders: true），但底层仍会转换为?，使用时需注意版本兼容性。- 切记，绝对不要在SQL字符串中间出现
${}（模板字符串）或+（字符串连接）来进行拼接，哪怕你只是想加个空格——像`WHERE id = ${id} AND active = 1`这样的写法，就是典型的高风险代码。 - 示例（pg）：
client.query('SELECT * FROM products WHERE category = $1 AND price
最后，也是最容易被忽视的一点：使用ORM（对象关系映射）框架并不等于绝对安全。以TypeORM为例，find({ where: { name: req.query.q } }) 这种写法看起来挺安全，但如果前端传来的 q 参数是一个像 { $like: '%admin%' } 这样的对象，并且框架没有关闭对原始操作符的支持，那么注入攻击依然可能发生。所以，参数化的精髓不在于“是否使用了某个高级工具”，而在于“每一个动态值是否都严格走了绑定通道”。这才是构筑数据库安全防线的根本所在。
