自动化脚本：前端仔的“偷懒”神器，还是技术债的温床？

去年秋招，我这个杭州某大专院校的计算机应届生，靠着自学前端+啃了几个开源项目源码（比如 Vite、Element Plus），居然在阿里云生态的一家小厂拿下了 offer。说实话，入职第一天看到 GitLab CI/CD 流水线跑得飞起，我内心是懵的——这玩意儿比我写的组件还复杂。

但很快我就体会到自动化脚本的威力了。上周五晚上十点，产品经理突然在钉钉群里@我：“明天上线前能不能把所有图片压缩一下？现在首屏加载太慢了。” 我看了一眼 Lighthouse 报告，Performance 只有 48 分，心里一万个“草”。手动压图？200+张？那不得干到天亮？还好，我早就写了个 Node.js 脚本配合 sharp 库批量处理，10 分钟搞定。那一刻，我真的觉得——自动化，真香！

但也正因为尝到了甜头，我才开始认真思考：我们到底该怎么看待自动化脚本？

---

别被“自动化”三个字忽悠了

刚入职时，我以为自动化脚本就是“写个 JS 跑一下，省事”。结果第一次写部署脚本，直接把测试环境数据库清空了（别问，问就是 rm -rf / 写错路径）。运维大哥黑着脸来找我：“你是不是以为这是本地开发机？” 我当场社死。

后来才明白：自动化不是目的，而是手段。它的价值在于“可重复、可验证、可回溯”的流程提效。如果你只是为了“偷懒”而写脚本，那它迟早会反噬你——变成没人敢碰的“祖传代码”，一旦出问题，整个团队都得陪你加班。

我在参与的一个 SaaS 产品项目中就吃过亏。早期为了快速上线，用 Shell 脚本拼凑了一套发布流程：拉代码 → 安装依赖 → 构建 → 上传 OSS → 清 CDN。看起来没问题，但每次换人维护都得花半天搞懂逻辑。更糟的是，有一次构建失败，脚本没做异常捕获，直接静默跳过，导致线上跑的是旧版本。产品经理差点把我挂工位上。

那次事故后，我们痛定思痛，决定用 JavaScript 重写整套自动化流程。为什么选 JS？很简单：我们是前端团队，Node.js 生态熟，调试方便，还能复用项目里的工具函数。

---

用 JavaScript 写脚本，真的稳吗？

很多人觉得：“脚本嘛，Python 或 Shell 就够了，干嘛非要用 JS？” 这话在纯后端场景可能成立，但在前端主导的项目里，JS 反而是最顺手的选择。

举个例子：我们产品有个需求——每次发版前自动从 Figma 提取最新设计稿的颜色变量，生成 SCSS 文件。如果用 Python，得额外装 requests、解析 JSON、处理异步……而用 Node.js，直接 fetch + fs.promises.writeFile，50 行搞定：

// scripts/generate-theme.js
import { writeFile } from 'fs/promises';
import fetch from 'node-fetch';

const FIGMA_TOKEN = process.env.FIGMA_TOKEN;
const FILE_KEY = 'your-figma-file-key';

async function extractColors() {
  const res = await fetch(
    `https://api.figma.com/v1/files/${FILE_KEY}/styles`,
    {
      headers: { 'X-Figma-Token': FIGMA_TOKEN }
    }
  );
  const data = await res.json();
  
  // 假设只处理颜色样式
  const colors = {};
  for (const style of data.meta.styles) {
    if (style.style_type === 'FILL') {
      const hex = rgbToHex(style.paints[0].color);
      colors[style.name] = hex;
    }
  }

  let scssContent = '// Auto-generated by figma-sync script\n';
  for (const [name, value] of Object.entries(colors)) {
    scssContent += `$${name}: ${value};\n`;
  }

  await writeFile('src/styles/_theme.scss', scssContent);
  console.log('✅ Theme SCSS updated!');
}

function rgbToHex({ r, g, b }) {
  return `#${Math.round(r * 255).toString(16).padStart(2, '0')}${Math.round(g * 255).toString(16).padStart(2, '0')}${Math.round(b * 255).toString(16).padStart(2, '0')}`;
}

extractColors().catch(console.error);

这脚本不仅能跑，还能被 Jest 测试！我们甚至把它集成到 package.json 的 prebuild 钩子里：

{
  "scripts": {
    "prebuild": "node scripts/generate-theme.js",
    "build": "vite build"
  }
}

关键点在于：脚本和项目技术栈一致，团队成员都能看懂、能改、敢改。这比丢一个 .sh 文件在角落强太多了。

---

自动化 ≠ 无脑堆脚本

但我也见过反面教材。有次 review 代码，发现同事写了 3 个脚本干同一件事：一个用于本地调试，一个用于 CI，一个用于生产回滚。逻辑大同小异，但参数配置分散在各处。问他为啥不合并？他说：“怕改坏线上。”

这就是典型的“自动化内卷”——为了规避风险，反而制造了更多技术债。

我的经验是：脚本也要遵循软件工程原则。比如：

• 单一职责：一个脚本只做一件事（如“压缩图片”、“同步文档”）
• 可配置：通过 .env 或命令行参数控制行为，别硬编码
• 可观测：加日志、加错误提示，最好接入 Sentry
• 可测试：核心逻辑抽成函数，写单元测试

我们现在的脚本目录结构长这样：

project-root/
├── scripts/
│   ├── utils/
│   │   └── logger.js        # 统一日志格式
│   ├── compress-images.js   # 带单元测试
│   ├── deploy.js            # 支持 --env=prod|test
│   └── sync-docs.js
└── tests/
    └── scripts.test.js

连实习生都能安全地修改脚本，因为有测试兜底。

---

性能优化？脚本也能帮忙！

作为对性能优化有点执念的人，我发现很多优化其实可以通过脚本前置完成。比如：

• 自动生成 WebP 格式图片（节省 30% 体积）
• 静态资源 hash 命名 + 强缓存
• 删除未使用的 CSS 类（借助 PurgeCSS）

这些操作如果手动做，效率低还容易漏。但写成脚本后，每次构建自动执行，Lighthouse 分数从 50+ 直接飙到 85+。

下面是我们用 esbuild + 自定义插件实现的资源预处理脚本片段：

// vite.config.js 中的插件
export default defineConfig({
  plugins: [
    {
      name: 'auto-webp',
      enforce: 'post',
      async generateBundle(options, bundle) {
        for (const fileName in bundle) {
          if (/\.(jpg|png)$/.test(fileName)) {
            const source = bundle[fileName].source;
            const webpBuffer = await sharp(source).webp().toBuffer();
            this.emitFile({
              type: 'asset',
              fileName: fileName.replace(/\.\w+$/, '.webp'),
              source: webpBuffer
            });
          }
        }
      }
    }
  ]
});

虽然只是几十行代码，但它让产品在弱网环境下首屏快了近 1 秒。产品经理终于不再天天催“能不能再快点”。

---

写脚本的心态：别把自己当“工具人”

最后说点掏心窝子的话。作为大专出身的前端，我一度觉得自己只能干“切图仔”的活。但自从开始研究开源项目的构建脚本（比如 Vite 的 bin/vite.js 是怎么启动 dev server 的），我才意识到：脚本能力其实是工程师掌控力的体现。

你写的每一行自动化代码，都在定义团队的工作流。它决定了你们是每天手动点按钮，还是喝着咖啡等 CI 自动跑完。

当然，也别走极端。见过有人为了“全自动”写了个脚本监控老板钉钉消息，收到“上线”关键词就自动部署……结果老板只是在群里开玩笑。第二天他就去 HR 那报到了。

所以我的态度很明确：

能自动化的，坚决不手动；但该人工确认的，一步都不能省。

自动化脚本不是魔法，它只是把你的经验固化成代码。而写代码的人，永远要比代码聪明。

---

附：我们项目中常用脚本效果对比

脚本类型	手动耗时	自动化耗时	错误率	团队满意度
图片压缩	45 分钟	3 分钟	12%	😄😄😄
文档同步（Confluence）	20 分钟	1 分钟	8%	😄😄
环境变量校验	无	5 秒	降低 90%	😄😄😄😄
发布回滚	15 分钟	2 分钟	5% → 0.5%	😄😄😄😄😄

数据不会骗人。当你把重复劳动交给机器，人才能去做真正需要创造力的事——比如，思考下一个脚本该怎么写。

---

写这篇文章的时候，我刚 fix 了一个脚本里的 race condition bug。虽然凌晨两点眼皮打架，但想到明天同事不用再手动处理那堆 CSV 文件，就觉得值了。

毕竟，好的自动化，不是让你少干活，而是让你干更有意思的活。

（完）