性能优化应先用Chrome Performance面板定位瓶颈：FPS低说明Layout/Paint过重，红色Long Task表明JS阻塞，高layout强度暴露强制重排；再依指标选策略——首屏卡顿用时间分片，滚动掉帧改固定高度+虚拟滚动，内存上涨查泄漏；最后量化验证首屏耗时≤100ms、平均FPS≥45、内存不持续增长。
直接看性能数据，再针对性改渲染逻辑，比凭感觉调优可靠得多。关键不是“怎么快”，而是“哪里慢、为什么慢、改哪最值”。
用 Performance 面板抓真实瓶颈
打开 Chrome DevTools → Performance → 点击录制 → 滚动长列表或触发渲染 → 停止。重点盯三块：
- FPS 曲线掉到 30 以下：说明渲染帧不稳，大概率是 Layout 或 Paint 过重，比如每项高度不一却没缓存、滚动中频繁读取 offsetHeight
- 红色 Long Task（>50ms）：主线程被 JS 占满，常见于一次性遍历上万条数据做 map/filter、在 render 函数里同步计算样式
- Main Thread 中 layout 强度高：看 Call Stack，如果大量出现 Recalculate Style 或 Layout，说明 DOM 结构或样式写法触发了强制重排
从指标反推渲染策略选型
不同性能问题对应不同解法，不能一上来就上虚拟滚动：
Java 接口排错助手
下载
在调试 Java 后端 API 故障时使用此技能，尤其适用于以下任务：分析日志、跨 Controller、Service 和 Mapper 层追踪请求、定位异常根因、检查 SQL 执行或参数流转，以及生成简洁的诊断结论与修复方案。
- 若 FPS 正常但首屏卡顿（Long Task 明显）→ 优先用 时间分片 拆分数据处理，比如把 10000 条数据的格式化拆成每 50 条一组，用 requestIdleCallback 逐步执行
- 若 FPS 波动大、滚动掉帧严重（Layout 占比高）→ 检查是否用了 flex-wrap、table 布局或未设 height 的子元素；改用固定高度 + 虚拟滚动，避免渲染不可见项
- 若内存曲线随滚动持续上涨 → 查 Heap Snapshot，大概率是事件监听没清理（如 scroll 回调里闭包引用了整个列表数据），或虚拟滚动中重复创建 DOM 节点未复用
优化后必须量化验证
每次改动后重新录制对比，只看三个数字：
- 首次渲染耗时：从数据传入到可视区域内容出现的时间，目标是 ≤ 100ms
- 滚动平均 FPS：稳定在 55–60 最理想，低于 45 就要继续调
- 峰值内存增长：滚动到底部再回滚，内存应回落，不持续爬升
别信“看起来顺滑”，数据不达标，优化就没到位。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
