JS 文件膨胀到 1M 怎么办？教你几招拯救屎山代码

最近看到有个朋友在吐槽：“本来只想写个简单的程序，结果一不小心 JS 文件就快 1M 了，这屎山代码越写越大，简直没法管。”

相信很多前端开发者在项目周期拉长后，都会遇到这种焦虑。明明功能没增加多少，打包出来的文件体积却像吹气球一样膨胀。特别是对于个人项目或者小团队，缺乏严格的代码审查，依赖越堆越多，最后导致加载变慢，用户体验下降。

别慌，文件大不代表就是烂代码，但肯定是有优化空间的。今天我们就来聊聊，面对这种“巨石”般的 JS 文件，我们该从哪里下手抢救。

1. 找出谁是“罪魁祸首”

在动手删代码之前，先搞清楚是谁占用了这么大空间。千万不要凭直觉去猜。

利用构建工具的分析插件（比如 webpack-bundle-analyzer 或 rollup-plugin-visualizer）生成一张可视化图表。通常你会惊讶地发现，自己以为很小的库，其实体积惊人。比如你只是用到了某个 UI 库里的一个按钮组件，结果打包时把整个组件库都引进来了。或者是为了方便，直接引入了 Lodash 全家桶，却只用了一两个函数。

对症下药才能药到病除，这一步不可或缺。

2. 依赖瘦身与 Tree Shaking

找到大块头依赖后，下一步就是做减法。

• 按需引入：如果是组件库或工具库，查阅文档，确保只引入你需要的那个模块。现在主流的 UI 库都支持 ES Module 按需引入。
• 开启 Tree Shaking：现代打包工具都支持 Tree Shaking（摇树优化），它能自动剔除你代码里没用到的部分。但这有个前提：你的依赖和代码必须使用 ES6 模块语法（import/export），而不是 CommonJS。检查一下你的配置和引入方式，确保这个功能是开启的。
• 寻找轻量替代品：有些库确实设计得很重。如果只是简单操作，能不能用原生 API 实现？或者是找找更专注、更轻量的替代库？比如 moment.js 就经常被 day.js 这种更小的库取代。

3. 代码分割：不要把鸡蛋放在一个篮子里

如果优化完依赖，主文件依然很大，那就要考虑拆分了。这就是所谓的 Code Splitting。

不要把所有代码都打到一个 app.js 里。你可以利用路由进行懒加载。用户没访问到的页面，对应的代码就不加载。这对于单页应用（SPA）来说尤为有效，能极大地提升首屏加载速度。

对于一些不那么关键的功能模块，比如弹窗组件、或者是非首屏的图表库，可以设置成异步加载。先把核心业务跑起来，剩下的慢慢加载。

4. 给资源“上压缩”

代码层面的优化做好了，最后别忘了传输层面的优化。

• 开启 Gzip 或 Brotli 压缩：这是性价比最高的优化手段。一般服务器配置开启后，JS 文本的传输体积能减少 70% 以上。1M 的文件，压缩后可能只需要传输 200KB。
• 混淆与压缩：生产环境打包时，利用 Terser 等工具去除空格、注释、缩短变量名。虽然这对体积的缩减不如压缩算法来得猛烈，但也是必不可少的一环。

写在最后

代码膨胀是软件工程中的“熵增”，几乎是不可避免的。遇到 1M 的 JS 文件不用过于恐惧，但这确实是一个提醒信号：你的架构可能需要重构了。

定期审视打包产物，保持对依赖的敬畏，该拆分时拆分，该替换时替换。把这些习惯融入开发流程，就能让项目保持健康，避免变成无法维护的“屎山”。