杭州滨江开发者复盘：一次把构建时间砍掉七成的实战

滨江「墨砾网络」的前端仓库，一次npm run build要四十八秒。开发者老周每次改完样式等构建，顺手去接杯水，一天接八回，水没少喝，活没多干。他忍了三个月，终于在六月的一个雨天决定动刀。

第一步他把webpack换成了vite。别被文档吓到，迁移只改了配置文件，源码一行没动。构建从四十八秒掉到十九秒。老周说那天他少接了五杯水。

真正的大头在依赖

我们帮他跑了一次npm analyze，发现lodash整个被打进包里，而他只用到了debounce和throttle两个函数。改成按需引入后，包体积从912KB掉到240KB，构建再掉三秒。

第二个坑是sourcemap。生产构建他一直开着完整map，每次多花六秒还泄源码。关掉之后构建十二秒。三次改动叠起来，四十八秒到十二秒，砍掉七成五。

说白了，构建慢十有八九是依赖和配置的问题，不是你代码写得丑。老周后来把这套流程写进团队规范，新项目默认vite加按需引入，新人入职第一天就跑通。

杭州城西一家「砚台科技」更狠。他们把CI里的构建缓存打开，第二次构建只花四秒——因为没改的模块直接读缓存。一个月省下的流水线时长，折算云费用少了大概一千一百块。

给杭州小团队的三条实在建议

一，本地用vite，别死守webpack的老配置。二，依赖按月审，用npm dedupe清掉重复包。三，CI一定开缓存，这是最便宜的提速。墨砾网络照做之后，发布从每天两次提到每天六次，产品那边催得也没那么凶了。

别天真，工具换完不是终点。老周现在每周看一次构建报表，谁的提交让构建涨了，立刻找人聊。把优化变成习惯，比一次性折腾管用得多。

我们还帮老周接了个本地脚本，提交前自动跑eslint和构建计时，数字写进commit message。团队七个人，头两周还有人嫌烦，一个月后没人愿意回到四十八秒的年代。习惯这东西，养成了就回不去。

顺带说个数据：墨砾网络优化前每月因等待构建浪费的工时约三十六小时，优化后降到九小时。按杭州前端均价算，相当于每月省出两千块的人力。这笔账，老板比谁都清楚。