sublime text 不运行 webpack，但能高效辅助分析体积问题：快速打开格式化 stats.json、搜索模块路径、对照 bundle-report.html 定位源码、批量检查重复依赖与无效引入，并结合 webpack.config.js 验证优化效果。
Sublime Text 本身不运行 Webpack，也不能直接启动 webpack-bundle-analyzer，但它能高效辅助你“读透”分析结果、快速定位体积问题。关键不是把它“集成”进 Sublime，而是用好它的编辑能力配合分析流程。
打开并快速扫描 stats.json 文件
Webpack Bundle Analyzer 的核心输入是 stats.json（或生成的 bundle-report.json），而 Sublime 加载大 JSON 文件快、支持折叠/搜索/高亮，比浏览器 DevTools 或 VS Code 更轻量。
- 构建时务必开启
generateStatsFile: true，并确保stats配置包含modules和chunks字段（否则看不到模块级体积） - 用 Sublime 打开
stats.json后，按Ctrl+Shift+P→ 输入 “JSON Reindent” 格式化（若已装插件），再用Ctrl+F搜"size":或具体模块名（如"node_modules/moment"） - 重点关注
assets里.js文件的size，以及modules中重复出现、体积异常大的条目（比如多个lodash版本或整包element-ui）
对照 bundle-report.html 定位具体源码位置
bundle-report.html 提供可视化树状图，但鼠标悬停只显示模块路径（如 ./src/views/Home.vue 或 node_modules/axios/index.js），真正要改代码还得回到编辑器。
- 在报告中点击某个大色块，看右下角显示的完整路径；复制路径（去掉
node_modules/前缀或处理别名）后，在 Sublime 中用Ctrl+P快速跳转到对应文件 - 如果是 Vue 组件体积过大，检查是否引入了未使用的子组件、是否用了
import xxx from 'xxx'而非按需导入（如import { Button } from 'ant-design-vue'） - 若路径含
webpack/runtime或webpack/compiled，说明是 Webpack 运行时代码膨胀，需检查SplitChunksPlugin配置是否合理，而非改业务代码
用 Sublime 批量检查重复依赖和无效引入
体积问题常源于重复安装、全量引入、开发依赖泄露。Sublime 的多行选择和正则搜索能快速扫出这些痕迹。
- 在项目根目录用 Sublime 打开所有
package.json（包括子包），搜"lodash":或"moment":，确认是否多个版本共存（npm ls lodash只能查顶层，容易漏） - 全局搜
import.*[\"']vue-i18n[\"']（正则模式），看是否在非必要地方全量引入了 i18n —— 实际只需语言包时，应改为动态 import 或 CDN 引入 - 搜
console.log、debugger、mock等关键词，确认它们没混进生产构建（尤其注意process.env.NODE_ENV === 'development'是否被正确 tree-shaken）
配合 webpack.config.js 快速验证优化效果
每次改完配置或代码，都需要重新构建并对比体积。Sublime 可以同时打开 webpack.config.js 和刚生成的 stats.json，边调边看。
- 调整
optimization.splitChunks时，关注chunks字段里新生成的vendor或commonchunk 大小变化，而不是只盯着main.js - 启用
sideEffects: false后，用 Sublime 在node_modules对应包里搜require(或__webpack_require__，确认没有动态 require 导致 tree-shaking 失效 - 改完后不要只看总大小，用 Sublime 对比两份
stats.json的assets数组，重点看 gzip 后体积（gzipSize字段）是否真实下降
真正卡住体积优化的，往往不是工具不会用，而是没看清 stats.json 里哪一行 module 占了 300KB，也没意识到 import('@/components/BigChart.vue') 其实拖进了整个 ECharts。Sublime 不提供自动化，但它让你一眼看到真相——这点比任何花哨的 GUI 都实在。
