卡顿主因是浏览器每帧执行样式计算→布局→绘制→合成，任一环节被阻塞即掉帧；必须仅用transform和opacity做过渡，禁用left/top/width等触发重排的属性，并避免transition: all、JS同步读取布局及图像未预解码。
过渡效果卡顿，不是动画太“慢”，而是浏览器在关键帧里干了不该干的事——比如重排、解码图像、同步读取 layout，或者对不支持插值的属性做了 transition。
为什么 transition 会卡顿
根本原因在于：浏览器必须在每一帧里完成样式计算 → 布局（Layout）→ 绘制（Paint）→ 合成（Composite）。只要其中任一环节被阻塞或频繁触发，帧率就会掉。
-
transition: all 0.3s或未限定属性的transition: 0.3s会让浏览器对background-position、top、left等触发重排的属性也尝试插值，结果就是滚动/悬停时明显粘滞 - 对
height: auto或display做 transition，浏览器无法插值，直接跳变或完全不生效 - 在 iOS Safari 上连续点击时，
max-height过渡容易跳帧，尤其内容高度差异大又没加will-change: max-height - 图像首次参与 opacity/transform 过渡前未预解码，主线程被图像光栅化阻塞，导致首帧卡在 5fps
transition 只保 transform 和 opacity
这两个属性走合成层（Compositor Thread），不触发布局和绘制，是唯二真正“平滑”的过渡目标。其他属性基本都该排除。
- 把原本写的
transition: background-color 0.3s, width 0.3s, height 0.3s改成只留transition: transform 0.3s ease, opacity 0.2s ease - 需要“拉伸”效果？别碰
height，用transform: scaleY()模拟，配合transform-origin: top - 要改颜色？可以，但确保它不引发重排——比如用
box-shadow替代border，用filter: brightness()替代background-color - 真要动布局属性（如
margin、padding），就别加 transition，JS 单帧修改更稳
移动端 Safari 的 max-height 卡顿怎么修
iOS 15+ 对 max-height 的过渡优化不足，尤其内容高度浮动时，硬写 max-height: 500px 容易截断或拖沓。
Article To Html
下载
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
立即学习“前端免费学习笔记（深入）”；
- 优先用 JS 动态读取
element.scrollHeight，然后设style.maxHeight = element.scrollHeight + 'px' - 展开前给容器加
style.will-change = 'max-height'，但收起后立刻清空（避免长期占用合成资源） - 若仍卡顿，降级为
transform: scaleY(0) → scaleY(1)，视觉上仍是“从上往下展开”，且性能稳定 - 禁用
overflow: hidden的同时又设max-height，会导致 Safari 渲染异常——必须保留overflow: hidden
首帧卡顿：图像没预热就进动画
三张 <img> 初始 opacity: 0; width: 0%，第一次加 .active 类时，浏览器才开始解码、上传 GPU、建合成层——这一串操作远超 16ms。
- 页面加载完立即执行一次“隐身预演”：给每张图临时加类，触发完整
opacity: 1; width: 100%过渡，再立刻移除 - 用
setTimeout(() => img.classList.add('preheat'), 50 * i)错峰触发，避免并发解码压力 - 首屏加一层
background-image的 cover 层，遮住预演过程，用户完全无感 - 不要依赖
<link rel="preload">，它只提前下载，不解码也不渲染
最常被忽略的一点：卡顿往往不是出在“怎么动”，而是出在“动之前浏览器有没有准备好”。强制 layout 读取、图像预解码、合成层提示、属性精简——这些前置动作比调 easing 曲线重要得多。
