坦白讲，Zui开始弄这个玩意儿，纯粹是为了自己偷懒。

这几年写 Vue 项目，无论是 Vue 2 还是 Vue 3，甚至 Nuxt dou有涉猎，踩过的坑简直Neng填满一个采石场。每次遇到性Neng问题，dou要去翻以前的笔记，或者去 Google 搜半天效率极低。特别是那些kan似不起眼，实则致命的“低级错误”，一旦在生产环境爆发，那种焦头烂额的感觉，懂的dou懂。

后来我就琢磨着，不如把这些血泪史整理成一份文档，自己查阅起来方便，顺便还Neng投喂给现在的 AI 编码助手，比如我常用的 Claude Code。这样在审代码的时候，AI 就Neng像一位经验丰富的老同事一样，提前帮我嗅出潜在的风险。

这就有了今天要聊的这个开源项目。它不仅仅是一份文档，geng是为了解决“AI 到底Neng不Neng帮我们Zuo Vue 性Neng优化”这个问题的一次尝试。

为什么我们需要给 AI “立规矩”？

现在大家dou在用 Cursor、Claude Code 或者 GitHub Copilot 写代码。AI 确实hen强，Neng快速生成组件、写通用的业务逻辑。但是在性Neng优化这个领域，AI 往往容易“想当然”。

它可Neng会给你写出逻辑正确的代码，但运行起来却慢得像蜗牛。为什么？因为 AI 缺乏上下文，它不知道你的项目里有 10 万条数据，也不知道你的用户网络环境有多差。它只知道“这样写Neng跑”，却不知道“这样写Zui快”。

所以我整理了这套规则，本质上就是给 AI 建立一个知识库。当你把这份指南喂给它，它就Neng在生成代码的同时对照着规则进行自我审查。

那些年我们常踩的坑：从瀑布流到响应式滥用

在这个项目中，我把问题按严重程度分了类，从 CRITICAL到 LOW，总共涵盖了几个大类别。咱们挑几个Zui典型、Zui让人头疼的场景聊聊。

1. 接口请求的“瀑布流”噩梦

这绝对是新手Zui容易犯，也Zui容易被忽视的错误。

想象一下用户详情页需要加载三个数据：用户基本信息、用户的帖子、用户的评论。这三个接口其实互不依赖，完全Ke以一起请求。

但hen多时候，我们会不自觉地写成这样：

async function handleRequest {
  // 即使 skipProcessing=true，也会等待 userData
  const userData = await fetchUserData
  if  {
    // 立即返回，但前面Yi经浪费时间等待了
    return { skipped: true }
  }
  // 只有这个分支使用 userData
  return processUserData
}

或者geng直观的串行调用：

// 错误：串行：总耗时 = 300ms + 200ms + 250ms = 750ms
const user = await fetchUser          // 300ms
const posts = await fetchUserPosts    // 200ms
const comments = await fetchUserComments // 250ms

结果就是用户眼睁睁kan着页面转圈圈，明明三个接口加起来才 750ms，却因为排队执行，让首屏加载时间拉长了一倍。用户抱怨页面慢，一查日志才发现，全是这种“排队”造成的。

正确的Zuo法非常简单，就是并行处理：

// 正确：并行：总耗时 = max = 300ms
const  = await Promise.all()

总耗时瞬间从 750ms 降到了 300ms，页面快了一半多。这种优化的投入产出比简直高得离谱。而且，这种规则非常适合教给 AI，只要你在 Prompt 里强调“并行请求”，它以后就不会再犯傻。

2. 响应式系统的滥用：大对象卡顿的元凶

Vue 3 的响应式系统虽然比 Vue 2 好了hen多，但也不是万Neng的。特别是面对海量数据时滥用 ref 或者 reactive 会带来巨大的性Neng开销。

举个真实的例子：一个商品列表页，可Neng有 1000 条商品数据，每条商品有十几个字段。Ru果直接这样写：

这时候，Vue 会在后台默默地把这 1000 个对象，连同它们内部的所有属性，全部包装成 Proxy。这得消耗多少内存和 CPU？渲染的时候卡得要命，用户一滚动页面就掉帧，你还以为是组件写得不好，或者是浏览器的问题。

其实这种场景根本不需要深度响应式。我们只需要关心数组变了没，不需要关心数组里某个商品的某个属性变了没。这时候就该请出 shallowRef

shallowRef 只让数组本身具备响应性，内部对象保持原样。geng新时替换整个数组就Neng触发视图geng新，省去了大量的代理开销。这招对于老项目改造特别有效，新项目Ru果Neng一开始就用上，那性Neng基础就非常扎实了。

3. CSS 的黑魔法：content-visibility

有时候，JS 逻辑写得再好，渲染还是慢，那可Neng就是浏览器的渲染压力太大了。

比如一个长列表页面有几百条评论。Ru果一次性全部渲染到 DOM 里浏览器就算计算得再快，也会累得够呛。

以前我们可Neng会用虚拟滚动，但那个实现起来太复杂，还得引入第三方库。其实现在浏览器原生支持一个hen强大的 CSS 属性：content-visibility。

kankan这段代码：

加上这个属性后浏览器会非常智Neng：屏幕外的元素，它先不渲染，只占个位。等你滚动到了那里它再立刻渲染出来。实测下来初始加载速度快了好几倍，滚动也丝般顺滑。这种 CSS 属性真的太好用了属于那种“加一行代码，性Neng提升一个台阶”的神器。

4. 逻辑层面的低效：循环套循环

除了框架层面的坑，纯算法逻辑的坑也不少。虽然前端不像后端那样对算法要求极高，但在大数据量下写烂循环一样会卡死。

之前接手过一个项目，发现同一个商品列表循环了 5 次：

// 错误：5 次独立遍历
const discounted = products.filter
const inStock = products.filter
const featured = products.filter
const totalValue = products.reduce => sum + p.price, 0)
const avgPrice = totalValue / products.length

kan着就难受。商品少的时候kan不出来数据一多，性Neng差距就hen明显了。明明一次遍历Neng解决的事，非要跑五次。

后来改成这样：

// 正确：一次遍历
const stats = products.reduce => {
  if  acc.discounted.push
  if  acc.inStock.push
  if  acc.featured.push
  acc.totalValue += product.price
  return acc
}, { discounted: , inStock: , featured: , totalValue: 0 })
const avgPrice = stats.totalValue / products.length

这种优化虽然基础，但非常有效。而且，这也是 AI 比较擅长的地方，只要你告诉它“合并循环”，它通常Neng改得hen好。

如何把这份指南“喂”给 AI？

说了这么多，这份指南到底怎么用？特别是怎么结合 AI 工具？

Ru果你也在用 Claude Code、Cursor 这类 AI 工具，Ke以直接集成进去。项目里Yi经构建好了 AGENTS.md，把所有规则整合在一起，方便搜索。

你Ke以尝试以下命令：

# 克隆仓库
git clone https://github.com/ursazoo/vue-best-practices.git
# 安装依赖
npm install
# 构建 AGENTS.md
npm run build

或者直接使用 npx 快速添加技Neng：

npx add-skill vue-best-practices

当 AI 审查代码的时候，Ru果发现性Neng问题，它会参考这些规则给出优化建议。我现在就是这么用的，感觉就像带了个随身的技术顾问，挺方便。

别在微优化上浪费时间

Zui后想聊聊心态问题。

我发现hen多人Zuo性Neng优化容易搞错重点。

举个例子：页面有 600ms 的请求等待时间，结果花了一周去优化 computed 的缓存逻辑；首屏加载了 300KB 的 JavaScript，结果却在纠结怎么把循环少跑几次。

这就是典型的“捡了芝麻丢了西瓜”。

所以我按这个思路把规则分成了几个优先级。先把那些Bundle 体积失控接口瀑布流核心渲染阻塞的大问题解决了。至于那些微优化，比如少一次加减法，真的Ke以慢慢来甚至不用管。

这些问题不是什么高深的优化，就是基本功。但忙起来就容易忽略，等出问题再改成本就高了。

这是个开源项目，Ru果你在生产环境踩过坑、有geng好的优化方案，欢迎提 Issue 或 PR。

希望这份指南Neng帮你少走弯路，也希望你的 AI Neng变得geng聪明。毕竟我们的目标是写出geng快的代码，而不是geng累的代码。

项目信息

GitHub: github.com/ursazoo/vue-best-practices

包含多个类别，数十条规则，覆盖 Vue 2/3 及 Nuxt。

---