Vue.js 生态系统的深度实战：从手写代码到谨慎拥抱 AI

凌晨两点，窗外北京的夜色早已沉寂，地铁末班车也停了。我泡了杯速溶咖啡——别笑，程序员的浪漫就是能在凌晨三点还能保持清醒地 debug。今天想聊聊 Vue.js，不是那种“Hello World”式的入门教程，而是我在真实项目里摸爬滚打后的一些思考。毕竟，作为一个至今仍坚持手写每一行代码、对 AI 辅助工具既好奇又警惕的老派前端，我对“生态”的理解，总是带着点保守主义的滤镜。

为什么又是 Vue？React 不香吗？

先坦白：我司技术栈主推 React。团队里不少新人张口闭口“hooks 天下第一”，连产品经理都开始说“我们这个需求用 React 写更快”。但去年双11前夕，一个新运营后台项目突然砸到我头上，要求两周内上线，支持多租户、权限隔离、动态表单配置——而且，必须兼容 IE11（对，你没看错，2024 年还有人要 IE11）。

那一刻我真的想砸键盘。React + TypeScript 虽然爽，但 IE11？光 polyfill 就能让我掉一半头发。这时候，Vue 2 的兼容性优势就凸显出来了。再加上团队里有位老哥之前用 Vue 做过类似系统，GitHub 上还能扒到他半年前开源的一个权限管理模板（虽然 star 不多，但 issue 回复挺勤快），综合评估后，我们决定“叛逃”一次，用 Vue.js 搞定这个“政治任务”。

当然，这不代表我认为 Vue 比 React 好。它们只是工具，就像锤子和螺丝刀——修椅子用锤子，装电脑用螺丝刀。关键是你得知道什么时候该换工具。

构建一个“抗造”的 Vue 项目骨架

接手这种运营类后台，最怕的就是“改需求如呼吸”。今天运营说要加个筛选项，明天产品说表格要支持拖拽排序，后天测试说导出 Excel 报错了……所以架构设计必须灵活、可插拔、易维护。

我最终搭的骨架基于 Vue CLI + TypeScript + Element Plus（对，我知道很多人喷它重，但在 IE11 场景下，它比很多“轻量级”UI 库更稳）。核心原则就一条：分层清晰，职责单一。

src/
├── api/              # 接口定义，按模块拆分
├── assets/           # 静态资源
├── components/       # 通用组件（非业务）
├── composables/      # Vue 3 Composition API 逻辑复用（后面迁移到 Vue 3 用了）
├── layouts/          # 布局组件（Header/Sidebar）
├── plugins/          # 插件注册（axios、permission 等）
├── router/           # 路由配置 + 权限守卫
├── store/            # Pinia 状态管理（Vuex 已淘汰）
├── utils/            # 工具函数
├── views/            # 页面级组件
└── main.ts           # 入口

特别提一下 composables 目录。虽然项目初期是 Vue 2，但我在写业务逻辑时就有意识地把可复用的逻辑抽成函数形式（比如 useTable, useForm），为后续升级 Vue 3 打基础。这种“渐进式重构”策略，在 deadline 压力下特别实用——不用一次性推翻重来，又能逐步现代化。

权限控制：不只是路由守卫那么简单

运营系统的命脉是权限。我们遇到的最大坑，不是“能不能访问某个页面”，而是“页面里某个按钮能不能点”、“表格某列要不要显示”。

最初我天真地以为在路由守卫里校验角色就行。结果上线第一天，运营小妹反馈：“明明没权限，为啥‘删除’按钮还在？点一下报 403，体验很差啊！”

这才意识到：前端权限必须做两层：

1. 路由级：防止用户直接输入 URL 进入无权页面
2. 元素级：根据权限动态渲染 UI 元素

于是我在 plugins 里封装了一个 v-permission 指令：

// plugins/permission.ts
import type { App } from 'vue'

export default function setupPermissionDirective(app: App) {
  app.directive('permission', {
    mounted(el, binding) {
      const { value } = binding
      const permissions = JSON.parse(localStorage.getItem('userPermissions') || '[]')
      
      if (value && !permissions.includes(value)) {
        el.parentNode?.removeChild(el)
      }
    }
  })
}

用起来很简单：

<template>
  <el-button v-permission="'user:delete'">删除</el-button>
</template>

注意这里用了 removeChild 而不是 v-if。因为 v-if 只是隐藏，DOM 还在，有心人还是能通过 devtools 找到按钮并触发点击。安全起见，直接干掉 DOM 更稳妥。

性能优化：别让运营等得睡着了

运营后台最怕卡顿。想象一下：运营小姐姐点一下“查询”，然后去泡了杯咖啡回来，数据还没出来……那场面我都不敢想。

我们的数据表格动辄上千行，还带多级联动筛选。最初的实现是全量渲染 + 前端过滤，结果 Chrome 标签页直接卡成幻灯片。

优化方案三板斧：

1. 虚拟滚动：用 vue-virtual-scroller 只渲染可视区域
2. 计算属性缓存：复杂筛选逻辑用 computed + lodash.memoize
3. 接口分页：逼后端改接口，前端只负责展示

特别吐槽一点：很多团队迷信“前端做一切”，其实像大数据量筛选，应该交给后端。我们和后端约法三章：超过 200 条的数据，必须走分页接口。运营可能不懂技术，但她们懂“快”和“慢”。

从 Vue 2 到 Vue 3：一场小心翼翼的迁移

项目上线稳定后，领导发话：“明年所有新项目必须上 Vue 3”。作为保守派，我其实不太情愿——Vue 2 跑得好好的，干嘛折腾？但架不住“技术债”三个字压下来。

迁移过程比想象中顺利，多亏了 Vue 官方的 Migration Build。它允许你在 Vue 3 环境中运行 Vue 2 代码，并给出详细的警告提示。

最关键的改动是状态管理：从 Vuex 切到 Pinia。Pinia 的 TypeScript 支持简直不要太香：

// stores/user.ts
import { defineStore } from 'pinja'

interface User {
  id: number
  name: string
  permissions: string[]
}

export const useUserStore = defineStore('user', {
  state: () => ({
    userInfo: null as User | null
  }),
  getters: {
    hasPermission: (state) => (perm: string) => {
      return state.userInfo?.permissions.includes(perm) || false
    }
  },
  actions: {
    async login(credentials: { username: string; password: string }) {
      // 登录逻辑
    }
  }
})

对比 Vuex 的 mapState、mapActions，Pinia 的 composition-style 写法更直观，也更容易单元测试。

GitHub 不是终点，而是协作起点

说到开源，我们把权限模块的核心逻辑抽出来，放到了 GitHub 上：vue-operate-permission（名字随便编的，别搜了）。虽然只有几十个 star，但有几个 issue 讨论得很深入，比如有人建议用 Web Worker 做权限计算避免阻塞主线程——这思路我很喜欢，已经加到 backlog 里了。

不过我得提醒一句：别盲目崇拜开源项目。很多 GitHub 项目文档写得天花乱坠，实际用起来 bug 一堆，作者还半年不回 issue。我的经验是：star 数 > 5k 的项目可以考虑，但一定要自己跑 demo 验证。

AI 辅助？我还在观望

最近团队新来的实习生，用 GitHub Copilot 写了个表单验证规则，速度比我手敲快一倍。说实话，有点心动。

但我还是坚持手写核心逻辑。原因很简单：AI 生成的代码，我不敢保证安全。比如它可能用 eval() 处理动态表达式，或者忽略 XSS 防护。运营系统涉及敏感数据，一个漏洞可能让公司赔得底裤都不剩。

现在我的策略是：让 AI 帮我写重复性代码（比如 CRUD 模板），但核心业务逻辑、权限校验、数据处理，必须亲手过一遍。毕竟，凌晨三点 debug 的时候，没人能替你背锅。

最后一点碎碎念

写这篇文章的时候，窗外已经开始泛白。北京的早高峰又要来了，我得抓紧时间眯一会儿，不然通勤路上怕是要站着睡着。

回头看看这个 Vue 项目，虽然过程磕磕绊绊，但最终交付时运营团队给了好评，甚至主动帮我们在公司内部做了分享。这大概就是做技术最有成就感的时刻——你的代码真的在帮别人解决问题。

至于 Vue 和 React 的争论？我觉得没意义。工具没有好坏，只有合不合适。就像我，虽然保守，但也愿意在合适的场景尝试新东西。只要记住一点：安全第一，用户体验第二，炫技排最后。

下次如果你也在做一个需要兼容 IE11 的运营系统，不妨试试 Vue。至少，它能让你少掉几根头发——虽然可能也多喝几杯速溶咖啡。

---

附：Vue 2 vs Vue 3 在运营系统中的关键差异对比

特性	Vue 2	Vue 3 (Composition API)	对运营系统的影响
响应式原理	Object.defineProperty	Proxy	Vue 3 支持监听数组索引和动态属性
TypeScript 支持	需额外配置，体验一般	原生支持，类型推导更准确	减少低级错误，提升大型项目可维护性
组件逻辑复用	Mixins (易冲突)	Composables (函数式，无冲突)	权限、表单等逻辑复用更清晰
包体积	较大	Tree-shaking 后更小	首屏加载更快，尤其对低网速运营环境友好
IE11 支持	原生支持	需额外 polyfill，官方已放弃	Vue 2 仍是 IE11 场景的稳妥选择
生态成熟度	非常成熟，插件丰富	快速追赶，主流库已支持	Vue 3 新项目需验证第三方库兼容性

注：如果你的运营系统不需要支持 IE11，强烈建议直接上 Vue 3。技术债越早还，利息越低。

---

凌晨五点，保存，提交。希望这篇深夜杂谈，能给同样在 Vue 生态里摸爬滚打的你，带来一点点启发。