phpMyAdmin 会自动调用 SQL 格式化 API 是因前端 sql-formatter.js 在本地格式化失败时默认回退至 https://sqlformat.org/api/v1/format 远程服务，该行为不可仅通过 PHP 配置关闭，需在 JS 层显式禁用 fallback。
为什么 phpMyAdmin 会自动调用 SQL 格式化 API
phpmyadmin 默认启用 sql-formatter（基于 sql-formatter.js 的前端格式化），但部分版本（尤其是 5.2+）在编辑 sql 时会向 https://sqlformat.org/api/v1/format 发起 post 请求——这是它内置的「远程格式化服务」，用于处理超长或复杂语句。这个行为不经过用户确认，且请求体含原始 sql，存在敏感语句外泄风险。
这不是 bug，是默认启用的「功能回退机制」：当本地格式化失败（比如语法太新、含特殊注释）时，自动 fallback 到线上服务。
- 常见错误现象：
Failed to fetch控制台报错但不影响使用；抓包看到向sqlformat.org的 POST 请求；SQL 编辑框卡顿半秒后才格式化完成 - 使用场景：DBA 或开发在内网部署 phpMyAdmin，审计要求禁止任何外联；或处理含客户数据、密钥、路径等不可出域的 SQL
- 关键点：该行为由前端 JS 控制，**服务端配置无法直接关闭**，必须修改前端逻辑或覆盖配置
关闭远程格式化：改 config.inc.php + 禁用 JS 回退
phpMyAdmin 5.2.0+ 引入了 $cfg['SQLFormat']['enable'] 和 $cfg['SQLFormat']['method'] 配置项，但仅控制是否启用格式化功能本身，**不阻止远程 fallback**。真正生效的是前端的 sqlFormatterOptions 全局对象。
- 在
config.inc.php中添加以下两行（位置任意，建议放在$cfg['Servers']块之后）：
$cfg['SQLFormat']['enable'] = false; $cfg['SQLFormat']['method'] = 'none';
./js/vendor/sqlformatter/ 目录下找到 sql-formatter.min.js，搜索 https://sqlformat.org，将其替换为 about:blank 或直接删掉整个 fallback 请求逻辑块（约 3 行 fetch 调用）./templates/header.twig 或自定义 footer.inc.php 中注入覆盖脚本：<script>
window.sqlFormatterOptions = {
method: 'none',
fallback: false
};
</script>
验证是否真正断开外联
改完别急着信配置，实际验证比写注释重要得多。
- 打开浏览器开发者工具 → Network 标签页 → Filter 输入
sqlformat→ 在 SQL 编辑框里随便输点东西再按 Ctrl+Shift+F（格式化快捷键） - 如果仍有请求发出，说明 JS 覆盖未生效，检查脚本加载顺序：你的自定义
<script>必须在 phpMyAdmin 自身的sql-formatter.min.js之后执行 - 注意缓存：浏览器可能缓存旧 JS，强制刷新（Ctrl+F5）并清空
./js/vendor/sqlformatter/对应文件的本地缓存 - 兼容性提醒：phpMyAdmin 5.1 及更早版本没有
$cfg['SQLFormat']配置项，只能靠 JS 层 patch，且需手动替换sql-formatter.js版本（推荐锁定 v3.4.0，已移除远程调用）
替代方案：用本地格式化引擎（可选）
如果团队坚持要格式化功能但拒绝外联，可以引入轻量本地方案，不过得接受一定妥协。
立即学习“PHP免费学习笔记（深入）”；
- phpMyAdmin 本身不自带完整本地 SQL 解析器，但支持通过
sql-formatter的standalone模式运行：下载最新版sql-formatter（v4+），构建为单文件sql-formatter-standalone.min.js，替换原vendor下的文件 - 性能影响：本地格式化对超长 SQL（>10KB）响应略慢，但无网络延迟；移动端 Safari 可能因 JS 引擎限制导致卡顿
- 参数差异：
standalone模式不支持某些冷门方言（如 BigQuery 的QUALIFY），遇到解析失败会静默退回到原始文本，不会报错也不会外发 - 别忘了同步更新
config.inc.php中的路径引用，否则 phpMyAdmin 仍会加载旧版
最核心的一点：远程格式化不是开关式配置，而是前端 fallback 链路，任何只改 PHP 配置的尝试都会漏掉真实调用点。盯住 Network 面板里的请求，才是唯一可信的判断依据。
