一个朋友去年做了个电商站，防注上线第三天就被脱裤了。入网黑客只用了最简单的防注SQL注入，在搜索框里敲了句 `' OR '1'='1`，入网就把整个用户表导走了。防注那天晚上他给我打电话，入网声音都在发抖——五千多个注册用户的防注手机号、地址、入网订单记录全没了。防注事后查日志，入网攻击者连扫描器都没用，防注纯手工试了两下就进去了。入网 问题出在哪？防注他的后台登录接口直接把用户输入拼进了SQL语句。`SELECT * FROM admin WHERE username='$name' AND password='$pass'`——就这么裸奔了十年。入网现在很多教程还在教用字符串拼接写查询，防注简直是给黑客递刀。 防注入的核心就一条：**永远别信任用户输入**。但这句话太虚，具体到代码层面，分三层。 第一层是参数化查询。拿PHP的PDO举例，写成 `$stmt = $pdo->prepare("SELECT * FROM users WHERE email = ?"); $stmt->execute([$_POST['email']]);`。数据库驱动会把参数当纯数据对待，而不是可执行代码。这招能挡住99%的注入尝试，成本几乎为零。Java的PreparedStatement、Python的sqlite3参数占位符，原理都一样。说白了就是告诉数据库：“这段是查询逻辑，那段是用户给的字符串，别混在一起”。 第二层是输入校验。别只依赖参数化，因为有些场景绕不开拼接——比如动态表名、排序字段。这时就得白名单校验：表名写死在数组里，排序只允许 `ASC` 或 `DESC`，其他值直接拒绝。我见过最蠢的写法是拿正则过滤 `'` 和 `"`，结果黑客用 `/**/` 注释符就绕过去了。过滤黑名单永远是下策，因为攻击手法迭代太快，你堵不完。 第三层是权限最小化。给数据库连接账号只开必要的权限——查询账号就别给DROP、UPDATE权限，哪怕注入成功了，他也只能读不能写。很多小站图省事，直接用root连库，等于把保险柜钥匙挂在门口。我那个朋友后来重建系统，专门建了个只读账号给前台页面用，后台管理单独走另一个IP白名单的接口。 还有个细节容易被忽略：错误信息。开发时开着 `display_errors` 方便调试，上线后忘了关。黑客故意输入语法错误，页面直接爆出完整SQL语句和表结构。正确做法是生产环境把错误写日志，用户那边只显示“系统繁忙”。 说到底，防注入不是某个神奇框架或工具能解决的，得从编码习惯上改。每次写SQL前问自己一句：这里能参数化吗？不能的话，白名单校验做了吗？账号权限缩到最小了吗？三连问下来，基本就稳了。我见过太多团队花大价钱买WAF，结果自家代码里全是洞——WAF只是创可贴，伤口不缝针，血照样流。