应关闭生产环境错误显示，统一捕获数据库异常并记录日志，禁用原始错误输出；使用bindValue绑定固定值，bindParam需确保变量生命周期稳定；错误提示须白名单控制，防止二次注入。
SQL注入报错时，error_log 里出现 MySQL server has gone away 或 Unknown column 'xxx' in 'where clause' 怎么办
这类报错不是真正的“SQL注入成功”，而是攻击者输入了非法 SQL 片段，触发了数据库语法解析失败或连接中断。你看到的错误信息本身已暴露后端技术栈，且默认错误页可能泄露表名、字段名甚至完整查询逻辑——这比注入本身更危险。
实操建议：
- 绝不在生产环境开启
display_errors = On或show_sql_errors = true（具体配置项依框架而定） - 用
try...catch捕获PDOException/mysqli_sql_exception，统一返回HTTP 500并记录日志，不透出任何数据库细节 - 检查 Web 服务器是否把原始错误写入
error_log：Apache 的ErrorLog、Nginx 的error_log配置需设为warn或更高，避免debug级别输出
用 prepared statement 防注入，但参数绑定后仍报错：为什么 bindValue 和 bindParam 行为不同
绑定方式选错会导致参数未生效、类型强制失败或变量生命周期异常，进而让预编译失效，退化成拼接式查询。
常见错误现象：
-
bindValue传入变量引用但变量后续被修改 → 绑定值不变（安全，推荐） -
bindParam传入变量引用，执行前变量被 unset 或重赋值 → 绑定值为空或意外值（危险，易踩坑） - 对
WHERE id = ?使用bindValue(null, PDO::PARAM_INT)→ 实际发给数据库的是WHERE id = NULL，而非IS NULL，逻辑错位
使用场景差异：
- 固定值、字符串/数字字面量 → 用
bindValue - 需在循环中复用同一语句并更新变量值（如批量插入）→ 可用
bindParam，但必须确保变量作用域稳定 - 判断字段是否为 NULL → 显式写
WHERE status IS ?并绑定'NULL'字符串，或拆成两个分支处理
自定义错误处理不能只靠 set_error_handler：它捕获不到 PDO 报错
set_error_handler 只捕获 PHP 警告、通知类错误（E_WARNING、E_NOTICE），而 SQL 执行失败属于异常（Exception），必须用异常机制拦截。
实操建议：
- 全局开启
PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION，否则execute()失败只返回 false，无法进 catch - 不要在 DAO 层裸 throw 新异常（如
throw new Exception("DB failed")），会丢失原始getCode()和getSQLState()，应直接 re-throw 或包装时保留原异常作为$previous - 日志中记录
$e->getSQLState()（如45000是自定义异常，23000是约束冲突），比错误消息更稳定、更适合自动化分类
报错页面显示 “操作失败，请联系管理员” 就够了吗？还要防二次注入
用户看到的友好提示本身如果拼接了攻击输入（比如 “用户 admin'; DROP TABLE users-- 不存在”），就构成二次 SQL 注入或 XSS —— 错误消息也是数据输出点。
关键控制点：
- 所有返回给前端的错误文案必须来自白名单常量，禁止拼接原始请求参数（包括
$_GET['id']、$_POST['email']） - 若需透出部分上下文（如“邮箱 xxx 格式不正确”），先对变量做
filter_var($input, FILTER_SANITIZE_EMAIL)或正则白名单过滤，再插入选定文案模板 - 前端展示的错误信息，服务端响应字段名应为
message而非error，避免某些旧版前端库自动执行eval(error)类逻辑
最麻烦的点往往藏在日志脱敏和错误码映射里：同一个 SQL 异常，在 MySQL 5.7 和 8.0 中 getCode() 可能不同，而应用层按 code 做路由时容易漏掉版本差异。
