关键在于让重绘不被用户感知：用contain: paint隔离区域、避免innerHTML全量替换、优先textContent更新、删冗余节点、表单控件只更新辅助属性而非value。

多语言切换、动态内容更新或主题变更时，只要 DOM 更新方式不当，页面就会肉眼可见地“闪一下”——这不是浏览器 bug，而是 HTML 结构和更新逻辑没对齐渲染管线的节奏。关键不在“能不能避免重绘”，而在于“让重绘不被用户感知”。

用 contain: paint 隔离重绘区域

浏览器默认把整个视口当作一个绘制单元，改一个按钮文字，可能连顶部导航栏都跟着重绘一遍。加 contain: paint 能强制划出边界，让重绘只发生在该元素内部。

• 给语言容器加 class：
  ...
  ，再配 CSS：.i18n-region { contain: paint; }
• 不要滥用：只对明确可独立更新的区域（如侧边栏、卡片列表、表单区）设，contain: layout 或 contain: strict 会带来额外解析开销
• 兼容性注意：contain 在 Safari 15.4+ 和 Chrome 52+ 支持良好，但 IE 完全不支持；若需兼容旧环境，可用 transform: translateZ(0) 做降级图层隔离

避免 innerHTML 直接赋值触发整块重排

innerHTML = '...' 看着方便，但每次执行都会清空旧节点、重新解析字符串、重建子树——哪怕只改一个词，也会触发 layout + paint 全流程。

• 纯文本更新一律用 textContent，它跳过 HTML 解析，只触 repaint
• 含标签的国际化内容（比如 登录），提前在 HTML 中预留结构：，JS 只填 el.querySelector('strong').textContent = '登录'
• 批量更新时别写 for 循环逐个设 textContent，先收集所有目标节点，再一次性遍历赋值，让浏览器有机会合并绘制

删掉冗余节点，减少初始解析压力

DOM 节点越多，HTML 解析越慢，首屏布局计算越重——这不是“重绘问题”，却是后续所有重绘变卡的底层原因。每多 100 个无用节点，平均拖慢解析 20–40ms。

HTML Text Extract

从HTML页面（URL、文件或标准输入）中提取主体内容文本，去除导航、页脚、广告和模板文本。可直接传递给readability_check或其他文本工具。

下载

• 用 Chrome DevTools 右键某个
  →「Break on subtree modifications」，观察它是否真被 JS 操作；没动静且没对应 CSS 规则，直接删整块
• CMS/低代码导出的残留如
  、

  ，只要没 JS 读 dataset、也没 CSS 匹配该 class，就删
• 语义化替换优先：
  →

  ，避免用

  这类断裂结构

  表单控件更新必须跳过 value 属性

  切换语言时重设 input.value 或 textarea.value，会清空用户已输入内容——这不是重绘问题，但常被当成“UI 闪退”误报。

  • 只更新 placeholder、title、aria-label 等辅助属性：el.setAttribute('placeholder', langPack.loginPlaceholder)
  • 别用 el.placeholder = ...，IE11 下某些 setter 会隐式触发重排；setAttribute 更稳定
  • 按钮文字用 textContent，禁用状态文案也走同一套 i18n 流程，别靠 CSS ::after 插入，那会绕过 JS 控制时机

  真正难处理的不是单次重绘，而是语言切换与滚动、动画、输入同时发生时的帧竞争。这时候哪怕加了 contain: paint，如果更新逻辑卡在 scroll 回调里没节流，照样一秒几十次重绘。动手前先看 DevTools 的 Rendering 面板里 Layout / Paint 时间占比，再决定优化方向。