will-change: transform对Grid容器无效且易致卡顿，仅对JS驱动位移的子项动态设置并及时清除才有效；必须配合touch-action、overflow-x: auto、grid-auto-columns等确保真实溢出与合成滚动通道畅通。
直接给 Grid 容器加 will-change: transform 或硬塞 scroll-behavior: smooth，大概率会让滑动更卡——这不是代码写错了，而是触发了浏览器合成器的负优化路径。
为什么 grid-auto-flow: column 滑动一卡一卡的
横向滑动列表用 grid-auto-flow: column 却掉帧，往往不是 Grid 本身的问题，而是滚动容器没真正“溢出”。浏览器需要明确知道“该往右滚”，否则会把所有子项压进第一行，靠重排撑宽容器，而不是走 GPU 加速的合成滚动通道。
- 必须配
grid-auto-columns: minmax(200px, 1fr)（不能只靠grid-template-columns） - 容器要设
overflow-x: auto+white-space: nowrap，否则 Safari 可能静默截断 - 移除所有可能干扰溢出的样式：比如父级
overflow: hidden、width硬约束、或未设box-sizing: border-box导致 padding/border 撑破计算 - 在 iOS Safari 上，如果子项含
border-radius+overflow: hidden组合，会强制退回到软件渲染，滑动必然卡顿
用 transform 模拟滚动时，will-change 怎么加才有效
will-change: transform 对 Grid 子项生效的前提是：它真正在被 requestAnimationFrame 驱动位移，且不伴随 layout 触发。静态写死在 CSS 里，等于白占 GPU 内存，还可能让合成器频繁切换图层。
- 只在 touchstart 后动态加：
element.style.willChange = 'transform' - touchend 或
pointerup后 100ms 内立刻清空：element.style.willChange = 'auto' - 确保子项已脱离 Grid 布局约束：加
position: absolute或inset: 0，避免每次 transform 都牵连父容器重排 - 别在 Grid 容器上设
will-change，它不滚动，滚动的是里面那个被 translate 的元素
scroll-behavior: smooth 和 JS 滚动控制能不能共存
不能。两者叠加会导致视觉撕裂和掉帧——scroll-behavior: smooth 是浏览器原生滚动动画，走 layout 层；而 JS 控制 transform 或 scrollTop 是手动合成，走 compositor 层。浏览器会在两层之间反复同步，帧率直接崩到 30fps 以下。
- 选 JS 方案就彻底禁用：
scroll-behavior: auto（显式覆盖全局或局部） - 用
scrollTo({ top, behavior: 'smooth' })时，别再同时监听scroll事件去改transform - 若需自定义缓动，用
requestAnimationFrame+ 线性插值，别依赖 CSS 动画或 transition - 真机调试时盯住 Chrome DevTools 的 Layers 面板：正常应只有 1–2 个合成图层；如果看到“Raster”频繁刷屏或图层数飙升，说明
will-change或transform正在制造内存碎片
最易被忽略的一点：Grid 滑动流畅度的瓶颈，90% 不在 Grid 语法本身，而在你是否允许浏览器把滚动判定交给合成器——这取决于 touch-action 是否明确、overflow 是否真实触发、以及有没有其他样式（如 filter、backdrop-filter）悄悄关闭了硬件加速通道。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
