
Vue 里做逻辑复用时，Mixins 是很自然会接触到的一种方式。

刚开始用时它很顺手：提一段公共逻辑，多个组件混进来就能复用。可一旦项目做久，很多团队都会感受到同一个问题：Mixin 好写，但不太好管。

## Mixin 最大的问题是“隐式”

组件引入一个 Mixin 后，表面上只是多了一行配置，实际上它可能带来：

- data
- methods
- computed
- 生命周期

这些能力会直接混进当前组件里。

功能上当然成立，但阅读代码的人很容易看不出来某个字段到底来自哪里。

## 一开始省事，后面成本会上来

Mixin 常常在项目前期特别讨喜，因为它能很快解决：

- 表单通用逻辑
- 列表加载逻辑
- 权限判断逻辑

可随着 Mixin 越来越多，组件就开始出现两个典型问题：

- 命名冲突
- 来源不清

这时调试体验会明显变差。

## 复用逻辑不能只看“抽没抽出来”

真正稳定的复用，不只是把代码搬到另一个文件，而是要让依赖关系仍然清楚。

如果一个组件用了多个 Mixin，后面想知道：

- 哪个方法是谁提供的
- 哪个生命周期里做了什么
- 为什么这个字段会突然存在

这些问题都会变得不那么直观。

## 写在最后

Mixin 当然能用，但它更适合短期、简单、边界清楚的逻辑复用。

一旦项目越来越复杂，光“能复用”已经不够，来源和边界同样重要。代码复用如果把可读性搭进去，后面通常会还回来更多维护成本。


Vue Mixins 用久了为什么容易乱：复用逻辑不等于把代码拼在一起


Vue 组件写起来很顺，写着写着就容易把很多东西都塞进首屏。

登录页带上富文本编辑器，详情页顺手把图表模块一起注册，设置页里再挂一个体积不小的可视化库。页面一开始看不出问题，项目大了之后，首屏就会越来越重。

异步组件的价值，就是把这些低频内容往后放。

## 什么时候值得异步加载

一个组件如果同时满足下面几条，就很适合异步化：

- 体积不小
- 首屏不一定会看到
- 打开频率不高
- 和核心路径解耦

比如：

- 富文本编辑器
- 大图表
- 高级筛选面板
- 复杂弹窗

## 为什么说它不只是优化技巧

很多人把异步组件理解成“最后再做的性能优化”，其实不是。

当你决定某个模块应该按需加载时，本质上是在表达页面优先级：

- 哪些内容必须先到
- 哪些内容可以后到

这已经不是单纯的打包问题，而是页面结构判断。

## Vue 里的写法很直接

```javascript
components: {
  ChartPanel: () => import('./ChartPanel.vue')
}
```

写法很简单，但背后的意义很明确：这个组件不是页面一启动就必须拿到的。

## 写在最后

页面做大以后，异步组件不该只是“顺手优化一下”。它更像一种节奏控制，让用户先看到真正重要的部分。

在 Vue 项目里，越早建立这种按需加载意识，后面的性能成本越低。


Vue 异步组件值得早点用：页面越大，按需加载越像基本功


学 Vue 时，生命周期几乎是绕不过去的一章。

很多人一开始会背：

- `created`
- `mounted`
- `updated`
- `destroyed`

顺序当然要知道，但真正写项目时，更重要的问题其实是：哪些逻辑该放在哪个阶段。

## 生命周期不是为了背名词

生命周期存在的意义，是让你知道组件此刻处于什么状态。

数据是不是已经初始化了，DOM 是不是已经挂载了，页面是不是刚更新完，这些信息会直接决定你在这个阶段能做什么。

## created 更适合处理数据准备

到了 `created`，组件的数据和方法已经准备好了，但真实 DOM 还没挂到页面上。

所以这个阶段更适合：

- 初始化数据
- 发起请求
- 做纯逻辑处理

如果你只是要拿数据、准备状态，很多时候放在这里就够了。

## mounted 才适合碰 DOM

如果你要做的是：

- 获取元素尺寸
- 操作第三方 DOM 库
- 依赖页面真实节点

那就更适合放在 `mounted`。

因为只有到了这个阶段，组件的 DOM 才真正进了页面。

## updated 不是补丁桶

很多人一发现界面更新后要再做点事，就会想到 `updated`。它当然能用，但也最容易被滥用。

因为一旦组件更新频繁，这个钩子也会跟着频繁触发。

所以如果你只是想在某个字段变化后做动作，很多时候用 `watch` 会更明确，而不是把逻辑一股脑塞进 `updated`。

## destroyed 别只想着“组件被删了”

这个阶段真正要关注的是清理。

例如：

- 解绑事件
- 清理定时器
- 销毁第三方实例

这些事情如果不做，页面看起来可能没马上出问题，但后面很容易留下隐患。

## 写在最后

Vue 生命周期真正难的地方，不是顺序，而是时机感。

什么时候该拿数据，什么时候该碰 DOM，什么时候该做清理，只要这些边界分清楚，生命周期就不再是一串需要背诵的名字，而是你组织组件逻辑的坐标点。


Vue 生命周期别背顺序了：先弄清楚每个阶段该做什么


前端开发离不开请求。

页面展示数据、提交表单、刷新列表、加载详情，这些动作几乎都要和服务端通信。

如果把时间往前拉，大家最熟悉的方式可能是 Ajax；再往后，Fetch 逐渐成为更常见的写法。它们都能完成请求，但带来的开发体验并不完全一样。

## Ajax 解决了什么问题

Ajax 最重要的价值，是让页面不必整页刷新也能和服务端交换数据。

这在早期前端开发里是一次很大的改变，因为它让页面开始具备更强的交互性和动态性。

大家最熟悉的实现通常是 `XMLHttpRequest`。

```javascript
const xhr = new XMLHttpRequest();
xhr.open('GET', '/api/list');
xhr.onreadystatechange = function () {
  if (xhr.readyState === 4 && xhr.status === 200) {
    console.log(xhr.responseText);
  }
};
xhr.send();
```

这个写法并不是不能用，但确实比较底层。

## Fetch 为什么更容易被接受

Fetch 更贴近现代 JavaScript 的编码方式。

它的 API 更简洁，也更容易和 Promise、`async/await` 组合。

```javascript
async function loadData() {
  const response = await fetch('/api/list');
  const data = await response.json();
  console.log(data);
}
```

相比 `XMLHttpRequest`，这种写法的优势主要体现在：

- 更容易阅读
- 更容易封装
- 更适合现代异步流程

## 两者的差异不只是“新旧”

不少人会简单理解成“Fetch 就是更现代的 Ajax”，但更准确地说，它们代表了两种不同层级的开发体验。

`XMLHttpRequest` 更像底层接口，你需要自己处理很多状态变化。

Fetch 则更像一个围绕请求流程设计得更现代的抽象。

## Fetch 使用时也有需要注意的地方

虽然 Fetch 更简洁，但它也有一些容易踩坑的点。

例如很多人第一次用时会以为：

- 请求失败就会进入 `catch`

实际上不是所有 HTTP 错误状态都会自动抛异常。比如返回 404、500，Fetch 依然可能算“成功收到响应”，只是 `response.ok` 为 `false`。

所以通常还要自己判断：

```javascript
const response = await fetch('/api/list');

if (!response.ok) {
  throw new Error('request failed');
}
```

## 请求封装的重要性

无论使用 Ajax 还是 Fetch，真正影响项目维护体验的，往往不是底层 API 本身，而是你有没有做好请求层封装。

例如：

- base URL
- 通用 headers
- 错误处理
- token 注入
- 超时控制

如果这些都散落在页面里，请求方式再现代，项目后期也会很难维护。

## 从工具切换到抽象思维

很多技术演进表面看起来只是 API 更新，实际上还有一个更关键的问题是推动开发者思维变化。

从 Ajax 到 Fetch，更有价值的变化不只是代码少了几行，而是前端异步请求开始更自然地融入整体工程结构。

## 写在最后

从 Ajax 到 Fetch，是前端请求方式一次很自然的演进。前者解决了页面局部更新的问题，后者则让请求代码更容易和现代 JavaScript 编程方式结合。

工具当然会变化，但真正值得沉淀的是请求层的组织方式。只要这层思路清楚，用什么接口都不会太乱。


从 Ajax 到 Fetch：前端请求方式的演进到底带来了什么


我第一次认真把乐观更新用进 React 项目，不是在点赞按钮这种玩具级例子里，而是在一个内部内容系统的评论区。

那个页面表面上不复杂：用户输入评论，点击发送，评论出现在列表里。需求也很普通，谁都觉得不难。真正把它做进业务之后，问题很快就出来了。

最开始的实现很直白。用户点击“发送”后，按钮进入 loading，等接口返回成功，再把新评论插进列表。逻辑一点都不花哨，但体验非常差。公司内网环境本来就不稳定，再加上评论接口还会顺手做审核、敏感词和通知，正常情况下一次请求经常要几百毫秒，偶尔还会上 1 秒。结果就是用户每次点完发送，页面都像卡了一下。

最烦的是，这种迟钝不是“性能慢”的那种大问题，它更像一种持续的小摩擦。用户会不自觉地点第二次，会怀疑刚刚有没有发成功，会盯着按钮看。你从埋点里也能看到，评论提交后的二次点击率很高，但接口明明没有真正失败。

## 一开始我用的是最常见的临时状态写法

我最早的处理方式其实很传统：

1. 本地先维护一份 `comments`
2. 再维护一份 `isSubmitting`
3. 提交时手动把一条临时评论插进去
4. 请求回来后用真实评论替换掉临时项
5. 如果失败，再把临时项删掉

这套方案不是不能用，问题在于它很快就会长出一堆边角逻辑。

比如：

- 临时评论的 `id` 用什么生成
- 用户连续发两条时，哪条先回来
- 如果接口失败，输入框里的文字要不要恢复
- 列表重新拉取时，临时项和真实项怎么合并

这些东西单看都不大，但它们会让“提交一条评论”这件事越来越像在修一套同步系统，而不是写一个交互。

那次改造到后面，我最大的感受不是“乐观更新可以让页面更快”，而是如果你继续手搓两套状态，迟早会把自己绕进去。

## 真正的问题不是快不快，而是状态到底该由谁来表达

我后来回头看，当时最别扭的点在于：我一边想让界面先表现得像成功了，一边又不想把真实状态提前写死。

这其实是两种状态：

- 用户当前应该看到什么
- 服务器最终确认了什么

以前我把这两层混在一起处理，所以写到后面只能不断补丁。React 的 `useOptimistic` 给我的帮助，不是“提供一个新 Hook”，而是把这两层状态硬拆开了。

你可以先明确地告诉 React：提交中的界面长什么样。然后等真实请求回来，再把真实状态落进去。这个分工一旦清楚，代码会安静很多。

## 我后来是怎么改的

改造之后，我把评论提交拆成两段：

第一段负责立即反馈。用户点发送的那一刻，先用 `useOptimistic` 往列表里加一条带 `pending` 标记的评论，这样界面立刻变化，输入框也能马上清空。

第二段负责异步收口。接口成功后，把服务端返回的真实评论写回去；失败的话，就把这条临时评论回滚掉，并把输入内容恢复出来。

核心写法和官方文档思路差不多，但我在业务里更在意的是三件事：

```javascript
const [optimisticComments, addOptimisticComment] = useOptimistic(
  comments,
  (currentComments, newComment) => [
    ...currentComments,
    { ...newComment, pending: true }
  ]
);

function handleSubmit(text) {
  const tempComment = {
    id: crypto.randomUUID(),
    text
  };

  startTransition(async () => {
    addOptimisticComment(tempComment);
    await saveComment(tempComment);
  });
}
```

第一，临时评论必须能被稳定识别。否则后面失败回滚、成功替换都会很难做。

第二，失败路径不能是“以后再说”。我一开始就是在这件事上吃亏，导致偶发失败时列表里会留下幽灵评论。

第三，乐观更新最好局部做，不要一上来改整个页面的共享状态。那次我只把评论列表这一段先改了，没有顺手去动评论数、消息中心、右侧推荐这些联动区域。事实证明这是对的，因为局部先跑通以后，边界会清楚很多。

## `startTransition` 在这里帮我的，不是“异步”，而是优先级

很多人第一次看到 `startTransition`，会下意识把它理解成异步包装器。实际开发里我更把它当成“让 React 知道这次更新不必抢最高优先级”。

像评论提交这种交互，用户最在意的是：

- 按钮点下去立刻有反馈
- 输入框别卡
- 列表看起来已经变了

至于后面那次真实状态写回，并不是最强实时的那种更新。`startTransition` 的好处就在这里，它不会把所有状态更新一股脑地压到最前面。页面整体的手感会更平顺，不是那种“逻辑都对，但总觉得哪里发沉”的状态。

## 不是所有交互都该乐观更新

那次改造之后，我有一段时间很上头，觉得很多操作都可以乐观一点。后来很快就收住了，因为有些地方用起来确实不合适。

我现在基本用这几个标准判断：

- 成功率高不高
- 失败后能不能自然回滚
- 即时反馈值不值那点复杂度

点赞、收藏、关注、评论追加，这些通常适合。

支付、库存扣减、权限切换、关键配置保存，这些我就会谨慎很多。因为一旦失败，用户看到的不是“界面闪了一下”，而是对系统信任直接下降。

## 这类改造最后给我的一个感受

我后来越来越觉得，前端很多交互问题表面上像是“等待太久”，其实根子在状态建模。

如果你的代码里只有“提交前”和“提交后”两种状态，那你只能让用户等。可真实交互里明明还有一种状态很重要，就是“用户已经做了动作，系统也应该先给反应，但后端还没最终确认”。

`useOptimistic` 的价值就在这里。它不是为了让页面看起来花哨一点，而是让这层状态终于有了正式写法。

## 写在最后

我现在看乐观更新，已经不太把它当作“体验优化技巧”了，更像是一种交互建模方式。

当你明确区分“用户现在应该看到什么”和“服务器最终确认了什么”之后，很多原来看起来只能靠补丁处理的逻辑，都会顺下来。React 这两个 API 好用的地方，不是新，而是它们终于把这件事讲清楚了。


React 中的乐观更新：我是在一次评论交互改造里真正把它用明白的


Vite 出来之后，Vue 开发者很自然会拿它和 Vue CLI 比。

这两者表面上都能帮你起一个项目、跑开发环境、做打包，但用起来的感觉并不一样。

## Vue CLI 的强项是成熟

Vue CLI 已经陪很多项目跑了很久。

它的优点很明确：

- 上手路径清楚
- Webpack 能力完整
- 插件和配置体系成熟

如果你在一个比较传统、稳定、历史包袱多的项目里，Vue CLI 仍然很靠谱。

## Vite 的吸引力在体验

Vite 最容易让人有感知的地方，就是开发阶段反馈更快。

你甚至不需要先把一堆原理吃透，光是启动和热更新速度，已经足够让人愿意试。

## 这不是淘汰关系

在 2020 这个时间点，更合理的理解不是“谁干掉谁”，而是：

- Vue CLI 代表成熟的 Webpack 工具链
- Vite 代表一种更轻、更快的新方向

## 写在最后

如果你现在手上项目跑得稳，没必要为了新就立刻重构全部工具链；但如果你正在起新项目，Vite 已经足够值得认真看一眼。

它带来的不是小修小补，而是开发体验上的一条新路。


Vue 异步组件值得早点用：页面越大，按需加载越像基本功

什么时候值得异步加载

为什么说它不只是优化技巧

Vue 里的写法很直接

写在最后

从 Ajax 到 Fetch：前端请求方式的演进到底带来了什么

React 中的乐观更新：我是在一次评论交互改造里真正把它用明白的

Vue CLI 和 Vite 该怎么看：一个成熟稳，一个轻快直接