CSDN 文章编辑界面文本批量替换技巧

场景：以前写的 CSDN 文章有一些固定的变量名称，现在想统一替换成其他的文本。

解决方法

首先编辑所需要修改文章，然后开启 F12 开发者工具控制台
点击选择元素按钮，选择文本编辑区域
在控制台输入如下代码
- ceshi：代表文章中需要被替换的文字
- mio：替换成的文字

$('body').innerHTML = $('body').innerHTML.replace(/ceshi/g, 'mio');

待上述命令执行后，全选编辑区域，剪切，再粘贴
最后保存发布即可

这段代码的原理

拆开看这一行做了什么：

$('body').innerHTML = $('body').innerHTML.replace(/ceshi/g, 'mio');

$ 在 DevTools 控制台里是 document.querySelector 的别名，不是 jQuery。这是 Chrome DevTools 提供的便利函数（Console Utilities API），所以哪怕页面没引入 jQuery 也能用。对应地 $ 是 querySelectorAll 的别名，返回真数组而不是 NodeList。

顺带说一个更关键的便利变量：$0 代表 Elements 面板里当前选中的那个元素。正文第二步说的「点击选择元素按钮，选择文本编辑区域」，目的就是让那个编辑区变成 $0。所以更精确的写法应该是操作 $0 而不是 body：

$0.innerHTML = $0.innerHTML.replace(/ceshi/g, 'mio');

这个区别很重要。改 body 会把整个页面的 HTML 重写一遍——包括工具栏、侧边栏、CSDN 自己的脚本挂载点。副作用是页面上所有已绑定的事件监听器全部失效（因为 innerHTML 赋值会销毁并重建所有 DOM 节点），工具栏的按钮点了没反应。这也解释了正文为什么要「全选、剪切、再粘贴」——那是在用一次真实的用户输入操作，让编辑器重新捕获内容并触发它自己的 change 事件，把改过的内容同步进编辑器的内部状态。

只改 $0 的话破坏范围小得多，但同样会重建那个编辑区的节点，所以「剪切再粘贴」这一步依然需要。

/ceshi/g 是正则字面量，g 是全局标志。不加 g 只替换第一个匹配。这里用正则而不是字符串的原因就是要 g——replace 的第一个参数如果是字符串，只替换第一处。

这个方法的风险

因为它操作的是 innerHTML（HTML 源码），而不是文本内容，所以替换的目标字符串会同时匹配到 HTML 标签、属性、类名里的内容。举个会出问题的例子：

假设你想把文章里的 img 这个词替换成 图片，执行之后：

<!-- 替换前 -->
<img src="a.png" />
<!-- 替换后：标签名被改了，图片全坏 -->
<图片 src="a.png" />

同理，如果替换目标是 div、class、href、span 这类和 HTML 语法重叠的词，或者恰好出现在某个类名里（CSDN 的类名里有各种英文单词），页面结构会被破坏。

更隐蔽的一种：替换目标出现在图片的 URL 里。CSDN 的图片链接是带哈希的长串，里面可能包含任意字母组合，替换之后图片链接失效，文章保存后图片全挂。

安全的做法是只替换文本节点，不动标签。用 TreeWalker 遍历文本节点：

function replaceTextOnly(root, pattern, replacement) {
  const walker = document.createTreeWalker(root, NodeFilter.SHOW_TEXT);
  let count = 0;
  const nodes = [];
  // 先收集，因为遍历时修改 DOM 可能影响 walker
  while (walker.nextNode()) nodes.push(walker.currentNode);

  nodes.forEach(node => {
    const newText = node.nodeValue.replace(pattern, replacement);
    if (newText !== node.nodeValue) {
      node.nodeValue = newText;
      count++;
    }
  });
  return count;
}

// 用法：只改选中元素里的文本
console.log('替换了 ' + replaceTextOnly($0, /ceshi/g, 'mio') + ' 处');

这个版本只改文本节点的 nodeValue，标签、属性、URL 一概不碰，而且不重建 DOM，所以已绑定的事件监听器都还在，编辑器的状态也不会乱。理论上连「剪切再粘贴」都可以省掉——但富文本编辑器通常有自己的内部数据模型（不完全依赖 DOM），所以还是需要触发一次它认可的变更事件。可以试试直接派发 input 事件：

$0.dispatchEvent(new Event('input', { bubbles: true }));

如果编辑器监听的是 input 事件，这一行就够了，不用剪切粘贴。不同编辑器实现不同，试一下就知道。

执行前一定要先看匹配结果

这是我认为最该加的一步：替换之前先数一下会命中多少处，数量不对说明模式写宽了。

// 只统计，不修改
const html = $0.innerHTML;
const matches = html.match(/ceshi/g);
console.log('命中：' + (matches ? matches.length : 0) + ' 处');
console.log(matches);

想看命中的上下文（判断有没有误伤标签）：

// 打印每个匹配处前后各 30 个字符
const re = /ceshi/g;
let m;
while ((m = re.exec($0.innerHTML)) !== null) {
  const start = Math.max(0, m.index - 30);
  console.log(
    '...' + $0.innerHTML.slice(start, m.index + m[0].length + 30) + '...',
  );
}

看一遍上下文，确认每一处都在正文文本里而不是在标签或 URL 里，再执行替换。这一步花十秒钟，能避免把文章改坏之后手动一处处修回来。

更保险的操作顺序

综合下来我建议这么走：

先备份。在编辑器里全选内容复制，粘到本地的文本文件里存一份。CSDN 的历史版本功能不一定靠得住，自己存一份最稳。
切到 Markdown 编辑器。如果文章能切成 Markdown（另一篇文章讲了怎么切），那就根本不需要操作 DOM——Markdown 编辑器里的内容就是纯文本，直接在文本框里用编辑器自带的查找替换，或者拷到本地编辑器里改完再贴回去。这是最省事也最不容易出错的路径。
富文本编辑器才用 DOM 方案，且用上面的 TreeWalker 版本。
改完先预览再保存。CSDN 的预览能看出图片有没有挂、格式有没有乱。
保存后刷新页面确认。有时候编辑器里看着对，保存后的实际内容不对（因为编辑器的内部模型没同步）。

解决方法

这段代码的原理

这个方法的风险

执行前一定要先看匹配结果

更保险的操作顺序

相关：批量处理多篇文章