stacktrace-js get方法sourceCache非空引发性能下降、内存升高问题咨询

那句"Pre-populate source cache to avoid network requests"实际指向组件的默认运行逻辑：

• 当stacktrace-js解析堆栈、需要还原行号、列号对应的原始源码位置时，默认会根据堆栈帧里记录的文件路径，主动发起网络请求拉取对应的JS文件、甚至关联的sourcemap文件完成解析
• 所谓预填充source cache，就是让你提前把这些需要用到的源码、sourcemap文本内容，以「文件路径-文本内容」的键值对形式传入sourceCache参数
• 搭配offline: true配置时，组件会完全禁止向外发起任何网络请求，所有解析需要的源码内容只能从你传入的sourceCache中获取，找不到的文件会直接标记为解析失败

这个问题是stacktrace-js内部实现的固有特性，既然已经排除了回调逻辑的影响，性能异常基本来自以下几个可复现的实现缺陷：

• 组件对传入的sourceCache没有做内存边界控制：没有LRU之类的自动淘汰机制，只要你把内容传进去，就会一直常驻在JS堆内存里直到页面卸载。很多开发者踩坑时会把全站所有JS、全量sourcemap都塞进缓存，单文件几MB到十几MB的文本堆在一起，自然会让浏览器监测到的常驻内存大幅上涨。
• 每次解析堆栈的遍历逻辑没有做索引优化：组件在匹配当前堆栈帧对应的源码内容时，会全量递归遍历整个sourceCache对象做键名匹配，没有做哈希索引加速。如果你存了几十上百个缓存条目，哪怕每次只匹配1个文件，每次StackTrace.get调用都要跑完全量遍历；如果你的堆栈本身包含几十上百帧，累计的CPU计算开销会非常明显，直接表现为页面运行卡顿、交互掉速。
• 常见的传参格式踩坑：部分开发者传sourceCache时，没有把value转成纯字符串格式的源码内容，反而把整个webpack模块导出对象、带循环引用的业务对象当缓存值塞进去，会触发V8引擎的对象深拷贝、内存泄漏逻辑，进一步放大内存占用。

• 严格控制sourceCache的填充范围：只存业务堆栈实际会出现的文件对应的源码文本，不要为了省事把全量源码、全量sourcemap一股脑塞进去；缓存的键名必须和堆栈帧里记录的文件URL路径完全匹配，value必须是纯字符串，不要存非原始类型的对象。
• 减少不必要的StackTrace.get调用频率：业务侧可以对已经解析过的堆栈结果做短时间缓存，避免同一段堆栈反复触发解析逻辑。
• 如果确实需要大体积的缓存内容，可以自行封装一层Map结构做键值映射，减少组件内部全量遍历的开销，同时控制总缓存体积在1MB以内，避免常驻内存过高影响页面体验。

内容的提问来源于stack exchange，提问作者yaminoyuki