php防sql注入代码

凌晨两点，入代我盯着屏幕上那条报错的入代SQL语句，后背发凉。入代一个刚上线的入代搜索功能，用户输入了个单引号，入代整个订单表的入代数据差点被拖走。这不是入代危言耸听，SQL注入就是入代这么简单粗暴——你以为是普通文本，数据库却把它当成了代码执行。入代

PHP开发者最常用的入代防御手段，就是入代`mysqli_real_escape_string()`。这函数会把单引号、入代双引号、入代反斜杠这些危险字符前面加上转义符，入代让数据库不再把它们当作语法结构。入代但说实话，这招现在有点过时了。为什么？因为你得记得在每个输入点都调用它，人总会犯错，漏掉一个就是灾难。

真正靠谱的，是预处理语句（Prepared Statements）。拿PDO举例：

 $stmt = $pdo->prepare("SELECT * FROM users WHERE email = ?"); $stmt->execute([$_POST['email']]); 

看到没有？问号占位符把SQL结构和数据彻底分开。数据库先编译好语句结构，再把参数当纯文本传进去。就算用户输入`' OR 1=1 --`，也只是一串没意义的字符，永远成不了代码。这就像先把信封写好地址，再往里面塞信纸——信纸内容再乱，也改变不了收件人。

有一次我帮朋友排查他公司的老项目，整站全是字符串拼接SQL。几百个文件，每个查询都要手动转义。我问他为什么不用预处理，他苦笑说"历史包袱太重"。后来我们花了两个通宵，把所有查询改成了PDO绑定参数，上线后安全扫描直接清零告警。代价是有的，但比起被拖库后赔客户的钱，这点工时真不算什么。

还有个细节很多人忽略：数据库账号的权限。很多项目用root连接数据库，一旦注入成功，攻击者能删库、改表、读文件。正确的做法是给PHP应用单独建个账号，只授予SELECT、INSERT、UPDATE、DELETE权限，连DROP都别给。这样即使被注入，损失也有限——攻击者最多操作业务数据，碰不了系统表。

再有就是输入过滤。别依赖`$_POST`里的数据，先判断类型。比如年龄字段，用`filter_var($input, FILTER_VALIDATE_INT)`强制转成整数；邮箱用`FILTER_VALIDATE_EMAIL`校验格式。这些内置过滤器比你自己写正则靠谱得多，而且代码更短。

我见过最离谱的案例，是某开发把用户输入直接拼进`LIKE`子句，还用了`%`通配符。结果攻击者传个`%`进去，把整张表的数据全查出来了。你说他冤不冤？其实只要把`%`和`_`也转义掉，或者干脆用预处理，根本不会出这种事。

最后提个建议：写个简单的数据库封装类，统一处理所有查询。别让项目里到处散落裸的`mysqli_query()`。哪怕只是包一层函数，也能让你在需要加日志、加过滤时有个集中修改的地方。代码整洁是小事，安全可控才是大事。

SQL注入不是玄学，是工程习惯问题。用预处理语句，限制数据库权限，过滤输入类型——这三板斧砍下去，九成以上的注入漏洞都能堵死。剩下的，就靠你写代码时多留个心眼儿了。