上周三凌晨两点，网页替换我蹲在路由器旁边刷新一个二手交易平台，网页替换想抢一台老式胶片扫描仪。网页替换页面加载到一半突然卡住，网页替换进度条像被冻住的网页替换鼻涕虫。我以为是网页替换网速问题，重启了三次路由器，网页替换甚至把手机热点打开对比——结果一样。网页替换后来用开发者工具一看，网页替换好家伙，网页替换那个“立即购买”按钮的网页替换点击事件被绑在了一个根本不存在的DOM节点上。换句话说，网页替换这个按钮是网页替换画上去的，不是网页替换真的。

这就是网页替换网页替换最粗暴的一种形态：你看到的界面和背后运行的逻辑，早就不是一回事了。

不是换皮，是换骨

很多人把网页替换理解成改改CSS、换张banner图。差得远。真正的替换发生在结构层——HTML节点被动态重写，事件监听器重新绑定，甚至整个DOM树在你不注意的时候被整体替换掉。你盯着屏幕看，觉得“页面没动啊”，实际上底下已经换了一副骨架。

我见过一个电商大促的案例。运营要求把“加入购物车”按钮在特定时段换成“立即抢购”，文案变了，颜色变了，位置没动。前端用了一个叫replaceChild的方法，把原来的元素整个替换成新的。问题是，旧的按钮上绑着三个埋点事件和一个库存校验逻辑。新按钮只复制了样式和文案，事件没跟过来。结果那半小时里，所有点击“立即抢购”的用户，都只是看了一场动画——按钮抖了一下，购物车纹丝不动。

这种替换的隐蔽性在于，视觉上完全无感。用户不会知道DOM变了，他们只会觉得“这网站又抽风了”。

替换的动机，往往不体面

正常的网页替换应该发生在框架层面。React的虚拟DOM diff、Vue的patch，都是可控的、有预期的替换。但现实里更多的替换是“打补丁”——某个老系统改不动了，就在外面套一层iframe，或者用JS把某个区域的内容整个innerHTML重写。

我见过最离谱的一个：某政务网站，查询结果页的表格是后端渲染的。后来要求加一个“导出Excel”按钮，开发懒得改后端模板，直接用JS在页面加载后把整个表格区域替换成一个Vue组件。问题是，那个Vue组件挂载的时候，原始表格已经被销毁了，而导出功能依赖原始表格里的一个隐藏字段。于是每次导出，Excel里都少一列数据。

这种替换的本质是欺骗。欺骗浏览器，欺骗用户，也欺骗后来的维护者。你打开开发者工具，看到的DOM结构和源代码完全对不上，像走进一个被重新装修过的房间，墙纸下面还是旧墙皮。

怎么判断你遇到了替换

有个很简单的办法：打开控制台，输入document.body.innerHTML.length，记下数字，然后触发一次页面交互（比如点个按钮、切个标签页），再输一次。如果数字变化超过30%，大概率发生了大规模DOM替换。另一个信号是事件失效——你明明看到按钮在那儿，点击没反应，或者反应的是上一个版本的行为。

我自己的习惯是，遇到可疑页面就先禁用JavaScript再刷新。如果页面变成一片空白或者只剩骨架，说明核心内容全靠JS替换生成。这时候再去看网络请求，往往能发现一个返回HTML片段的接口，那个片段就是替换的“原材料”。

网页替换本身不是坏事。现代前端框架每天都在做替换，只是做得干净、可预测。坏就坏在，有人把它当成创可贴，哪儿破了贴哪儿，贴完还不告诉别人。最后页面变成一层叠一层的替换产物，像地质层一样，每一层都记录着一次偷懒。

凌晨三点，我终于放弃了那台扫描仪。关掉页面之前，我最后看了一眼那个“立即购买”按钮——它还在那儿，安静地、虚假地亮着。