安装 vite 和相关插件

从“能跑就行”到“可持续交付”：我的前端工程化实践之路

刚入行做前端开发的时候，我干过一件现在回想起来挺尴尬的事。那会儿我们团队赶着上线一个促销页面，我在本地把代码写完打包丢给后端部署，结果用户打开页面后样式错乱、JS报错满天飞。后来查了才发现——本地开发用的现代语法在某些低端浏览器上直接跪了，而且没有做兼容处理，连错误日志都没有留下。

那一刻我就意识到：前端开发早已不再是简单地写出能跑的页面，而是要构建一套可持续交付、质量可控、可维护的工程体系。尤其对于我们这种用户体量大的互联网公司来说，一次线上事故可能带来的影响是非常巨大的。

今天我想结合自己亲身经历的一个项目，来聊聊我们在实践中是如何一步步建立起相对完善的前端工程化体系的。

---

我们是从哪开始的？

两年前，我加入了一个中大型 B2C 项目的前端团队。这个项目已经运营了三年多，但技术栈还停留在 Vue 2 + Webpack 3 的时代，项目结构复杂、配置混乱、缺乏规范，CI/CD 流程非常原始。

当时最突出的问题有几个：

• 开发体验差：每次修改一个组件都要等两三分钟才能热更新
• 包体积臃肿：主包接近 4MB，首屏加载慢得像蜗牛
• 兼容性问题频出：iOS Safari 上经常有空白页，Chrome 又没问题
• 线上定位困难：错误日志缺失，源码映射没处理好，一出问题全靠猜
• 没有版本管理和变更控制：谁改了什么，什么时候上的线，没人知道

这样的项目放在初创公司或许还能忍，但在我们这样每天几百万 UV 的产品里，简直就是一个定时炸弹。于是，我们决定彻底重构整个工程结构，并建立起一套完整的工程化流程。

---

第一步：工具链升级和模块化治理

技术选型

我们选择将 Vue 升级到 3，并迁移到 Vite 来提升开发体验。Vite 的原生 ES Modules 支持确实带来了质的飞跃。以前热更新需要三分钟左右的项目，在使用 Vite 后变成了秒级响应。这是让我最直观感到惊喜的一点。

npm install vite @vitejs/plugin-vue --save-dev

配置文件也比 Webpack 清晰很多：

// vite.config.ts
import { defineConfig } from 'vite'
import vue from '@vitejs/plugin-vue'

export default defineConfig({
  plugins: [vue()],
  build: {
    outDir: 'dist',
    assetsDir: 'assets',
    rollupOptions: {
      output: {
        chunkFileNames: 'assets/js/[name]-[hash].js',
        entryFileNames: 'assets/js/[name]-[hash].js',
        assetFileNames: 'assets/[ext]/[name]-[hash].[ext]'
      }
    }
  },
  server: {
    port: 3000
  }
})

不过，升级过程中我们也踩了不少坑：

坑一：Vue 2 到 Vue 3 的迁移成本远比预期高
虽然官方提供了迁移指南，但真实业务代码中存在大量依赖 this 的混写写法、$listeners 使用方式不一致等问题。最终我们是分阶段进行的迁移，先统一风格、规范组件写法，再逐步切换框架版本。

包体积优化

为了减小首屏体积，我们做了几个动作：

1. 按需引入 Element Plus：

   // vite.config.ts 添加 unplugin-vue-components 插件
   import Components from 'unplugin-vue-components/vite'
   import { ElementPlusResolver } from 'unplugin-vue-components/resolvers'
   

export default defineConfig({ plugins: [ vue(), Components({ resolvers: [ElementPlusResolver()] }) ] })

2. 路由懒加载拆分包：

```ts
const Login = () => import('@/views/Login.vue')

3. Gzip 压缩 + HTTP/2 配置（配合 Nginx）

最终主包体积从 4MB 缩减到了 980KB 左右，首屏加载速度提升了近两倍。

---

第二步：建立标准化开发流程

代码风格与规范统一

我们选择了 Prettier + ESLint + Stylelint 的组合：

• Prettier 做格式自动美化
• ESLint 检查 JS 语法规范
• Stylelint 控制 CSS 样式风格

// package.json 中的 scripts
"scripts": {
  "lint": "eslint .",
  "format": "prettier --write src/**/*.js src/**/*.vue",
  "stylelint": "stylelint \"src/**/*.css\" --syntax less"
}

我们还在 VSCode 中集成了这些规则，编辑器保存时自动修复部分低级错误。同时 CI 流程中加入了 lint 阶段，防止不合规范的代码合入主分支。

---

第三步：打造高效的调试工具和协作机制

调试经验分享

我们遇到一个特别头疼的问题：线上出现白屏或者接口失败，根本不知道用户遇到了什么问题。后来我们引入了 Sentry 来收集错误日志：

import * as Sentry from '@sentry/browser'
Sentry.init({
  dsn: process.env.SENTRY_DSN,
  release: `web@${process.env.npm_package_version}`,
  environment: process.env.NODE_ENV
})

结合 sourcemap 上传，即使代码经过压缩混淆，也能精准还原错误堆栈。这对我们排查 iOS 上的兼容性问题帮助巨大。

开发者工具使用心得

• Chrome DevTools 的 Performance 工具可以清晰看出首屏渲染瓶颈
• React Developer Tools 对 Vue 也基本通用，能快速查看组件树结构
• Vite 自带 Server-side HMR 功能非常强大，推荐搭配 Typescript 使用
• VS Code 的 TypeScript 提示在严格模式下非常实用，提前规避了很多潜在错误

---

第四步：CI/CD 与自动化部署

我们采用了 GitLab CI + Jenkins + PM2 的方案：

.gitlab-ci.yml 示例：

stages:
  - lint
  - test
  - build
  - deploy

eslint:
  script:
    - npm run lint

build:
  script:
    - npm run build
  artifacts:
    paths:
      - dist/

deploy:
  script:
    - ssh root@server "cd /path/to/project && pm2 startOrRestart ecosystem.config.js"

我们还做了几点细节优化：

• 所有构建产物都带有 commit hash，方便回滚
• 部署脚本自动执行数据库 migrations（如有）
• 结合 Slack 通知部署状态，方便运维介入

---

小插曲：那次让人哭笑不得的“生产环境问题”

还记得有一次发布新版本，早上刚上线就有客服反馈说某个弹窗无法关闭。我们一开始以为是缓存问题，清除 CDN 后无效。最后通过 Sentry 发现是一个未定义变量导致的崩溃。

为什么测试环境没发现？因为测试人员是在 Chrome 上操作，而用户用的是微信内置浏览器（基于旧版 WebView）。这个问题暴露了我们之前对兼容性测试的疏漏。

这次教训之后，我们做了两个调整：

1. 在 Jenkins 上增加了针对多个目标浏览器的 E2E 测试（使用 Cypress + BrowserStack）
2. 接入了浏览器兼容性检测服务（Browserslist + Can I Use 数据）

---

最终效果如何？

重构完成后，我们团队的开发效率明显提升，具体收益如下：

指标	改进前	改进后
热更新时间	>3分钟	<5秒
主包大小	~4MB	980KB
错误率	0.7%	0.08%
新人上手时间	3~5天	1天内
发布频率	每月1次	每周多次

更关键的是，我们终于可以自信地说：“这个功能没问题，我已经验证过了”，而不是拍胸脯保证“应该不会有问题”。

---

给前端朋友们的几个建议

1. 不要被框架绑架。真正支撑你走得远的是良好的工程实践，而不是花哨的技术名词。
2. 尽早接入监控系统。哪怕是小型项目，也需要知道你的用户到底经历了什么。
3. 重视持续集成的价值。每次提交都有保障，才敢大胆重构。
4. 养成良好的代码习惯。Lint 规则、目录结构、命名约定，都是减少沟通成本的关键。
5. 保持工具链简洁。有时候不是工具不够高级，而是我们过度配置了。

---

写在最后：工程师的温度比技术更重要

工程化不只是工具堆砌，更是思维方式的转变。它关乎我们如何面对变化、如何承担责任、如何为用户负责。

现在的我，在接到一个新需求时，第一反应不再是“怎么实现”，而是思考：

• 这个功能是否需要埋点？
• 是否会影响已有流程？
• 在哪些设备上表现会不同？
• 出现错误有没有合理的兜底方案？

只有把这些考虑进去，才算真正完成了工程落地。

希望这篇文章能给你一些启发。如果你也有类似的前端工程化故事，欢迎留言交流。我们一起成长。