移动端卡顿主因是css触发重排重绘，应仅用transform和opacity实现gpu合成动画，禁用top/left/width/height等布局属性，动态控制will-change并用devtools验证图层。
移动端页面卡顿，八成和CSS写法有关——不是JS慢，也不是网络差，而是浏览器在主线程上被样式拖垮了。
用 transform 和 opacity 替代 top/left/width/height
left、top、width 这类属性一动，浏览器就得重新计算布局（reflow），再重绘（repaint），移动端 CPU 弱，一帧就超时。而 transform 和 opacity 属于“合成属性”，只走 GPU 合成层，不碰布局和绘制。
- ✅ 正确：
transform: translateX(50px)、opacity: 0.8 - ❌ 错误：
left: 50px、margin-top: 20px、width: 200px - ⚠️ 注意：
transform: translateZ(0)能强制升层，但别滥用——每个图层吃内存，iOS 上图层过多直接掉帧甚至崩溃
谨慎使用 will-change，且必须配合 JS 控制生命周期
will-change 不是“开挂指令”，它只是提前告诉浏览器：“这个元素马上要动了，请分配资源”。但长期挂着，等于让浏览器一直扛着一个闲置图层。
- ✅ 正确做法：动画开始前 1～2 帧设
element.style.willChange = 'transform'；动画结束回调里立刻清空：element.style.willChange = 'auto' - ❌ 错误写法：
will-change: transform写死在 CSS 里、或对静态导航栏也加 - ? 验证方式：Chrome DevTools → Rendering → ✅ “Layer borders” 查图层是否合理，✅ “FPS meter” 看帧率是否稳定
避开 calc() + 百分比嵌套的渲染陷阱
calc(100vw - 2rem) 看似灵活，但在多个元素中反复出现，尤其父容器本身也靠 calc() 或 flex 分配尺寸时，浏览器得递归求值，同步阻塞渲染线程——低端安卓机上卡顿特别明显。
- ✅ 替代方案：把动态尺寸抽成 CSS 自定义属性，如
:root { --sidebar-width: 280px; }，用 JS 单次更新document.documentElement.style.setProperty('--sidebar-width', '240px') - ✅ 能用
flex: 0 0 auto或min-content实现自动收缩，就别硬算calc(100% - 80px) - ⚠️ 特别注意：动画中绝对禁用
width/height变化，改用transform: scale()或clip-path模拟
媒体查询别堆断点，语义化 + em 才真适配
写一堆 @media (max-width: 375px)、@media (max-width: 414px)……看着精细，实则让 CSSOM 构建变慢。每个断点都要参与匹配，低端机解析耗时翻倍。
- ✅ 只保留 3 个语义断点：
mobile（max-width: 480px）、tablet（481px–1024px）、desktop（min-width: 1025px） - ✅ 断点值统一用
em，比如max-width: 30em，适配用户系统字体缩放 - ✅ 把 hover 动效等非触屏功能包进
@media (hover: hover)，避免 iOS/Android 加载无用规则
最常被忽略的是：性能问题往往藏在“看起来没问题”的地方——比如一个 backdrop-filter 毛玻璃 header，或一段没清 will-change 的轮播 JS，它们不会报错，但会让帧率从 60 掉到 20，而且只在真机上才暴露。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
