如何在 CI 中集成 Wasm 体积预算检查

上个月我们团队差点被一个Wasm模块坑惨了。本来是想用Rust重写图像处理算法提升性能，结果打包后发现这个.wasm文件居然有8MB！要不是测试环境网速快，用户那边首屏加载时间直接爆炸。从那以后我就意识到，在CI流程里集成Wasm体积检查太重要了。

为什么要在CI里做这个检查？

说实话，Wasm体积膨胀真的太容易发生了。你加个依赖、多用几个标准库函数，或者忘记打开编译优化，分分钟给你整出个几MB的庞然大物。而且这玩意儿不像JS bundle，用户没法按需加载，必须一次性下载完才能执行。

我们现在的做法是在git push触发构建时自动检查Wasm文件大小。如果超过预设阈值，就直接让构建失败，开发想合并代码都合不了。

具体怎么操作？

我们用的是GitLab CI，配置起来其实特别简单。在.gitlab-ci.yml里加这么一段：

wasm_size_check:
  stage: test
  script:
    - wasm_size=$(stat -f%z pkg/my_module_bg.wasm)
    - if [ $wasm_size -gt 1048576 ]; then
        echo "Wasm文件超过1MB预算！当前大小: $wasm_size bytes"
        exit 1
      fi

这个检查跑得特别快，就几秒钟的事。但我们团队因为这个检查，已经拦住了三次体积超标的问题。

预算阈值怎么定？

刚开始我们也很纠结该设多大。后来发现一个很实用的方法：先看当前线上版本的Wasm文件大小，然后根据性能要求设定一个合理的增长空间。比如我们现在的版本是800KB，那就设个1MB的阈值，给未来留点余地。

有时候特定功能确实需要更大的体积，我们就会在CI配置里做例外处理：

# 特殊功能模块可以单独设置预算
if [[ "$CI_COMMIT_MESSAGE" == *"feature: advanced-filter"* ]]; then
  MAX_SIZE=2097152  # 2MB
else
  MAX_SIZE=1048576  # 1MB
fi

实战中的小技巧

我们摸索出几个特别管用的优化方法。首先是用wasm-opt做二次优化，这工具能把Wasm文件再压缩个15%-20%，简直神奇。

还有就是一定要用wasm-pack build --release，开发模式下编译出来的文件能大好几倍。

最让我惊喜的是，我们在CI流程里加了个自动报告，每次构建都会把Wasm文件大小变化趋势图发到Slack频道里。现在团队里谁要是把体积搞大了，自己都不好意思。

现在每次看到CI检查通过的那个绿色对勾，心里就特别踏实。毕竟用户可不会管你用了多牛的技术，加载慢了他们扭头就走。