浏览器动画卡顿主因是帧超16ms，需用requestanimationframe对齐刷新节奏、transform/opacity避免回流重绘，并杜绝动画帧内读写交替触发强制同步布局。
浏览器动画卡顿，不是帧率设得越高越好，而是要让每一帧都在 16ms 内完成渲染——这是 60fps 的硬性时间窗口，超了就会掉帧。
为什么 requestAnimationFrame 比 setTimeout 更适合动画
因为 requestAnimationFrame 会自动对齐屏幕刷新节奏（通常为 60Hz），而 setTimeout(fn, 16) 只是“尽量”每 16ms 执行一次，实际触发时机不可控，容易和重排/重绘错位，导致跳帧或抖动。
- 它会在浏览器下一次重绘前执行回调，天然绑定渲染管线
- 页面不可见时（如切换 Tab），
requestAnimationFrame自动暂停，省资源 - 不建议手动计算帧间隔或用
setInterval驱动关键动画
CSS 动画该用 transform 还是 left/top
必须优先用 transform 和 opacity。这两类属性触发布局（Layout）和绘制（Paint）的开销极小，能走合成器线程（Compositor Thread），不阻塞主线程。
Article To Html
下载
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
-
left、top、width、height等会触发 Layout → Paint → Composite 流程，频繁修改极易掉帧 - 哪怕加了
will-change: transform，也不能弥补top本身带来的布局计算 - 用
transform: translateX(10px)替代left: 10px，性能差异常达 3–5 倍
哪些操作会意外打断合成（forced synchronous layout）
当你在 requestAnimationFrame 回调里读取 offsetTop、getBoundingClientRect()、scrollHeight 等布局信息时，浏览器必须立刻回流（reflow），把之前所有样式计算、布局全部执行完——这会强行阻塞当前帧，大概率超 16ms。
- 避免在动画帧内读写交替：比如先改
style.transform，马上又读offsetLeft - 把读取操作批量提前到帧开始（如
raf回调最开头），写入操作集中放在末尾 - 用
element.getBoundingClientRect()前确认没有未提交的样式变更，否则代价翻倍
真正卡顿的根源往往不在“没开硬件加速”，而在不经意的回流、冗余重绘或 JS 执行超时——优化要从每一帧的执行路径抠起，而不是堆配置或加 transform: translateZ(0)。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
