Minified 体积 是指代码经过压缩（移除空格、注释、缩短变量名等）后的大小，是浏览器需要解析的 JavaScript 原始体积。
Gzip 体积 是经过 Gzip 压缩传输后的实际网络传输大小，通常比 Minified 体积小 60-80%。
浏览器下载的是 Gzip（或 Brotli）压缩后的文件，因此 Gzip 体积直接影响用户下载速度，是评估包体积最重要的指标。CDN 和现代服务器默认启用 Gzip/Brotli 压缩。

Tree-Shaking 是打包工具（如 Webpack、Rollup、Vite）的一项优化技术，它会移除未使用的代码（dead code）。
如果包正确配置了 sideEffects: false 并使用 ES Modules，打包工具可以大幅减小最终产物体积。
实际项目中，你往往只使用包的少部分功能，Tree-Shaking 后实际增加的体积可能远小于包的完整体积。本工具显示的体积为包的完整体积，实际增量取决于你的使用方式。

当你安装多个包时，如果它们共享相同的依赖（如多个包都依赖 lodash），npm/pnpm/yarn 会尝试去重，只保留一份副本。
因此，添加一个新包的实际体积增量可能小于该包的独立体积——共享依赖不会重复计算。使用 pnpm 或 npm dedupe 可以最大化去重效果。本工具中的"依赖详情分析"可帮助你识别哪些依赖可能已被项目中的其他包引用。

一般而言，可以参考以下标准（以 Gzip 体积为准）：
🟢 < 10 KB — 优秀，对性能影响极小
🟡 10-30 KB — 可接受，需关注依赖数量
🟠 30-100 KB — 较大，需评估是否必要
🔴 > 100 KB — 沉重，强烈建议寻找更轻量的替代方案
对于移动端或性能敏感的项目，建议将单个第三方包的 Gzip 体积控制在 30 KB 以内。

本工具使用 Bundlephobia 的公开 API，它通过 Webpack + Terser 模拟打包过程来计算体积。
数据包括：Minified 体积（Terser 压缩后）、Gzip 压缩后体积、直接依赖数量及各依赖的近似体积。
这比单纯看源码大小更接近实际打包结果，但仍为近似值——实际项目中的体积受打包配置、Tree-Shaking 效果、依赖版本范围等因素影响。

1. 选择轻量替代品 — 在功能相似的情况下优先选择体积更小的包
2. 按需导入 — 使用具名导入（如 import { debounce } from 'lodash-es'）而非默认导入整个库
3. 利用 Tree-Shaking — 确保使用 ES Modules 格式的包，配置打包工具启用 Tree-Shaking
4. 检查依赖去重 — 运行 npm ls 或 npx depcheck 查找重复依赖
5. 考虑自行实现 — 对于简单功能（如深拷贝、日期格式化），评估是否有必要引入第三方包
6. 使用动态导入 — 对于非首屏必需的包，使用 import() 进行代码分割和懒加载

Scoped Packages 是带有命名空间的 npm 包，格式为 @scope/package-name（如 @angular/core、@babel/runtime）。
它们在体积分析上与普通包没有区别，本工具完全支持查询 Scoped Packages。
在搜索框中直接输入完整名称（如 @angular/core）即可。注意：Scoped Packages 通常是一个大型项目的一部分，单独分析其中一个子包时，实际项目可能同时安装了该 Scope 下的多个包，总体积需要综合考虑。