拼字符串拼出来的防s方式 SQL，迟早要出事。注入最佳我见过一个后台登录接口，防s方式前端传 username=admin' --，注入最佳后端直接把这段拼进查询里，防s方式结果密码验证被注释掉了，注入最佳攻击者空着密码就进了管理后台。防s方式这不是注入最佳段子，是防s方式真实发生过的案例，而且类似的注入最佳代码现在仍然有人在写。

问题的防s方式根源不在于开发者粗心，而在于把「数据」和「指令」混在了一起。注入最佳SQL 语句本身有语法结构，防s方式用户输入如果被当作语法的注入最佳一部分来解析，那就等于把方向盘交给了乘客。防s方式防注入的核心思路只有一个：让数据库永远分清楚哪部分是你要执行的命令，哪部分是纯粹的数据。

参数化查询是唯一正解

参数化查询（Prepared Statement）做的事情很朴素——先把 SQL 语句的骨架发给数据库编译，此时占位符 ? 或者 $1 的位置已经确定了语法结构。然后再把用户输入的值填进去，数据库只把它当值处理，不会重新解析成 SQL 语法。

用 Java 举例：

String sql = "SELECT * FROM users WHERE username = ? AND password = ?"; PreparedStatement ps = connection.prepareStatement(sql); ps.setString(1, username); ps.setString(2, password); ResultSet rs = ps.executeQuery();

就算用户输入 admin' --，数据库收到的也只是「一个叫 admin' -- 的用户名」，而不是「用户名是 admin，后面注释掉」。这个区别是本质性的。

Python 的 psycopg2、PHP 的 PDO、Node.js 的 mysql2、Go 的 database/sql，所有正经的数据库驱动都支持参数化。没有例外。如果你用的 ORM 框架，比如 MyBatis 用 #{ } 而不是 ${ }，Hibernate 用命名参数，底层走的也是这条路。

为什么转义函数不靠谱

很多人觉得用 mysql_real_escape_string() 转义一下就安全了。这个函数确实能处理大部分情况，但它依赖字符集设置。如果数据库连接字符集是 GBK，攻击者可以构造特定字节序列绕过转义，注入依然成立。更不用说有些开发者转义了字符串参数，却忘了数字参数——WHERE id = $id 这种写法，转义函数根本不生效。

参数化查询没有这个问题。它不靠「过滤坏字符」来防御，而是从协议层面把数据和指令隔离开。这是架构层面的安全，不是补丁层面的。

那些绕不开的边界情况

表名、列名、ORDER BY 后面的字段名，这些不能用参数化占位符。因为数据库在编译阶段就需要知道这些标识符是什么。遇到这种场景，只能用白名单校验——把允许的值写死在代码里，用户传进来的值必须精确匹配其中之一。比如排序字段只允许 created_at、updated_at、id 三个，其他一律拒绝。不要尝试用正则去过滤，白名单比黑名单可靠得多。

存储过程如果内部拼接了动态 SQL，同样会中招。参数化只保护调用层，不保护存储过程内部的字符串拼接。这一点经常被忽略。

写代码时的肌肉记忆

我现在审查代码，看到字符串拼接出现在 SQL 附近就会停下来。不管这个参数来自前端、来自内部服务调用、还是来自配置文件，只要它进入了 SQL 语句的拼接流程，就是隐患。有人觉得内部调用的参数可信，但内网横向移动、SSRF 这些攻击手法早就把「内网可信」这个假设打穿了。

养成习惯：写 SQL 的第一反应是找占位符，而不是找转义函数。ORM 里看到 ${ } 就改成 #{ }。原生 SQL 里看到 + 或 . 或 f-string 拼变量就改成参数绑定。这个习惯比任何安全扫描工具都管用。

数据库账号权限也要收窄。Web 应用连数据库的账号，不该有 DROP、FILE、INTO OUTFILE 这些权限。万一参数化出了纰漏，权限限制能兜住最后一道底线。但这只是纵深防御的一层，不能替代参数化本身。