先用Performance面板定位瓶颈：密集Layout/Paint是特效问题，XHR堆积是AJAX问题；再针对性优化CSS动画与请求逻辑。
界面卡顿怎么快速定位是特效还是 AJAX 拖慢的
先别急着关东西，得先分清锅是谁的。浏览器开发者工具的 performance 面板录一段操作，看主线程里密集的是 layout / paint（大概率是 css 动画、阴影、透明度变化这类视觉特效），还是大量 xhr 或 fetch 请求堆积在 network 时间轴上（那就是 ajax 拉垮了）。
常见错误现象：滚动卡、点击按钮后几秒才响应、输入框打字延迟——前两者偏渲染瓶颈，后者偏请求排队或回调处理太重。
- 如果
Performance里看到频繁的Recalculate Style或长Paint块，优先查 CSS 动画、transform缺失硬件加速、或用了box-shadow/filter在滚动容器上 - 如果
Network面板里一堆 pending 的/api/list或/search?q=xxx，且响应时间波动大，说明 AJAX 是瓶颈，关特效没用 - 注意：某些 UI 库（如 Ant Design、Element Plus）默认开启
transition+will-change，小数据量不显，一上真实列表立刻卡
关闭 Chrome/Firefox 里「看起来很酷」但真卡的 CSS 特效
不是所有动画都该关，而是关掉那些浏览器无法用 GPU 加速、又高频触发重排的。比如 opacity 和 transform 本身轻量，但加在 position: relative + 大量子元素的容器上，就会让合成层失效。
实操建议直接改 CSS，别依赖 JS 控制开关：
- 全局禁用过渡：加一条
* { transition: none !important; animation: none !important; }到开发环境样式末尾，立竿见影测效果 - 重点盯住
box-shadow、filter: blur()、backdrop-filter—— 这些在中低端设备上每帧都要重绘整个区域，比多 10 个 DOM 节点还伤 - 用
transform: translateZ(0)或will-change: transform强制提升图层？小心反效果：Chrome 会为每个加了它的元素单独建合成层，内存暴涨反而拖慢
AJAX 加载慢，光关特效没用，得动请求逻辑
用户点一下就发 5 个 GET /user/profile、GET /user/permissions、GET /user/notifications，再串行等，卡是必然的。优化核心不是“少发”，而是“发得更聪明”。
常见错误：用 async/await 串行写法硬等每个接口返回；或把所有 fetch 放 Promise.all 里，结果一个超时全挂。
- 合并请求：后端提供
/user/summary接口，一次返回 profile + permissions + notifications，前端少 2 次 RTT - 取消冗余请求：用户快速切换 Tab 时，前一个
fetch还没回来，新请求已发，老请求必须AbortController主动 abort，否则它还在后台占连接、吃内存 - 防抖搜索：输入框
input事件里，别每次打字都调fetch('/search?q='+val)，用setTimeout+clearTimeout控制最小间隔（比如 300ms） - 缓存策略：对不变或低频变的数据（如省市区列表），加
cache: 'force-cache'或用localStorage存 10 分钟，别每次都走网络
Vue/React 里“关特效”容易被忽略的底层陷阱
框架层封装了一层又一层，你以为关了 fade 动画就完事，其实 v-if 切换组件、key 反复变化、甚至 useEffect 里没清理定时器，都会让 DOM 批量重建，比 CSS 动画还卡。
尤其要注意 SSR 渲染后客户端激活（hydration）阶段的卡顿，那不是特效问题，是 JS 执行阻塞了渲染线程。
- Vue 中避免在循环里用
v-if控制单个 item 显隐，改用v-show—— 后者只切display，不销毁重建 VNode - React 中别在
map里动态生成key={Math.random()}，key 不稳定会导致整块列表重渲染 - 所有轮询（
setInterval）、事件监听（addEventListener）必须在组件卸载时清理，漏掉一个就可能让已卸载组件持续触发 setState，引发内存泄漏+卡顿 - Chrome DevTools 的
Memory面板拍个堆快照，搜Detached，如果有大量 detached DOM 节点，基本就是事件监听没卸载干净
卡顿从来不是单一原因，关特效或减请求只是表象。真正要盯的是主线程是否被 JS 长任务堵死、合成层是否被滥用、以及每个请求和渲染帧背后的真实开销。这些地方一松动，卡顿就松动。
