console.profile() 结合火焰图是定位 cpu 耗时热点最轻量可控的方式；需手动包裹目标逻辑、关注宽条/深栈/密集窄条，再通过 call tree 区分 self/total time，最后逐点验证优化。
直接用 console.profile() 触发采样，再结合开发者工具里的火焰图（Flame Chart），是定位复杂业务逻辑中 CPU 耗时热点最轻量、最可控的方式之一。它不依赖构建配置，也不需要重启应用，适合在开发调试阶段快速圈定问题范围。
明确 profile 的起止边界
复杂业务逻辑往往分散在多个函数调用链中，盲目全局录制会导致数据噪音大、关键路径被稀释。应主动包裹目标逻辑：
- 在业务入口前加
console.profile('checkout-flow') - 在逻辑结束处加
console.profileEnd('checkout-flow') - 确保前后标签名一致，否则 Chrome 会报错或忽略结束标记
- 避免嵌套同名 profile，否则可能提前截断或合并错误
录制后优先看 Flame Chart 的“宽条”和“深栈”
打开 DevTools → Performance 面板 → 点击录制 → 执行业务操作 → 停止录制 → 切换到 Flame Chart 标签页。此时重点关注：
Twitter热点监控与推文生成
下载
每小时自动在推特搜索中国、加密货币、国际热点、美国热点、特朗普等话题的热度信息，提取前十热点，依据 X 平台真实算法权重（开源代码数据）为每个热点生成高曝光推文或线程。用户提及“推特热点”“Twitter热点”“推特搜索”“热点推文”“生成推文”“社交媒体监控”“Twitter监控”等关键词时触发。
- 横向最宽的矩形条：代表单次执行耗时最长的函数（不是调用次数多，而是单次慢）
-
纵向最深的调用栈：从底部（如
onClick）一直延伸到顶部某工具函数，说明该路径层层透传、未做裁剪或缓存 -
重复出现的同名窄条密集堆叠：可能是循环内高频调用的小函数，比如
formatDate被调用 200 次，每次 0.5ms，总耗时就达 100ms
结合 Call Tree 定位具体方法归属
Flame Chart 直观但不够结构化。点击任意宽条后，在右侧面板切换到 Call Tree，按 Total Time 降序排列：
- 找到 Total Time 最高的方法，展开其子节点，看耗时是否集中在某个深层依赖（如第三方 SDK 的序列化逻辑）
- 注意区分
Self Time和Total Time：Self Time 高，说明该函数自身计算重；Total Time 高但 Self Time 低，说明它只是个“中转站”，真正耗时在它调用的下游 - 若看到大量
anonymous或<self></self>，说明代码经过打包压缩或使用了箭头函数/立即执行函数，可临时开启 source map 或加命名函数辅助识别
验证与收敛：改一行，测一次
不要试图一次性优化整个调用链。锁定一个高耗时节点后，用最小改动验证效果：
- 对高频小函数加记忆化（
memoize）或提前返回 - 将同步遍历改为异步分片（
setTimeout或queueMicrotask）防止主线程阻塞 - 移除冗余的深克隆、JSON 序列化/反序列化操作
- 每次修改后重新跑一遍
console.profile()录制，对比 Flame Chart 中对应区域宽度是否明显收窄
