will-change 在 Chrome 60–79 中仅能有限引导图层合成，效果不稳定；其解析缺陷、父容器限制及未重置导致内存泄漏，故应优先采用更可靠的降级方案。
will-change 在低版本 Chrome（如 60–79）中确实能缓解卡顿，但效果不稳定——它不是“修复”，而是对浏览器图层策略的有限引导。老版本 Chrome 的合成器不够智能，will-change 有时被忽略，有时又过度创建图层，反而拖慢性能。
低版本 Chrome 对 will-change 的支持很弱
Chrome 60–75 默认不主动为 transform 或 opacity 创建独立图层，除非明确提示。但它的解析逻辑有缺陷：
-
will-change: transform可能被识别，但will-change: opacity, transform常被降级为只处理前者 - 若元素父容器有
overflow: hidden或transform，老 Chrome 可能拒绝升层，will-change形同虚设 - 动画结束后未重置
will-change: auto，图层会一直驻留，内存占用持续上升
比 will-change 更靠谱的 fallback 方案
在 Chrome
- 用
transform: translateZ(0)或transform: translate3d(0, 0, 0)替代will-change—— 兼容性更好，老 Chrome 强制升层成功率更高 - 确保动画元素有明确的
position: relative或position: absolute，避免因文档流参与导致合成失败 - 禁用
will-change: scroll-position和will-change: contents：它们在低版本中基本无效，还可能引发渲染异常
必须配合的 CSS 属性限制
即使加了 will-change 或 translateZ(0)，只要动画里混入以下任一属性，低版本 Chrome 仍会降级到软件渲染：
立即学习“前端免费学习笔记（深入）”；
-
left/top/width/height—— 触发 layout，直接卡死 -
background-position—— 老 Chrome 不把它当合成属性，除非显式加will-change: background-position（但支持极差，不建议） -
filter: blur()—— 即使加了will-change，Chrome 70 之前几乎必然掉帧
真正起效的组合非常窄：仅 transform + opacity + translateZ(0) + 动画前 JS 设置、动画后 JS 清除，才可能在 Chrome 68–79 上稳定跑满 60fps。其他任何“加个 will-change 就行”的想法，在低版本里大概率失效。
