前端工程化，从简历上的“熟练”到真正能跑起来
大家好，我是成都某大厂（对，就是百度）的算法工程师，干了两年搜索相关业务。你可能会奇怪：一个写 C++、搞召回排序的人，怎么突然聊起前端工程化了？
其实这事儿挺常见的——我们团队做的是搜索落地页、Query 改写辅助工具、甚至内部 AB 实验平台，这些系统都需要前端界面。去年双11前，产品经理拍着桌子说：“这个实验配置后台必须下周上线！” 我一咬牙，撸起袖子自己上了。结果发现，光会 npm install 和 vue create 根本不够用——本地跑得飞起，CI 一跑就崩；开发环境丝滑如德芙，生产环境白屏到怀疑人生。
于是，我花了整整一个月时间，把前端工程化的链路从头理了一遍。今天这篇，就是血泪教训+实战总结，不为别的，就为了下次跳槽写简历时，“熟悉前端工程化体系”这句话能说得心安理得。
别让“本地能跑”成为你的遮羞布
很多同学（包括曾经的我）觉得：代码能 npm run dev 就行了。但现实是，前端工程化不是“能跑”，而是“可靠地、高效地、可维护地跑”。
我们团队之前就栽过跟头：一个新同事用 vite 搭了个项目，本地调试没问题，推到 GitHub 后 CI 流水线直接报错：
Error: Cannot find module 'postcss'
原来他本地全局装了依赖，但 package.json 里没声明。这种低级错误，在没有标准化工程流程的团队里太常见了。
所以，第一步不是选框架，而是建立统一的工具链契约。
工具链：别再各自为政了
我们最终定了这套组合：
| 环节 | 工具选择 | 理由 |
|---|---|---|
| 构建 | Vite + TypeScript | 快，热更新秒开，TS 强类型兜底 |
| 代码规范 | ESLint + Prettier | 统一风格，减少无意义 PR 争论 |
| 提交检查 | Husky + lint-staged | 阻止脏代码进仓库 |
| 包管理 | pnpm | 快、省空间、依赖扁平 |
| 部署 | GitHub Actions + Docker | 云原生友好，和 K8s 无缝衔接 |
特别说下 pnpm。以前用 npm/yarn，node_modules 动辄几个 G，CI 跑一次缓存失效就得等半天。自从切换到 pnpm，安装速度快了 3 倍不止，磁盘占用也少了一半——对于我们这种经常在笔记本上 coding 的人来说，简直是救星。
GitHub 不只是代码托管，更是工程化中枢
很多人把 GitHub 当成“远程 U 盘”，其实它能干的事多得多。
我们的做法是：所有工程化流程都围绕 GitHub 生态展开。
- 分支策略：
main分支保护，PR 必须通过 CI + 至少 1 人 review - Issue 管理：每个功能/修复对应一个 Issue，PR 关联 Issue
- Release 发版：用 GitHub Releases 打 tag，自动触发部署
最爽的是 GitHub Copilot。虽然它不能代替你思考架构，但在写配置文件时简直是神队友。比如让我写 .github/workflows/deploy.yml，我只要注释一句：
# Build and deploy frontend to staging when push to develop
Copilot 几乎能自动生成完整 workflow。省下的时间，够我多喝两杯瑞幸。
不过也别全信它——有一次它给我生成的 Dockerfile 用了 node:latest，差点在线上搞出兼容性事故。所以 Copilot 是“副驾驶”，方向盘还得自己握紧。
部署流程：从“手动 scp”到“提交即上线”
早期我们部署前端的方式很野：本地 npm run build，然后 scp 到服务器，再 nginx -s reload。有一次半夜线上出问题，运维小哥打电话吼我：“你打包的 JS 文件名又变了！CDN 缓存没刷新！”
痛定思痛，我们搞了一套自动化部署流水线：
- 开发者推送代码到
develop分支 - GitHub Actions 自动：
- 安装依赖（用 pnpm）
- 运行单元测试 & E2E 测试（Cypress）
- 构建静态资源
- 构建 Docker 镜像并推送到私有 registry
- 触发 Argo CD（K8s GitOps 工具），自动滚动更新 staging 环境
- 人工确认后，合并到
main，触发 prod 部署
关键配置片段如下：
# .github/workflows/ci.yml
name: CI
on: [push]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: pnpm/action-setup@v2
- run: pnpm install
- run: pnpm test
- run: pnpm build
- name: Build and push Docker image
run: |
docker build -t ${{ secrets.REGISTRY }}/my-frontend:${{ github.sha }} .
docker push ${{ secrets.REGISTRY }}/my-frontend:${{ github.sha }}
配合 Dockerfile：
FROM node:18-alpine AS builder
WORKDIR /app
COPY . .
RUN pnpm install --frozen-lockfile
RUN pnpm build
FROM nginx:alpine
COPY --from=builder /app/dist /usr/share/nginx/html
COPY nginx.conf /etc/nginx/nginx.conf
EXPOSE 80
这套流程跑通后，我们再也不用担心“在我机器上是好的”这种鬼话了。而且因为用了 K8s，扩容缩容、灰度发布都变得 trivial。
用户体验？性能？别忘了它们！
工程化不只是“让代码跑起来”，更要“让用户爽起来”。
我们在构建阶段加了几个关键优化：
- 按路由拆包：Vite 默认支持 dynamic import，配合 Vue Router，首屏加载快了 60%
- 压缩与缓存：Nginx 配置 long-term caching，JS/CSS 文件名带 hash，避免缓存污染
- Lighthouse 分数监控：CI 中集成 Lighthouse CLI，低于 90 分就 fail
// vite.config.ts
export default defineConfig({
build: {
rollupOptions: {
output: {
manualChunks(id) {
if (id.includes('node_modules')) {
return 'vendor';
}
}
}
}
}
});
另外，浏览器兼容性也不能忽视。我们用 Babel + core-js 按需 polyfill，并在 browserslist 里明确支持范围：
// package.json
"browserslist": [
"> 1%",
"last 2 versions",
"not dead"
]
这样既能覆盖主流用户，又不至于打包一堆无用 polyfill。
写在最后：工程化是团队协作的基石
说实话，搞这套体系花了不少时间。期间被产品经理催进度催到想删库跑路，也被测试同学吐槽“你们前端怎么又改接口”。但当看到新同事第一天入职，clone 仓库、pnpm install、npm run dev 三连击就能跑起项目时，那种成就感，值了。
现在我的简历上终于可以自信地写：“主导前端工程化体系建设，实现从开发到部署的全流程自动化。” —— 而不是“熟悉前端工程化（能跑就行）”。
如果你也在经历类似的混乱，不妨从一个小点开始改造：比如先加上 Husky 提交校验，或者把部署脚本换成 GitHub Actions。积跬步，至千里。
毕竟，好的工程化，不是炫技，而是让团队每天少踩一个坑，多睡一小时觉。
成都的夜晚很安静，凌晨两点，我合上电脑，窗外只有锦江的水声。明天又是新的一天，但至少，我不用再为“本地能跑线上挂掉”而失眠了。
（完）
评论 0