把用户输入直接拼进SQL语句，防范等于把家门钥匙复制一份交给陌生人。入攻十年前的击最撞库事件，八成以上都有SQL注入的有效影子。攻击者往输入框里塞一段`' OR '1'='1`，手段数据库就乖乖把整张用户表吐出来。防范这不是入攻黑客技术多高明，是击最开发者把数据库的信任门槛设得太低了——任何来自客户端的字符串都值得怀疑，这应该成为写代码的有效本能。

最有效的手段手段，听起来可能有点反直觉，防范不是入攻过滤，不是击最转义，而是有效参数化查询。原理不复杂：SQL语句的手段结构和参数分开传送，数据库先编译好语句结构，再把你给的数据当纯值处理。拿PHP的PDO举例，`$stmt = $pdo->prepare("SELECT * FROM users WHERE email = ?");`，那个问号占住位置，后面再绑定用户输入的邮箱。就算输入`' OR '1'='1`，数据库也只会把它当成一个普通的字符串去匹配email字段，语法结构早被锁死了，注入的代码根本没机会执行。Java的PreparedStatement、Python的sqlite3参数占位符，都是同一套逻辑。

光知道参数化还不够。我见过有人写存储过程时偷懒，在存储过程内部用字符串拼接，结果前端参数化做好了，后门却留着。存储过程内部的动态SQL同样要用`sp_executesql`配合参数，别图省事直接拼。另外，ORM框架也不是免死金牌——用原生查询方法或者写复杂条件时，照样有人把参数直接用`+`拼进查询串，框架的保护层被绕过去了，等于白穿防弹衣还露出要害。

第二个关键手段是数据库权限收窄。很多项目用数据库超级管理员账号连接应用，一旦注入成功，攻击者不只是拖库，还能`DROP TABLE`、写文件、提权。正确的做法是：应用账号只给`SELECT`、`INSERT`、`UPDATE`、`DELETE`权限，坚决不给`DDL`权限。如果业务只需要读某几张表，那就只授这几张表的读权限。权限越小，注入的破坏半径越小。这不是防注入本身，而是把爆炸范围控制在坑里，别让一颗手雷炸掉整个军火库。

还有一层容易被忽略的防线——输入校验。这不是让你去黑名单过滤关键字，而是白名单校验格式。比如用户ID必须是纯数字，邮箱必须匹配标准格式，日期必须符合`YYYY-MM-DD`。类型不对直接拒绝，连数据库都不用碰。注意，校验是辅助，不是替代。有人写了个正则过滤`union`、`select`就以为万事大吉，结果攻击者用注释符、十六进制编码轻松绕过。把校验当第一道哨兵，把参数化当最后一道铁闸，两层配合，才睡得着觉。

说个实在话，参数化查询这招已经存在二十年了，但每次代码审计还是能翻出几处拼接的写法。为什么?因为写起来快，因为有的老代码历史包袱重，因为团队里没人真正意识到后果的严重性。我见过某个支付系统，因为一处订单查询漏了参数化，被拖走几万条交易记录，公司赔了钱还上了新闻。技术本身不难，难的是每个写SQL的人都把这条规矩刻进肌肉记忆。

最后补一句，数据库防火墙和WAF这类外部工具能挡掉一部分扫描流量，但别指望它们兜底。攻击者只要多花点时间，总能找到绕过规则的方式。真正的安全边界，永远在代码里，在你写每一条SQL时多花的那五秒钟——把值绑进参数，而不是把字符串拼上去。这五秒钟，值回整个数据库的命。