MySQL服务端不返回详细错误信息的关键配置是log_error_verbosity=1（8.0.14+）或log_warnings=0（旧版本），配合应用层禁用错误透出（如mysqli_report(MYSQLI_REPORT_OFF)、PDO::ATTR_ERRMODE设为SILENT）及display_errors=Off，方可阻断敏感信息泄露。
MySQL服务端不返回详细错误信息的关键配置
MySQL本身不会主动“把表名、字段名塞进HTTP响应”，它只向客户端发送错误包；真正让敏感信息暴露在页面上的，是应用层把mysqli_error()或conn.error()直接echo出来。但服务端配置能堵住一条后路：避免错误细节写入日志并被运维误发、或被攻击者通过其他通道（如慢查询日志、general_log）间接获取。
MySQL 8.0.14+ 必须设 log_error_verbosity = 1（仅记录ERROR级别），旧版本可设 log_warnings = 0（注意该参数在8.0已废弃）。不要碰 sql_mode = STRICT_TRANS_TABLES——它和错误回显无关，只影响数据校验行为。
另外两个常见误区：
-
secure_file_priv控制的是文件读写权限，关不关它不影响错误信息泄露 -
show_errors不是MySQL配置项，属虚构参数，别在my.cnf里瞎加
PHP中彻底禁用MySQLi/PDO错误透出的实操设置
光改MySQL配置没用。PHP驱动默认可能把完整SQL和错误堆栈一起抛出，尤其老项目常手动开启严格模式。
MySQLi必须关闭报告开关：mysqli_report(MYSQLI_REPORT_OFF) —— 这是最干净的做法
或至少降级为 MYSQLI_REPORT_ERROR（报错但不带SQL语句）
绝不能用 MYSQLI_REPORT_STRICT，它会让每个警告都变异常并附原始SQL。
PDO则要禁用异常模式：$pdo->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_SILENT)
或 PDO::ERRMODE_WARNING（写日志但不抛出）
同时确认 display_errors = Off 在php.ini中生效，否则即使PDO静默，PHP自身仍会把Warning打到HTML里。
为什么预处理语句不能代替错误屏蔽
参数化查询（prepare+bind_param）解决的是SQL注入的“执行”问题，但挡不住报错注入的“触发”逻辑。比如你写了：$stmt = $pdo->prepare("SELECT * FROM users WHERE id = ? AND updatexml(1, concat(0x7e, user()), 1)");
只要用户输入的id值能拼进这个SQL模板（哪怕用了?），且数据库开启了错误回显，updatexml就会照常报错并吐出user()结果。
所以防御链必须完整：
解析 MySQL 8.0 的 DDL 脚本，并将表结构导出为 Excel 格式。适用于用户需将 MySQL 的 `CREATE TABLE` 语句转换为结构化的 Excel 文件场景，导出内容包含字段名、数据类型、长度及精度等信息。支持多张表的批量处理，每张表对应 Excel 中的一个独立工作表。适用于数据库文档编写、数据字典生成及模式分析等任务。
- 输入进SQL前，先做类型校验（如
ctype_digit()判断ID是否纯数字） - SQL执行必须包裹
try/catch，捕获后只返回通用提示 - 数据库用户权限最小化，删掉
information_schema的SELECT权限
验证是否真关掉了错误回显的快速检测法
上线前用最简方式验证：在任意输入框提交单引号 '，观察返回内容。
安全的表现是：
- 页面无任何MySQL字样（如“Unknown column”、“Access denied”、“You have an error in your SQL syntax”）
- HTTP状态码仍是200（不是500），且响应体里只有“操作失败”“请求异常”之类泛化文案
- 查看浏览器开发者工具的Network面板，Response中不含SQL片段、表名、字段名、路径
如果其中任一条件不满足，说明某一层（PHP配置、驱动设置、自定义异常处理器、前端JS兜底）还开着口子。最容易被忽略的是框架自带的debug页面——Laravel的APP_DEBUG=true、Django的DEBUG=True、Flask的debug=True，这些在生产环境必须为false。
