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

很多人一开始会背：

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

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

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

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

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

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

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

所以这个阶段更适合：

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

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

## mounted 才适合碰 DOM

如果你要做的是：

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

那就更适合放在 `mounted`。

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

## updated 不是补丁桶

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

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

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

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

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

例如：

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

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

## 写在最后

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

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


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


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

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

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

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

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

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

比如：

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

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

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

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

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

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

## Vue 里的写法很直接

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

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

## 写在最后

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

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


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


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

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

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

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

- data
- methods
- computed
- 生命周期

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

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

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

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

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

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

- 命名冲突
- 来源不清

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

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

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

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

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

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

## 写在最后

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

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


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


Vue 项目包一大，最容易出现的情况就是大家开始凭感觉优化。

有人觉得是图片大，有人怀疑某个 UI 库太重，也有人想先改构建参数。问题是，在没有看到真实体积分布之前，很多判断都只是猜。

这时最值得做的第一步，不是马上删代码，而是先把包看清楚。

## Bundle Analyzer 的价值不在图炫

很多人第一次看到打包分析图，会被那一堆彩色方块吸引。但真正重要的不是图好不好看，而是它让你知道体积到底花在了哪里。

例如：

- 哪个第三方库最重
- 哪些模块重复出现
- 哪个页面 chunk 明显偏大

这些问题如果不先搞清楚，后面的优化很容易瞎忙。

## Vue 项目里最常见的膨胀点

实际项目里包体积变大，常见原因通常包括：

- 引了过重的组件库
- 路由没有按需拆分
- 富文本或图表类库直接进了主包
- 工具库按整个包引入

这类问题很多并不是代码写错，而是结构没有控制住。

## 写在最后

Webpack Bundle Analyzer 最大的作用，是把“感觉有点大”变成“我知道大在哪里”。

前端优化最怕靠直觉。先把体积分布看清楚，再决定删什么、拆什么、延后加载什么，效率会高很多。


Vue 项目包太大时先别慌：Webpack Bundle Analyzer 到底能帮你看清什么


做表单页面时，很多团队都会很快开始抽输入组件。

这方向没问题。文本框、下拉框、日期选择器这些东西确实值得复用。问题通常出在复用方式上：刚开始只是想统一样式，后面慢慢开始加校验、加联动、加提示、加布局控制，最后组件越做越胖。

## 先统一外观，再考虑行为

表单组件一开始最值得统一的，通常是这些：

- label 展示
- 错误提示
- 间距
- 基础交互样式

如果一上来就把业务校验、字段联动、接口逻辑一起塞进去，组件很快就会失去边界。

## props 多到一定程度，复用就开始走样

一旦出现下面这种趋势，就要警觉了：

- `showError`
- `validateOnBlur`
- `customRule`
- `layoutMode`
- `extraTip`
- `beforeChange`

参数越来越多，看起来像组件更通用了，实际上往往说明它开始同时服务太多场景。

## 写在最后

Vue 表单组件做得稳不稳，关键不在于抽没抽，而在于抽象边界是不是克制。

输入组件最适合统一的是外观和基础交互，不该顺手把整个业务逻辑也吞进去。复用是为了减轻页面压力，不是为了再造一个更复杂的配置层。


Vue 表单组件拆分经验：可复用输入框不是把所有 props 都塞进去


Vue 的过渡系统很好上手，所以很多人第一次接触时都会很兴奋，觉得页面终于能“动起来”了。

问题在于，动画一旦脱离交互目的，就很容易从“有帮助”变成“看起来有点多余”。

## 过渡最重要的作用是补信息

好的过渡通常不是为了炫，而是为了告诉用户：

- 这个元素刚出现
- 这个区域已经切换
- 这个操作正在完成

当动画能补足状态变化时，它就有价值。

## Vue 让这件事变简单了

`<transition>` 把进入和离开的状态整理得比较清楚，让你不需要手写太多切换细节。

这对页面交互来说很实用，尤其是：

- 弹窗
- 下拉层
- 列表切换
- 提示信息

## 但动画不是加得越多越好

如果每个区域都在动，用户的注意力反而会被打散。

而且某些动画如果处理不好，还会带来：

- 掉帧
- 卡顿
- 响应变慢

所以比起“哪里都能动一下”，更重要的是先问一句：这个动画到底在帮助什么。

## 写在最后

Vue 的过渡能力很方便，但真正决定体验的不是 API，而是你有没有把动画放在合适的位置。

先服务交互，再追求效果，页面看起来会自然很多。
