Release发布流程中的自动化部署与版本控制实践

优化前：卡得不行

上个月上线一个新功能，用户反馈“点发布按钮后页面直接卡死，等了五六秒才跳转”。我一开始以为是后端接口慢，结果打开 DevTools 一看，Network 面板里 API 响应其实就 200ms，但整个页面从点击到响应完成花了快 5 秒。更离谱的是，手机上直接白屏，部分低端机甚至直接崩了。

这哪能忍？我本地跑起来一测，Chrome Performance 面板里满屏的红色长任务（Long Task），主线程被占得死死的。用户点一下，浏览器要处理一堆没必要的计算、渲染和内存分配，卡成 PPT 是必然的。

找到瓶颈了！

我先用 Chrome DevTools 的 Performance 录了一次完整的发布流程。关键发现：

• 一次点击触发了 3 次全量数据序列化（JSON.stringify）
• 表单校验逻辑在提交时同步执行了 10+ 个复杂正则，还嵌套了循环
• 有个隐藏的富文本编辑器组件在每次状态更新时都重新渲染整个内容区
• 所有图片资源都是原图直传，没做压缩，总大小超 8MB

最要命的是，这些操作全塞在主线程里同步执行，用户点完就只能干等。我试过加 loading，但治标不治本——主线程堵死了，loading 动画都卡帧。

核心优化：拆、懒、缓、压

折腾了两天，最后靠四个字搞定：拆、懒、缓、压。下面说重点。

1. 拆：把同步大任务切成小块

原来那段 JSON 序列化代码是这样的：

const payload = JSON.stringify({
  content: editor.getContent(),
  metadata: buildMetadata(),
  attachments: processAttachments(attachments)
});

问题在于 processAttachments 会遍历所有附件做 base64 转换，附件一多就卡。我改用 Web Worker 异步处理：

// worker.js
self.onmessage = (e) => {
  const { attachments } = e.data;
  const processed = attachments.map(file => ({
    name: file.name,
    data: arrayBufferToBase64(file.arrayBuffer)
  }));
  self.postMessage(processed);
};

// main.js
function processAttachmentsAsync(attachments) {
  return new Promise((resolve) => {
    const worker = new Worker('/worker.js');
    worker.postMessage({ attachments });
    worker.onmessage = (e) => {
      resolve(e.data);
      worker.terminate();
    };
  });
}

这样主线程不再阻塞，用户点完按钮立刻有反馈，后台慢慢处理数据。

2. 懒：延迟非关键操作

富文本编辑器那个坑我踩过好几次。之前每次 state 变化都触发全量 rerender，其实用户根本没在看它。现在改成只在聚焦时才激活完整编辑器，其他时候用静态预览：

// React 示例
const [isEditorActive, setIsEditorActive] = useState(false);

return (
  <div onClick={() => !isEditorActive && setIsEditorActive(true)}>
    {isEditorActive ? (
      <RichTextEditor value={content} onChange={setContent} />
    ) : (
      <div className="rich-text-preview" dangerouslySetInnerHTML={{ __html: content }} />
    )}
  </div>
);

发布页默认不激活编辑器，省下一大笔渲染开销。

3. 缓：避免重复计算

表单校验那堆正则，原来每次 submit 都重新跑一遍。其实规则是固定的，我就用 useMemo 缓存校验函数：

const validators = useMemo(() => ({
  email: (val) => /S+@S+.S+/.test(val),
  phone: (val) => /^1[3-9]d{9}$/.test(val),
  // ... 其他 10 个规则
}), []);

// 提交时直接调用 validators.xxx(val)

另外，像 buildMetadata() 这种纯函数，只要输入不变输出就不变，我也加了记忆化：

const buildMetadata = useCallback(memoize((user, project) => {
  // 复杂计算逻辑
}), []);

4. 压：图片必须压缩

前端直接传原图太奢侈了。我在上传前用 canvas 压缩图片：

function compressImage(file, quality = 0.7) {
  return new Promise((resolve) => {
    const img = new Image();
    img.src = URL.createObjectURL(file);
    img.onload = () => {
      const canvas = document.createElement('canvas');
      const ctx = canvas.getContext('2d');
      canvas.width = img.width * 0.5;
      canvas.height = img.height * 0.5;
      ctx.drawImage(img, 0, 0, canvas.width, canvas.height);
      canvas.toBlob(resolve, 'image/jpeg', quality);
    };
  });
}

实测 5MB 的图压到 300KB 左右，上传时间从 3s 降到 300ms，而且肉眼几乎看不出差别。

次要优化：顺手修的几个小毛病

还有一些零碎问题，虽然不致命但也顺手改了：

• 移除了 console.log（生产环境别留这个，有些机型会拖慢速度）
• 把非首屏的 CSS 拆成异步加载
• API 请求加了防抖，避免用户狂点按钮发多次请求

这些改动不大，但积少成多，整体体验更稳了。

性能数据对比

优化前后实测数据（中端安卓机 + Chrome）：

最直观的感受是：现在点发布按钮，页面立刻有 loading 反馈，1 秒内就跳转成功页。用户再也不用怀疑是不是点没点上。

还有点小遗憾

其实 Web Worker 那块还能再优化——现在每次都要新建 worker，其实可以复用。但项目时间紧，先保证主流程流畅再说。另外图片压缩在低端机上偶尔还是有点卡，后续考虑用 WebAssembly 替代 canvas。

但说实话，做到现在这样，95% 的用户已经感觉不到卡顿了。有时候优化不是追求完美，而是让问题消失在用户感知之外。

以上是我对 Release 发布流程的性能优化实战，核心就是别让主线程干太多活。有更好的方案欢迎评论区交流，比如你们怎么处理大文件上传的？我还在找更优雅的方案。