低端安卓机卡顿主因是重绘范围失控，需用contain: layout paint配显式尺寸、content-visibility: auto配contain-intrinsic-size、精准控制will-change生命周期，并避免contain与容器查询机制误叠加。
低端安卓机上滚动卡顿、动画掉帧，核心问题往往不是“CSS写得不够炫”，而是重绘范围失控——浏览器被迫反复重绘大片区域。关键不是加多少动画，而是让浏览器知道“哪些地方真没必要动”。
contain: layout paint 必须配显式尺寸
只写 contain: paint 几乎没用，尤其在高度不确定的列表项里。浏览器没法快速定位绘制边界，仍要遍历子树算 layout，隔离就失效了。
- 必须搭配
width/height或min-height（比如min-height: 48px） - 推荐组合：
contain: layout paint+height: auto不行，height: 60px或min-height: 60px才稳 - 若子元素含
position: absolute，确保其offsetParent在 contained 区域内，否则会逃逸出绘制边界
content-visibility: auto 是长列表的首选
对滚动列表、可折叠面板这类“大量 DOM 但非全部可见”的场景，content-visibility: auto 比手写 contain 更省心、收益更高。
- 一行生效：
content-visibility: auto，自动跳过不可见区域的渲染和解析 - 务必加
contain-intrinsic-size: 60px（值按实际项高设），防止布局抖动 - 注意：
position: fixed在该容器内会被强制转为position: absolute，需检查视觉偏移
@container 查询和 contain 完全无关
很多人以为设了 contain: layout paint 就能用 @container，其实不行。容器查询需要单独声明 container-type。
立即学习“前端免费学习笔记（深入）”；
-
container-type: inline-size（查宽度）或container-type: size（查宽高）才开启查询能力 -
display: contents会破坏容器查询上下文，@container规则直接静默降级 - 混用时小心边界：比如在
container-type: inline-size容器里再套contain: layout子元素，layout 计算可能被截断两次，反而增加开销
transform + will-change 要精准控制生命周期
移动端图层资源紧张，will-change 不是开关，是提示——用错时机或范围，比不用还糟。
- 只在动画开始前 1～2 帧设置：
element.style.willChange = 'transform' - 动画结束回调中立刻清空：
element.style.willChange = 'auto' - 避免全局写
will-change: transform，也别长期挂在静态元素上 - 慎用
filter、backdrop-filter，它们强制新建图层且开销大，低端机尽量降级或规避
真正卡性能的，常是 containment 和容器查询、content-visibility、will-change 这几类机制叠加时的隐式行为——比如父容器用了 content-visibility: auto，子元素又手动加了 contain: strict，浏览器可能重复截断渲染流程。先用 Chrome DevTools 的 Layer Borders 和 FPS Meter 实测，再决定叠哪一层。
