will-change: transform 误用于列表项会导致 GPU 图层过多而卡顿，应仅用于真实滚动容器并配合 transform 变化；content-visibility: auto 需搭配 contain-intrinsic-size 避免滚动错乱；overscroll-behavior: contain 仅控制滚动穿透行为，非性能优化手段。
别指望 overscroll-behavior 或 will-change: transform 单独解决卡顿——它们各自只管一件事，用错地方反而更卡。
为什么加了 will-change: transform 列表反而更涩？
浏览器看到 will-change: transform 就会尝试为该元素创建独立合成层。如果你把它写在每个 .item 上，一屏滚动中常驻 20+ 个节点，等于同时塞给 GPU 20 多个图层。中低端安卓机显存吃紧，纹理上传阻塞、图层抖动接踵而至，帧率可能从 60fps 直降到 20fps 以下。
- 只对真实承载滚动位移的容器设，比如
.scroll-content（虚拟滚动用）或.list-container（原生 overflow 滚动时仅限有明确尺寸且需硬件加速的父容器） - 必须搭配真实
transform变化：哪怕只是transform: translateZ(0)，否则浏览器直接忽略提示 - 绝不能写
.item { will-change: transform; }这类全局规则，DevTools Layers 面板里图层数超过 5～8 层就要立刻排查 - 禁用
will-change: scroll-position——它没被任何主流浏览器支持，iOS Safari 完全无视
content-visibility: auto 真快，但不配 contain-intrinsic-size 就是自找麻烦
移动端视口小，1000 条列表里真正可见的通常就 3～5 个。content-visibility: auto 让浏览器跳过离屏项的 layout 和 paint，首屏渲染时间实测可从 800ms 降到 200ms，内存下降超 70%。但它默认把未渲染项高度算成 0px，导致滚动条突然变短、内容上跳、手指位置错乱。
-
contain-intrinsic-size值要保守估计：固定高卡片写120px，含多行文字的写160px，宁大勿小 - 不能依赖子元素的
height或min-height，contain-intrinsic-size优先级更高 - 严禁写成
contain-intrinsic-size: 0或留空，这等于没设 - 和
display: none别混用：content-visibility: auto保留占位、可聚焦、无障碍友好；display: none会清空布局空间、破坏缓存机制
overscroll-behavior: contain 不是性能开关，是行为隔离开关
它不提升帧率，也不减少重排重绘，只控制“滚到边界后要不要传给父元素”。误用会导致 iOS 上触底没弹性、列表滑得发涩——因为你把它当成了“滚动加速器”，但它只管“别穿透”。
立即学习“前端免费学习笔记（深入）”；
- 只对满足条件的滚动容器生效：有
overflow-y: auto（不能是hidden）、内容高度超出容器、没被touch-action: none全局禁用 - 常见失效场景：
body设了overflow: hidden但没锁住scrollY（iOS Safari 会忽略子元素的contain）；flex容器没设明确高度（如height: 100vh），浏览器无法判断滚动边界 - 真正该用的地方很具体：弹窗里的评论列表、侧边栏菜单、聊天窗口嵌在
position: relative容器中时防止触发页面刷新 - 别用
none值替代contain——它会干掉 iOS 弹性回弹，用户感知就是“滑不动了”
最常被忽略的其实是 scroll 事件本身：哪怕只是读一行 scrollTop，也会强制同步回流；passive: true 不加，iOS Safari 可能直接禁用惯性滚动；图片没设宽高，每张加载都触发重排——这些开销远大于 CSS 层面的微调。
