CLS 自动化归因及自愈：让系统自己定位根因、修复并验证
你点"购买"按钮，按钮突然窜走，你点空了------这就是 CLS（布局偏移）。工具给你网页一个 CLS 分数，但分数只告诉你"跳了"，不告诉你谁在跳、为什么跳、怎么修、修了怎么确认。分数只是起点，真正的活在分数之后。
这篇讲的是 CLS 自动化归因及自愈：让系统自己完成分数之后的全部工作------留好证据、自动定位根因（归因）、趁早修复并统计验证（自愈）、防止再犯。不靠人猜，不靠"感觉好了"，全程基于浏览器原生能力，确定且可复现。
下面用三种方式讲同一件事：先看一张图理解全流程，再用文字讲清每一步"为什么这么设计"，最后看代码实现。 图、文字、代码讲的是同一件事，任选一种都能懂。
全流程：系统怎么自动搞定 CLS
光看这张图就能明白系统在干什么（每个框是大白话，箭头标着传给下一步什么）：
objectivec
网页上有东西突然乱跳（CLS 分数高）
│
▼
┌──────────────────────────────────────┐
│ ① 浏览器留下"证据" │
│ · 是哪个东西跳了？ │
│ · 跳之前长啥样（图片有没有写尺寸？） │
│ · 跳那一刻，哪个文件恰好刚加载完？ │
└─────────────────┬────────────────────┘
│ 证据
▼
┌──────────────────────────────────────┐
│ ② 对号入座，自动找到原因 │
│ · 图片没尺寸？ 字体换了？ │
│ · 突然塞进广告？ 排版样式来晚了？ │
│ · （压缩代码 → 还原回源码哪行） │
└─────────────────┬────────────────────┘
│ 原因
▼
┌──────────────────────────────────────┐
│ ③ 趁早修（网页画出来之前） │
│ · 图片补尺寸 / 广告位留好位置 │
│ · 字体设可选 / 关键样式提前送 │
│ · 改完能撤销，改之前要用户点头 │
└─────────────────┬────────────────────┘
│ 修完
▼
┌──────────────────────────────────────┐
│ ④ 多测几次，确认真好（不是运气好） │
│ · 修之前测几遍 vs 修之后测几遍 │
│ · 真的稳定下降，才算数 │
│ · 测不够 / 没降，就老实说"不确定" │
└─────────────────┬────────────────────┘
│ 确认好了
▼
┌──────────────────────────────────────┐
│ ⑤ 记成规矩，防再犯 │
│ · 以后改别的，CLS 一涨就提醒 │
│ · 别让修好的问题被新改动带回来 │
└──────────────────────────────────────┘这就是归因（①②）+ 自愈（③④）+ 防再犯（⑤） 。下面五节，每一节对应图里的一个框，讲清它做什么、为什么这么设计。
① 监控留证据：为什么不能只算分数？
分数只告诉你"跳了"，不告诉你"谁跳、为什么跳"。如果监控只算分数，后面找原因就只能靠猜------而猜，正是 CLS 修不好的根源。
所以设计上，监控层除了算分数，必须把每次跳动的"证据"留全 ：谁跳了（sources 里的元素）、跳之前长什么样（有没有尺寸、原来在哪）、跳那一刻哪个文件刚加载完（资源时间线）。而且监控层只管采证据，不管判原因------判原因的事交给下一层（归因）。这样分工，监控层简单、专注，不背业务逻辑的包袱；证据采全了，归因才有原料。
js
// 监控：算分数（session window）+ 留全证据（给归因用）
let session = { value: 0, start: 0, end: 0 };
new PerformanceObserver((list) => {
for (const e of list.getEntries()) {
if (e.hadRecentInput) continue; // 用户操作后的反馈，排除（那不是 bug）
shifts.push({ value: e.value, sources: e.sources, time: e.startTime }); // ★ 留证据
}
}).observe({ type: 'layout-shift', buffered: true });为什么排除用户操作后的跳动 ：你点"展开菜单"，菜单撑开推开下面，这是你预期的反馈，不是问题。算法用 hadRecentInput 跳过它------CLS 只惩罚"用户没招惹它、它自己乱动"。
② 归因对号入座：为什么用模式匹配，不靠猜？
CLS 的原因就四类，而且每一类都有明确的证据特征 ：图片没尺寸 = 跳的是图 + 图没写宽高 + 图在跳动那一刻刚加载完（三个条件同时成立）。这种"原因可枚举、特征明确"的情况，用规则对号入座，比任何猜测都可靠------确定性、可复现，每次给同样证据得到同样结论。
设计上不选"让 AI 猜"，是因为根因清晰、可枚举时，规则比猜测更稳。AI 猜会错、会幻觉，而"图没尺寸 + 图刚加载"这种硬条件，对就是对、不对就是不对。能用确定性的，就不用概率性的。
js
// 归因：拿"证据 + 资源时间"，对号入座四种原因
function attributeShift(entry, resourceTimings) {
for (const s of entry.sources) { // sources = 浏览器留的证据
const node = s.node; // 谁跳了
if (node.tagName === 'IMG'
&& !(s.previousAttrs && s.previousAttrs.width) // 跳之前没尺寸
&& resourceLoadedAround(node.src, entry.startTime, resourceTimings)) { // 图刚加载完
return { kind: 'unsized_image', node };
}
if (isTextNode(node)
&& fontLoadedAround(entry.startTime, resourceTimings)
&& s.previousRect.width !== s.currentRect.width) { // 文字宽度变 + 字体刚加载
return { kind: 'font_swap', node };
}
}
return { kind: 'unknown' };
}为什么还要 sourcemap 和指纹去重：线上代码是压缩的，光知道"某张图"不够，要用 sourcemap 还原回源码具体哪行，才知道改哪；同一个原因导致多次跳动（同一张图撑开三次），用指纹聚合成一个，别当成三个独立问题------否则一个根因被算成 N 个，统计和修复都乱。
③ 干预趁早：为什么加载后改无效？
这是整个流程里最容易栽的坑。CLS 发生在网页的布局阶段------东西刚排好位、正要画出来时，图片加载完撑开，把排好的位挤乱，跳动就发生了。
如果你等网页全加载完，再用脚本去补尺寸------对不起，跳早跳完了，补了也改不回已经发生的事。 所以设计上，干预必须抢在"布局发生之前"注入，这就是"趁早"的本质：在副作用发生之前动手，而不是之后补救。
js
// 干预：抢在渲染之前注入修复（injectImmediately = 渲染前）
chrome.scripting.executeScript({
target: { tabId }, world: 'MAIN', injectImmediately: true,
func: () => {
// 加载前就给无尺寸图占好位，加载完就不会撑开挤别人
const css = `img:not([width]):not([height]):not([fetchpriority="high"]) {
aspect-ratio: 16 / 9; background: #eee;
}`;
const s = document.createElement('style');
s.textContent = css;
(document.head || document.documentElement).appendChild(s);
}
});为什么排除首屏最大的图（LCP） ：给它加尺寸会推迟它的加载------治了 CLS，却拖慢了首屏。不能为一个指标牺牲另一个。为什么改动要能撤销 + 要用户同意 ：自动改页面是敏感操作，必须可回滚（记标记，验证不过就还原）、必须先经用户确认。自动化的底线，是可控、可撤销。
④ 验证多测：为什么不能只看一次？
修完 CLS 降了。但这次降，是修复起效了，还是这次碰巧网络快、广告没加载？单次测量充满噪声，只看一次会被骗。
设计上用"修之前测几遍、修之后测几遍，前后对照 + 统计检验"：多次采样把偶然波动平均掉，统计判断"这个下降是真的、稳定的"。这是"证明修复有效"，不是"感觉修复有效"。 而且诚实：样本不够或差异不显著，就标"不确定"，不硬下结论------宁可承认没把握，也不伪造确定性。
js
// 验证：修前 N 次 vs 修后 N 次，配对统计，排除偶然
function pairedTTest(baseline, treated) {
const n = Math.min(baseline.length, treated.length);
if (n < 4) return { conclusion: 'inconclusive', reason: '样本不足，不下结论' };
const diffs = []; // 修后 - 修前，期望为负（下降）
for (let i = 0; i < n; i++) diffs.push(treated[i] - baseline[i]);
const mean = diffs.reduce((s, d) => s + d, 0) / n;
const variance = diffs.reduce((s, d) => s + (d - mean) ** 2, 0) / (n - 1);
const t = mean / Math.sqrt(variance / n);
const significant = twoSidedP(t, n - 1) < 0.05 && mean < 0; // 显著 + 方向确实是降
return { significant, conclusion: significant ? 'decrease' : 'no_effect' };
}为什么还要方向校验：期望 CLS 下降，如果统计显著但方向是"升"，那不是修好了，是修出新问题------显著不等于成功，方向得对才算。
⑤ 防再犯：为什么修完还要守？
你今天修好了 A，明天改 B，可能不知不觉把 A 又弄坏。没有守护，修复会随时间失效------这是工程里最常见的"修了又坏"。
设计上要闭环：修复验证通过后，把"原因 + 修法 + 验证结果"记成一条回归用例 。以后任何改动，自动重放这条用例检查 CLS 没涨。CLS 一涨，立刻提醒：是不是新改动把它弄回去了？ 修复加上守护，才算真正解决，而不是"此刻恰好没跳"。
总结：归因 + 自愈，把分数之后的活自动化
图、文字、代码讲的是同一件事：
CLS 自动化归因及自愈，让系统自动做完五步------留证据、找原因、趁早修、多测确认、防再犯。 每一步的设计都有道理：监控只采不判（分工）、归因用规则不猜（确定性）、干预趁早（机制约束）、验证多测（排除偶然）、沉淀回归（防复发）。其中①②是归因 （把分数翻译成根因），③④是自愈（修复并证明），⑤是闭环防再犯。这五步全自动，人只看结论。
这套思路不只 CLS：网页卡（屏蔽某脚本看还卡不卡）、内存泄漏（清掉看还涨不涨）、代码报错（改对看还报不报），都是同一个套路------归因定位 → 自愈修复验证 → 防再犯，每一步都讲得出"为什么这么做"。CLS 只是其中根因最清晰、最适合自动化的一个。
下次看到 CLS 高，别只盯着那个分数。分数只是起点，真正的活、真正的设计，都在分数之后。