由 dawei PHP开发者常误以为`mysql_real_escape_string()`或简单的引号转义就能挡住SQL注入，Ruby工程师审视PHP生态时发现：真正的防御必须分层构建，单点防护形同虚设。
AI图片，仅供参考
第一层是参数化查询（Prepared Statements）。使用PDO或MySQLi时，明确分离SQL结构与数据，如`$stmt = $pdo->prepare(\”SELECT FROM users WHERE id = ?\”)`；变量仅以占位符传入，数据库引擎天然拒绝执行意外交叉的指令。这层切断了95%以上的注入路径，是不可绕过的基石。
第二层是输入验证与类型强制。即便走参数化流程，也要在业务逻辑入口校验数据格式——邮箱用filter_var过滤，ID强转为整型`(int)$id`，字符串长度限制并剔除控制字符。Ruby习惯中强调“信任边界外无净土”，PHP同样需在controller层就扼杀异常输入，而非寄望于后续层层补救。
第三层是权限最小化与运行时监控。数据库账号仅授予必要表的CRUD权限，禁用`SELECT INTO OUTFILE`等高危操作；同时部署SQL审计中间件（如ProxySQL日志分析）或启用PDO的`PDO::ATTR_EMULATE_PREPARES = false`，防止预处理被错误回退至模拟模式而失效。一次看似正常的`’1 OR 1=1’`若出现在日志高频告警中，即刻触发人工响应。
三者缺一不可：参数化防构造，验证防滥入，权限与监控防兜底失效。曾有项目因关闭PDO模拟预处理却未同步检查驱动兼容性，导致旧代码悄悄退化为拼接式查询——防御链一旦断裂，攻击者只需找到最薄弱的环节。安全不是功能开关，而是贯穿数据流转每一步的契约。