will-change: opacity 仅在元素即将发生 opacity 动画时有效，需配合实际变化、及时移除，滥用会导致内存占用上升和性能下降。
will-change: opacity 能起作用，但必须配合真实发生的 opacity 变化，且不能长期挂着——它不是“设了就自动变流畅”的开关，而是浏览器优化的“预告函”。
什么时候该加 will-change: opacity
只在明确知道元素即将执行 opacity 动画（比如 hover 显隐、JS 触发的淡入淡出、加载状态切换）且动画帧率不稳时才加。常见场景包括：
- 按钮悬停时用
transition: opacity 0.2s显隐图标 - 模态框打开/关闭时通过
opacity+visibility控制显示 - 列表项加载完成时从
opacity: 0过渡到1
如果只是静态样式或变化极少（比如一天只触发一次），加了反而浪费内存。
怎么写才真正生效
关键不是“写了就有效”，而是写法要匹配浏览器的合成层提升逻辑：
立即学习“前端免费学习笔记（深入）”；
html-to-pptx-converter
下载
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
- 必须搭配实际会变化的
opacity值（如从0→1或反之），纯 CSS 声明但没变化，浏览器不会响应 - 推荐用 class 切换而非内联 style：
.fade-in-ready { will-change: opacity; }，动画开始前加，结束立即移除 - 避免写成
will-change: opacity, transform却只动opacity，多写的提示可能让浏览器做无用预分配 - 不要在父容器上写
will-change: opacity期望子元素受益——它只对当前元素生效
为什么加了反而更卡？常见踩坑点
滥用 will-change 是性能倒退的主因，尤其 opacity 类型：
- 长期挂载：动画结束后没清除，浏览器持续维持独立图层，GPU 内存占用上涨，多个元素同时存在会明显拖慢滚动
- 批量滥用：给一整列卡片都加
will-change: opacity，等于主动要求浏览器为每个卡片单独建图层，内存爆炸 - 和
position: absolute+top/left混用：虽然能提升图层，但top/left本身触发重排，will-change无法抵消，反而增加开销 - 在低性能设备（如旧安卓 WebView）上，过度图层化会导致纹理上传失败或掉帧，表现比不加还差
JS 配合移除的最小可行示例
动画结束必须清理，否则优化变负优化。用 transitionend 最稳妥：
element.addEventListener('transitionend', () => {
element.style.willChange = 'auto';
// 或移除 class：element.classList.remove('fade-in-ready');
});
注意：transitionend 只在 CSS transition 触发时触发；如果是 JS 直接改 style.opacity（无 transition），就得自己记时间用 setTimeout 清理，或改用 requestAnimationFrame + 计数器判断动画帧结束。
真正难的不是加，是判断“什么时候该加”和“什么时候必须删”——这两点漏掉任何一个，will-change: opacity 就从性能助手变成页面负担。
