content-visibility: auto 能显著降低编辑器首屏渲染耗时（900ms→250ms），但必须动态设置contain-intrinsic-size、避开可编辑容器/固定定位工具栏/自适应父容器，并通过@supports和js支持性检测做渐进增强，否则导致光标错位、高亮失效、滚动抖动。
content-visibility: auto 能压首屏，但编辑器里直接加等于白干
超长 HTML 编辑器（比如富文本编辑区、Markdown 预览面板、代码块堆叠页）DOM 深、节点多、样式计算重，content-visibility: auto 确实能跳过离屏段落的 layout/paint，实测首屏渲染可从 900ms 降到 250ms。但编辑器不是普通列表——它有光标定位、焦点管理、实时高亮、语法解析等强交互逻辑，盲目套用会立刻出问题。
常见翻车点：getBoundingClientRect() 对未渲染段落返回 { height: 0 }，导致光标位置错乱；IntersectionObserver 监听不到滚动进入事件，语法高亮不触发；用户快速拖动滚动条时，内容“闪入”+ 滚动条突然变长，体验断裂。
contain-intrinsic-size 必须动态设，静态写死必抖
编辑器内容高度极不固定：一段空行、一个三行标题、一个带折叠代码块的段落，高度差可能达 3 倍。用固定值如 contain-intrinsic-size: 160px 会导致大量留白或撑不开，滚动仍抖。
- 初始加载时，按编辑器默认字体行高 × 最大常见行数估算，比如
1.5em × 8 = 120px，设为保守下限 - 每段落首次渲染后，立即用 JS 读取真实高度：
element.scrollHeight，再赋给element.style.containIntrinsicSize = `${height}px` - 监听内容变化（如输入、粘贴、折叠展开），触发对应段落的
containIntrinsicSize更新，别等滚动进入才补
哪些编辑器区域绝对不能加 content-visibility
不是所有“长”都适合延迟渲染。以下区域加了反而卡顿或功能失效：
- 当前聚焦的编辑器
<div contenteditable="true"> 容器本身——浏览器对 <code>content-visibility: auto下的可编辑元素支持不稳定，光标可能消失或定位偏移 - 含
position: fixed子元素的工具栏（如浮动菜单、快捷按钮），隔离后会脱离视口定位上下文，飘到左上角 - 依赖父容器高度自适应的布局区（如自动撑开的预览面板），未渲染子项会让父容器高度塌为 0
- SSR 渲染的初始 HTML 中直接加该属性——JS 还没执行，用户看到的是空白区块，必须等 hydration 完成后再通过 class 控制启用
- 用
@supports (content-visibility: auto)包裹样式，老浏览器自动忽略，回退到原始渲染 - JS 初始化时检查支持性：
'contentVisibility' in document.documentElement.style，不支持则跳过动态更新逻辑 - 避免和
display: none混用——切换会清空渲染缓存，导致重复 layout，改用临时opacity: 0; pointer-events: none+force-updateclass 触发重绘 - 屏幕阅读器关键路径（如编辑器状态栏、错误提示区）不加该属性，确保首屏可访问性不降级
兼容性兜底和渐进增强怎么写才不露馅
Chrome 85+、Edge 85+、Safari 17.4+、Firefox 桌面版已支持；但 Firefox for Android 和 iOS Safari ≤ 16.4 仍不支持。不能只靠 CSS。
content-visibility 的真正难点不在“加”，而在“什么时候加、加在哪、加完怎么管”。占位尺寸不准、动态更新滞后、兼容性漏判，任意一点没控住，性能优化就变成体验灾难。
