一个分号，入漏或者一个单引号，入漏就能让数据库从“忠实仆人”变成“泄密狂魔”。入漏这事听起来像天方夜谭，入漏但我亲眼见过一个电商后台，入漏因为搜索框没过滤，入漏被人在URL后面塞了句' or 入漏1=1 -- ，结果整张用户表像摊开的入漏账本一样，赤裸裸地躺在页面上。入漏密码哈希、入漏手机号、入漏收货地址，入漏全没了。入漏

PHP注入的入漏根子，不在PHP本身，入漏而在写代码的人把用户输入当成了“自己人”。你让用户填个用户名，代码直接拼进SQL语句：$sql = "SELECT * FROM users WHERE name='$name'"。用户要是老老实实填“admin”，那没事。可要是填个admin'--，SQL就变成了SELECT * FROM users WHERE name='admin'--'，注释符把后面的引号全吞了。查询照样执行，返回的却是管理员权限。就这么简单，一个字符，权限就换了主人。

更狠的玩法是union select。攻击者先猜字段数，拿order by 10试错，报错就减数字，直到不报错为止。然后union拼接，把数据库里的表名、列名一点点掏出来。整个过程像开锁匠试钥匙，叮叮当当，但耐心十足。有些老系统连错误信息都不屏蔽，直接把SQL报错甩在浏览器上——那等于把锁芯结构图贴在大门上。

别以为框架能救命。ThinkPHP、Laravel的ORM确实做了参数绑定，但架不住有人图省事，直接DB::select("SELECT * FROM goods WHERE id=" . $_GET['id'])。框架提供了盾牌，你偏要扔了它去裸奔。我见过一个二次开发的项目，开发者把原生查询写在模型里，注释还写着“此处SQL已优化”——优化了个寂寞，注入点就在那行“优化”代码里。

修复手段其实不复杂。预编译语句是正路，PDO的prepare + bindParam，把数据和SQL语句彻底分开。数据库那边收到的是模板，参数走独立通道，再诡异的输入也只是字符串，变不成代码。实在老代码改不动，那就加个白名单过滤，数字就强制intval，字符串就转义特殊字符——但转义是权宜之计，防得了单引号，防不了宽字节注入。

说句实在话，这漏洞能在OWASP Top 10里躺了十几年，不是因为技术门槛高，而是因为开发者总觉得“没人会这么闲”。可现实是，扫描工具到处飞，自动化的注入探测脚本比苍蝇还勤快。你站点只要有那么一个参数没过滤，机器就能在几分钟内找到它，然后把你数据库拖走。你甚至不知道攻击者什么时候来的，就像你不知道自己的钥匙什么时候被配了一把。

写代码的时候多问自己一句：这个变量，用户能控制吗？能控制，就别直接往SQL里怼。这不是什么高深道理，纯粹是手懒一时，事后补窟窿补到哭。我见过一个程序员，因为线上注入被脱库，凌晨三点爬起来改代码，改完在群里发了句：“原来参数绑定这么简单，以前咋就没用呢。”——那语气，像极了后悔没早用安全套的愣头青。