contain: layout paint 是唯一能真正压住重绘扩散的组合，因光标移动需 paint 限重绘范围，语法标记插入需 layout 防重排；单用其一均失效，且必须设 min-height/max-height 并作用于父容器而非 contenteditable 元素。
对 HTML 编辑器这类频繁局部更新、内容高度动态的场景，contain: layout paint 是唯一能真正压住重绘扩散的组合，单用 paint 或 layout 都会失效。
为什么编辑器容器必须用 layout paint 而不是单值
HTML 编辑器的 DOM 变化通常同时包含两类行为：光标移动、选区高亮（仅视觉变化）、以及实时语法标记插入（新增/删除 inline 元素）。只加 paint 无法阻止新 span 撑开行高引发父容器重排；只加 layout 则无法限制高亮背景色变化时浏览器扫描整屏绘制区域。二者必须共存：
-
layout锁住行盒（line box）内部的尺寸传播，防止<mark>或装饰节点改变影响编辑器外侧滚动条或工具栏位置 -
paint确保光标闪烁、语法高亮切换、折叠区域展开时，浏览器只重绘编辑器视口内可见块，不触发光栅化整页 - 若用
strict，编辑器内容高度浮动（如代码块自动换行、预览区动态渲染）会导致容器塌陷——size子项会强制忽略子内容对高度的贡献
容器尺寸写法决定 containment 是否生效
浏览器对 contain: layout paint 的容器有硬性要求：必须有可预测的高度上下文，否则静默忽略。编辑器常见容器结构（如 <div class="editor"><div contenteditable>...</div></div>）极易踩坑：
- ❌ 错误：父容器
.editor { contain: layout paint; }但未设height或min-height，且子contenteditable是display: block自由撑高 → Chrome 直接跳过隔离 - ✅ 正确：
.editor { contain: layout paint; min-height: 300px; max-height: 600px; overflow-y: auto; }，配合子元素contenteditable的white-space: pre-wrap和word-break: break-word - ⚠️ 注意：不要给
contenteditable元素本身加contain—— 它是内联上下文起点，加了反而破坏行盒计算；隔离必须落在其父级 wrapper 上
哪些子元素会意外破坏 containment 效果
编辑器中常嵌入的组件可能绕过隔离边界，让浏览器被迫扩大重绘范围：
立即学习“前端免费学习笔记（深入）”；
-
position: absolute的浮动工具提示（如参数提示、补全菜单）：仍可正常显示，但若其top/left计算依赖外部 scrollY，则layout隔离会切断该依赖，导致定位偏移 -
position: fixed的全屏覆盖层（如“正在保存”遮罩）：不受contain影响，但若遮罩父级被设了contain: strict，Safari 可能错判层叠上下文，导致遮罩不显 - 使用
box-shadow或filter: drop-shadow()的语法高亮块：若容器未设overflow: hidden，阴影可能物理溢出，而contain: paint不裁剪——此时需额外加overflow: hidden，但要小心它会截断position: absolute子元素
验证是否真起效，别信 getComputedStyle
写了 contain: layout paint 并不代表浏览器执行了隔离。真实效果必须通过渲染行为观测：
- 打开 Chrome DevTools → Rendering → 勾选 “Paint Flashing”，然后在编辑器里快速打字、拖动选区、触发高亮更新：闪光应严格限制在
.editor边界内，外部工具栏、状态栏完全不闪 - 同页面滚动时，开启 “Layout Shift Regions”：折叠/展开代码块不应引起编辑器外区域的布局位移高亮
- 禁用 JS 后手动修改 DOM（如在 Elements 面板删一个
<span class="token">），观察重绘范围是否收缩——这是检验隔离是否生效最直接的方式
最关键的细节：containment 生效的前提是容器在首次渲染前就已声明样式。用 JS 动态加 el.style.contain = 'layout paint' 在 Safari 中大概率失败，必须走 CSS class 或 @supports 规则注入。
