写出能在 DOM 变化中存活的 JS 规则
你写了一条规则，它工作了一周，今天停了。页面没坏 —— 它只是把一个类名从 .btn-primary 改成了 .Button_primary_x7f3。下面是如何写出能在这类变化中存活的规则。
规则为什么会坏
一条规则攀附在一个你控制不了的页面的 DOM 上。每次改版、每次带新类名哈希的构建、每次 A/B 测试都可能让你脚下的地动起来。你消灭不了它 —— 但你能限制它。
法则 1 —— 瞄准稳定的东西
选择器从最持久到最不持久：
- 最好：语义属性 ——
[aria-label]、[role]、[name]、[type]、[data-testid]。它们很少变，因为它们承载意义。 - 不错：标签及其结构 ——
nav a、main > article。 - 有风险：人类可读的类名 ——
.sidebar、.cookie-banner。 - 最差：带哈希的类名 ——
.css-1a2b3c、.jsx-987。在构建时生成，每次部署都变。
法则 2 —— 类名失效时用文本瞄准
对用户可见的文本变化得比 CSS 类名少。与其按类名捕获一个按钮，不如按内容找到它：
const btn = [...document.querySelectorAll('button')]
.find(b => /保存|提交|save|submit/i.test(b.textContent || ''));法则 3 —— 总是检查元素是否存在
一条假定某个元素存在的规则会在它缺失的那天爆掉 —— 而且常常会把它自己其余的代码一起害死。防御性地写：
const el = document.querySelector('.target');
if (el) {
// 在这里干活
}?. 运算符简洁地做到这点：document.querySelector('.target')?.remove() 在元素缺失时什么都不做 —— 而不是抛一个错误。
法则 4 —— 让规则在迷失时喊出来
最糟的故障是无声的 —— 规则不工作而你不知道为什么。加一个信号：
const el = document.querySelector('.target');
if (!el) JUSTZIX.warn('规则 X: 未找到 .target —— 页面变了？');Output Console 里的一条记录立刻告诉你该修选择器了 —— 而不是靠猜。
另见
- 规则里的 MutationObserver —— 对随时间发生的变化的韧性
- 把 Output Console 当日志器 —— 规则信号落地的地方
- URL 模式 —— 韧性从匹配开始
安装 JustZix —— 写出不会在页面下次部署时崩坏的规则。
为这篇文章评分
暂无评分 — 成为第一个。