will-change对排版引擎完全无效，只预告transform、opacity等合成属性变更，无法加速layout/reflow；滥用会增加开销，编辑器卡顿根源在dom操作、同步计算等主线程瓶颈。
will-change 不是 HTML 属性，也不能在 HTML 编辑器里“通过属性设置”来预加速排版引擎——它只在 CSS 渲染树构建阶段起效，对排版（layout）本身无加速能力，更不作用于 HTML 编辑器的内部排版逻辑。
will-change 对排版引擎完全无效
浏览器排版引擎（如 Blink 的 LayoutTree 构建、Gecko 的 Reflow）处理的是 width、height、left、display、flex 等触发重排（reflow）的属性。will-change 对这些值写任何提示（比如 will-change: width 或 will-change: contents）都会被浏览器静默忽略，或引发额外开销却无实际优化。
常见误判现象：
- 给富文本编辑器容器加
will-change: transform，但编辑时频繁插入 DOM 节点 → 仍卡在 layout 阶段，will-change毫无作用 - 在
contenteditable元素上写will-change: scroll-position→ Chrome/Firefox 几乎不响应，滚动卡顿照旧 - 以为加了
will-change: contents就能加速文字重绘 → 实际该值仅对极少数内容高频更新场景（如聊天消息流）有微弱提示意义，且兼容性差
HTML 编辑器真正卡顿的根源不在 will-change 覆盖范围
富文本编辑器（如 Slate、ProseMirror、Quill 或原生 contenteditable）的性能瓶颈通常来自：
- DOM 树深度过大 + 频繁
innerHTML替换 → 触发全量 reflow 和 repaint - 监听
input或compositionend时执行同步复杂计算（如语法高亮、实时校验）→ 阻塞主线程 - 未做虚拟滚动，长文档渲染全部节点 → 内存暴涨、样式计算耗时飙升
- 滥用
getComputedStyle或offsetHeight→ 强制同步 layout
will-change 无法绕过上述任一环节。它只对后续走合成线程（compositor thread）的属性变更起预告作用，而编辑行为几乎全是主线程 layout/paint 工作。
什么情况下可以谨慎加 will-change？仅限视觉动效层
如果你的 HTML 编辑器带有**独立于编辑逻辑的 UI 动效层**（比如悬浮工具栏淡入、侧边栏滑出、光标闪烁动画），且这些动效已严格限定为 transform 或 opacity 变更，才可考虑动态启用：
- 悬浮菜单显示前：用
el.style.willChange = 'transform, opacity' - 菜单
transitionend后立即设回'auto'，绝不挂载在初始化样式中 - 确认该元素父级无
overflow: hidden或clip-path抑制图层提升 - 用 Chrome DevTools Layers 面板验证是否真生成了
layer-for-transform，而非仅显示Reason: will-change
真正影响编辑器流畅度的，是 DOM 更新策略、事件节流、CSS containment（如 contain: layout paint）、以及避免强制同步布局——will-change 是个旁观者，不是解药。它连排版引擎的门都进不去，更别说预加速了。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
