WordPress 7.2 默认关闭 NO_BACKSLASH_ESCAPES：反斜杠转义、会踩的坑与 db.php 兜底

结论先说：WordPress 7.2 把 NO_BACKSLASH_ESCAPES 正式列入「 WordPress 不支持的 SQL 模式」，并在每次连接数据库时把它从会话里剔除。对绝大多数站点，升级后什么都不会变；真正受影响的是两类人：被主机商强行打开过这个模式的站点（它们此前一直在悄悄出数据错误），以及依赖反斜杠字面量的插件或自定义查询（它们必须改用绑定参数或改写 SQL）。本文讲清三件事：这个模式到底改了什么行为、你现在的环境是不是踩在上面、以及万一真的需要它该怎么兜底。

一、这次核心改了什么

改动本身只有几行逻辑。 WordPress 连上数据库后会执行一次「设置会话 SQL 模式」的动作，把一堆它不支持的模式从会话里去掉。此前名单里已有 STRICT_ALL_TABLES、TRADITIONAL、ANSI，7.2 起新增 NO_BACKSLASH_ESCAPES。

关键点在于 作用范围：

• 只改 WordPress 这一条连接的会话变量，不碰服务器的全局设置；
• 不写配置文件、不需要重启 MySQL；
• 其他程序（同一台机器上的别的站点、报表工具、命令行客户端）完全不受影响。

这种「只收缩自己那条连接」的做法值得学。数据库是共享资源，WordPress 作为租户之一，正确姿态是调整自己的会话约定，而不是替所有人改服务器参数。想了解 7.2 的整体节奏，可以对照7.2 路线图和发布派对日程一起看。

二、为什么一个转义约定值得单独发开发通告

因为反斜杠在 MySQL 里承担了「转义字符」的角色，而 WordPress 的数据库层大量依赖这个约定。举个最小例子：

-- 默认模式（反斜杠是转义符）
SELECT 'It\'s here';
-- 返回: It's here

-- 打开 NO_BACKSLASH_ESCAPES 后（反斜杠是普通字符）
SELECT 'It\'s here';
-- 语法错误，或者按字面量截断，返回值里多出一个反斜杠

WordPress 的 wpdb::prepare()、esc_sql() 以及大量手写查询，都会在字符串里插入反斜杠来做转义。一旦服务端把这个约定换掉，同一句 SQL 的语义就变了：轻则查不到数据（比如带引号的标题搜不出来），重则写进库里的值多出反斜杠（下次读出来变成 It\'s），最坏情况是转义失效导致的注入面扩大。

这类问题的棘手之处在于它不报错。站点照常打开，只是某些带特殊字符的内容莫名其妙不对——而这恰恰是最难归因的一类故障。官方在通告里也点明了动机：有些主机或服务器环境会把这个模式打开，此前的站点会在这些机器上遇到「很难定位的数据库问题」。换句话说，这次改动不是新增能力，而是把一类长期潜伏的环境差异收敛到核心层统一处理。

三、先确认你踩没踩上

在站点的数据库里执行：

SHOW VARIABLES LIKE 'sql_mode';

看返回的逗号分隔串里有没有 NO_BACKSLASH_ESCAPES。也可以用一条不依赖任何表的语句直接验证转义行为：

SELECT 'a\'b' AS literal_test;

• 返回 a'b → 反斜杠被当作转义符（正常，WordPress 期望的行为）；
• 报语法错误，或返回里保留了反斜杠 → 这个模式是开着的。

再验一次「实际数据有没有被污染」。下面这条查的是最容易出问题的地方——标题与正文里带单引号、双引号或反斜杠的内容：

SELECT ID, post_title
FROM wp_posts
WHERE post_status = 'publish'
  AND (post_title LIKE '%\\\\%' OR post_title LIKE '%\\\'%')
LIMIT 20;

如果结果里出现明显多出来的反斜杠（例如标题显示成 It\'s），说明历史上的写入已经受环境影响，升级后需要一次数据清理，而不只是改配置。

四、谁真的会受影响

值得注意的是第四行。这个模式本身不是「坏东西」——它的设计初衷是让反斜杠回归普通字符，符合部分团队的安全规范。问题在于它与 WordPress 核心的假设冲突。当平台默认值和应用的假设打架时，代价总是落在最终用户身上（表现为「换个主机就好了」这类玄学）。 7.2 把这件事收进核心，实际上是在替用户兜底。

五、万一你的站确实需要这个模式

官方给了出口：用已有的 incompatible_sql_modes 过滤器，把这一项从「要剔除的名单」里拿掉。

<?php
// wp-content/db.php
add_filter( 'incompatible_sql_modes', function ( $modes ) {
    return array_diff( $modes, array( 'NO_BACKSLASH_ESCAPES' ) );
} );

这里有一个必须注意的加载顺序问题：WordPress 在插件加载之前就已经连上数据库了，所以这段代码写在普通插件里、甚至写在 must-use 插件里都太晚——那时连接已经建立、模式已经被清掉。唯一有效的落点是 wp-content/db.php 这个 drop-in 。它和对象缓存的 object-cache.php 是同一套机制：核心在启动早期主动探测并加载这些文件。对象缓存 drop-in 的完整写法和坑，我在对象缓存与 Redis 持久化那篇里拆过，思路可以互相参照。

六、插件作者的落地检查清单

如果你维护着带自定义查询的插件，按这个顺序过一遍，成本很低：

七、这件事的方法论价值

把它当成一个普遍模式看，比记住这个模式名更有用：应用的隐含假设，迟早要变成显式约束。 WordPress 靠反斜杠转义跑了很多年，这个假设一直藏在 wpdb 的实现里，从没写进文档；直到环境差异让它偶尔失效，核心才不得不把它固化成「连接时主动修正会话」。同类事情在别处也在发生——字符集、时区、STRICT 模式、ONLY_FULL_GROUP_BY，每一次都是同一个剧本。

对自建站的启示：如果你的项目里也有「一直这么跑所以应该没问题」的假设（比如某个目录一定可写、某个扩展一定装了、某个编码一定是 UTF-8），在升级前把它写成一次启动自检，而不是等它变成线上事故。这也是我在服务器迁移流程里坚持要跑「只读灰度 + 回滚」的原因：可验证的假设才叫假设，不可验证的叫赌博。

查看 Trac #66185 原始工单常见问题