will-change不能直接写在HTML标签内，必须通过CSS声明；仅对transform和opacity等可合成属性有效，表格中只对实际变化的行或单元格按需动态设置，避免全局滥用导致内存飙升。

Html2md

使用 Readability + Turndown 将 HTML 页面转换为干净的、Agent 友好的 Markdown。去除导航栏、广告、页脚、Cookie 横幅、社交按钮等干扰元素。支持 URL...

下载

will-change不能写在

或标签里

直接往 HTML 标签上加 will-change="transform" 或 will-change_html="transform" 完全无效——浏览器当它是普通自定义属性，既不解析也不报错。表格元素本身不支持内联 will-change，必须走 CSS 声明路径。

表格里哪些元素能加、哪些加了也白加

will-change 只对后续真会变的 transform 或 opacity 起提示作用，且仅限可合成属性。表格场景下：

• transform：可加，但只对实际做位移/缩放的单元格或行有效（比如拖拽排序时高亮移动的 <tr>）
• opacity：可加，适用于淡入/淡出的加载态行（如新增行从 0→1）
• left、top、width、background-color：加了也白加，这些属性触发重排/重绘，will-change 对它们无响应
• 整张 <table> 或所有 <td> 批量加 will-change: transform：会导致每个单元格都占一个图层，内存飙升，滚动卡顿立竿见影

动态控制比静态声明安全十倍

表格数据频繁变动时，will-change 必须按需开关，否则等于长期占用 GPU 图层资源：

• 在拖拽开始、行插入动画触发前 1–2 帧，用 JS 设置：targetRow.style.willChange = 'transform'
• 监听 transitionend 或 animationend，结束后立刻设回：targetRow.style.willChange = 'auto'（不是空字符串）
• 避免在 scroll 或 resize 事件里反复 set/remove —— 节流不到位容易堆积未清理状态
• 长表格中，只对 IntersectionObserver 检测到的可视区域内的行启用，别全局扫描

验证是否真生效，别靠猜

加了 will-change 不代表优化成功，必须实测确认：

立即学习“前端免费学习笔记（深入）”；

• 打开 Chrome DevTools → More Tools → Layers 面板，手动触发表格动画，看目标行是否出现在图层列表中，且 Reason 字段显示 layer-for-transform（仅显示 will-change 说明只是收到提示，没升层）
• 勾选 Rendering → «Paint flashing»：如果动画期间满屏绿色闪动，基本就是 will-change 泛滥了
• 移动端尤其敏感，Layers 面板顶部显示 Compositing layers: X，超过 20 层就得排查

真正影响性能的，从来不是该不该加 will-change，而是是否清楚表格重绘瓶颈在哪、是否理解图层生成机制、是否愿意为每行动画单独管理生命周期。