Source Map 体积分析器

这些字节到底去哪了？

一个生产环境打包文件就是一个巨大的压缩文件。知道它有 340 KB 并不能说明原因——而这恰恰是你想压缩体积时真正关心的问题。本工具直接给出答案：加载打包文件及其 .map 文件，每个字节都会被归属到产生它的原始源模块。

归属是如何计算的

Source map 的映射条目会说"生成后第 4110 列来自 src/utils/format.js"。本工具按顺序遍历文件中的每一条映射，测量它与同一生成行中下一条映射之间的间隔——这段间隔就被记入该映射所属源码的账下。这与知名命令行工具 source-map-explorer 所用的行级近似方法完全相同，而且工具坦诚这只是一种近似：同一生成行上两个相邻词元之间若没有任何映射（多余的空白、压缩工具插入的字符），会被归入独立的未映射类别，而不是被悄悄记到旁边某个源码头上。

结构性字节——生成行之间的换行符——出于同样的原因也拥有自己的类别：它们属于文件的结构，而非任何具体模块。

核对检查

每次运行都会展示一个明确的结果：共 X 字节被归属，总计 Y 字节，以及未映射和结构性字节的数量，还有"已归属 + 未映射 + 结构性"是否恰好等于文件总长度。这不是装饰性细节——它是"没有任何字节被悄悄丢失或重复计算"的保证，你可以自行验证，而不必单凭工具的一面之词。

按文件或按文件夹

可在"每个源文件一行"与"按顶层文件夹汇总"之间切换——node_modules/lodash 会把 lodash 贡献的所有文件加总起来，让你无需先翻过四十个单独文件，就能看到"这一个依赖到底花了多少体积"。所有结果均按体积从大到小排序，导出的 CSV 也保留同样的数字，便于后续分析。

隐私

两个文件都完全在你的浏览器中读取和处理，不会上传到任何地方。