
刚开始用 Vue 时，很多人都会把 `computed` 和 `watch` 混着用。

表面上看，它们都能“跟着数据变化做点事”，写起来也都不难。可项目一大，差别就会越来越明显。该放在 `computed` 里的逻辑写进了 `watch`，后面会越来越绕；反过来，把副作用塞进 `computed`，代码也会慢慢变得不好维护。

这两个能力看着相近，职责其实完全不同。

## 先说最短的结论

如果你只是想基于已有状态推导出一个新值，用 `computed`。

如果你是想在某个值变化后执行副作用，比如发请求、写本地存储、调第三方接口，用 `watch`。

这个边界一旦立住，很多代码会立刻顺起来。

## computed 更像“结果”

`computed` 的核心是派生状态。

例如购物车里你已经有：

- 商品列表
- 数量
- 单价

那总价就很适合放进 `computed`。

```javascript
computed: {
  totalPrice() {
    return this.items.reduce((sum, item) => {
      return sum + item.price * item.count;
    }, 0);
  }
}
```

这个值不需要手动维护，也不需要额外存一份。只要原始数据变了，结果自然就变。

这就是 `computed` 最舒服的地方：它让状态表达更完整，而不是让你再多维护一份变量。

## watch 更像“反应”

`watch` 则不是拿来推导结果的，它更像对变化的响应。

比如用户切换搜索条件后，你要重新拉一遍列表：

```javascript
watch: {
  keyword(newValue) {
    this.fetchList(newValue);
  }
}
```

这里真正有意义的不是“生成了一个新值”，而是“变化发生后，要去做一件额外的事”。

请求、日志、埋点、缓存同步，这些都属于 `watch` 更擅长的范围。

## 为什么很多代码会把它们写反

因为 `watch` 看起来什么都能做。

你完全可以监听某个字段变化，再手动去改另一个字段，于是代码慢慢变成这样：

```javascript
data() {
  return {
    firstName: 'Su',
    lastName: 'Jf',
    fullName: ''
  };
},
watch: {
  firstName() {
    this.fullName = this.firstName + ' ' + this.lastName;
  },
  lastName() {
    this.fullName = this.firstName + ' ' + this.lastName;
  }
}
```

功能没问题，但结构已经开始别扭了。

因为 `fullName` 并不是独立状态，它只是另外两个值的组合。既然只是组合，就不该手动维护。

这种写法改成 `computed` 会更自然，也更不容易漏掉边界情况。

## 一个简单判断办法

可以问自己一句话：

“这个值是要算出来，还是要顺手做点别的？”

如果答案是“算出来”，优先 `computed`。

如果答案是“要顺手去做请求、写缓存、触发外部逻辑”，那就是 `watch`。

## 别让 watch 变成补丁桶

项目里有个很常见的现象：一开始只是监听一个字段，后面慢慢加条件、加分支、加节流、加异步请求，最后一个 `watch` 变成了功能中心。

这并不是 `watch` 的错，而是它太容易被拿来打补丁。

所以在写 `watch` 时最好克制一点，只让它做“变化后的动作”，不要拿它承担状态建模。

## 写在最后

`computed` 和 `watch` 都很重要，但它们处理的问题不是一类。

一个是“结果”，一个是“反应”。当你不再把它们混着用，Vue 代码会轻很多，状态关系也会更清楚。


Vue 里 computed 和 watch 到底怎么选：别把两种能力写成一回事


Vue 单页应用做小的时候，路由通常只是几个页面切换，没什么难度。可页面一多，路由就不再只是“从 A 跳到 B”，它会直接影响项目结构。

列表页和详情页怎么组织，后台模块怎么拆，权限页放在哪一层，布局组件怎么复用，这些事最后都会回到路由设计上。

## 路由不是只管跳转

很多人刚开始学 Vue Router，会把重点放在：

- `router-link`
- `this.$router.push`
- 动态参数

这些当然要会，但真到项目里，更关键的是路由和页面结构是否一致。

如果路由本身没有层级感，页面代码通常也会跟着乱。

## 嵌套路由很适合后台布局

后台管理系统里最常见的需求之一，就是外层菜单和头部固定，中间内容区切换。

这种场景下，嵌套路由会比平铺路由更自然。

```javascript
const routes = [
  {
    path: '/admin',
    component: AdminLayout,
    children: [
      { path: 'users', component: UserList },
      { path: 'orders', component: OrderList }
    ]
  }
];
```

这样布局只渲染一次，内部页面跟着切换，结构也更清楚。

## 动态路由别只想着参数怎么取

动态路由通常会写成：

```javascript
{ path: '/article/:id', component: ArticleDetail }
```

很多人学到这里就停了，关注点只剩“怎么拿到 `id`”。但真正更值得想的是：

- 详情页是否真的适合放在这个层级
- 列表和详情是不是同一个业务模块
- 返回路径和面包屑是否自然

说白了，参数不是难点，页面关系才是。

## 路由命名会在后期救你很多次

很多项目前期直接靠路径跳转，能跑就行。可等路径复杂了、参数多了、结构调整了，就会开始感受到命名路由的好处。

```javascript
{
  path: '/article/:id',
  name: 'article-detail',
  component: ArticleDetail
}
```

后面跳转时：

```javascript
this.$router.push({ name: 'article-detail', params: { id: 1 } });
```

比硬写路径更稳，也更便于统一维护。

## 懒加载值得尽早接入

页面一多以后，路由懒加载几乎是默认应该考虑的事情。

因为单页应用最容易出现的问题之一，就是首屏把所有页面代码一起打进来。

```javascript
const UserList = () => import('./views/UserList.vue');
```

这不是锦上添花，而是项目变大后的基本优化。

## 写在最后

Vue Router 学起来不难，真正难的是把它和页面结构一起设计清楚。

页面少时随便写都能跑，页面多了以后，路由就是项目骨架。骨架搭得清楚，后面很多代码都会跟着轻下来。


Vue Router 实战整理：页面一多，路由设计比跳转本身更重要


一提到 Vue 项目里的状态管理，很多人很快就会想到 Vuex。

这没问题。Vuex 在合适的场景下确实很有用，尤其是多组件共享、跨页面复用、状态流比较长的时候。

问题在于，Vuex 也特别容易被提早引入。

## 什么情况适合用 Vuex

如果一个状态同时满足下面几个条件，通常就值得考虑 Vuex：

- 多个组件都要读
- 修改入口不只一个
- 生命周期跨组件甚至跨页面
- 你希望状态流清楚可追踪

比如：

- 当前登录用户
- 权限信息
- 购物车
- 全局筛选条件

这些都比较适合放进 store。

## 什么情况不适合

如果只是一个页面里的弹窗开关、输入框内容、临时切换状态，这类局部交互通常没有必要上 Vuex。

不是说不能放，而是放进去之后成本会比收益高。

很多时候你会发现：

- mutation 要写
- action 要写
- getter 要写
- 最后只是改一个布尔值

这时大概率是建模层级抬高了。

## Vuex 最有价值的地方是“明确”

很多人喜欢 Vuex，不只是因为它能共享状态，而是因为它把状态改动路径写得很明确。

你能知道：

- 状态在哪里
- 谁在改它
- 通过什么动作改

这种明确感在多人协作时尤其重要。

## 但别把所有状态都追求成“全局”

Vuex 的一个常见误用，就是把“会被复用”误解成“应该全局”。

有些数据确实有机会在别处再用，但如果眼下仍然只是一个局部页面的交互状态，就不一定要提前进 store。

越早全局化，后面越容易产生多余耦合。

## module 拆分要早点做

项目稍大一些以后，store 最怕变成一个大对象，里面把用户、订单、设置、弹窗、缓存全揉在一起。

这时候最容易出现的问题不是功能失效，而是后面没人愿意动它。

所以模块拆分应该尽早做，不要等 store 已经长得很胖了再回头治理。

## 写在最后

Vuex 不该被神化，也不该被滥用。

它适合那些真正跨组件、跨页面、需要清晰流转的状态；至于局部交互，很多时候交给组件自己反而更自然。状态管理做得好不好，关键不是上没上 Vuex，而是状态层级是不是放对了。


Vuex 该什么时候上：不是所有共享状态都值得进 store


很多人第一次看到 Vue 的 `.vue` 文件时，都会觉得这东西很顺手。

模板、脚本、样式放在一个文件里，写组件时非常舒服。可写得顺手，不代表浏览器天生认识它。

浏览器并不理解 `.vue` 文件，能让这套写法成立的，背后其实是构建工具。

## 单文件组件为什么好用

单文件组件最大的好处，是把一个组件真正聚合在一起。

一个组件通常本来就包含三部分：

- 结构
- 逻辑
- 样式

以前这些内容可能散落在多个文件里，维护起来总要来回切。SFC 的好处就在于，组件边界更完整。

## 但浏览器并不会直接执行它

`.vue` 文件不是浏览器原生支持的格式，所以它必须先被处理。

这里 Webpack 的价值就体现出来了。它不是在“帮你写 Vue”，而是在帮你把这些开发阶段的写法转换成浏览器能运行的代码。

## vue-loader 的角色

如果说 Webpack 是总调度，那 `vue-loader` 就是专门处理 `.vue` 文件的那一层。

它会把：

- `<template>`
- `<script>`
- `<style>`

拆开处理，再交给对应的 loader 去接力。

这也是为什么你在 Vue 项目里明明只写了一个组件文件，最后浏览器却能正常拿到 JS 和 CSS。

## Webpack 不只是打包

很多初学者会把 Webpack 理解成“把文件合并一下”。实际上在 Vue 项目里，它做的事情远不止这些。

例如：

- 处理单文件组件
- 转换 ES Module
- 编译样式预处理器
- 处理图片和字体资源
- 做代码拆分

说到底，它在替你把开发体验和浏览器运行环境之间的差距补上。

## 写在最后

Vue 单文件组件之所以让人觉得自然，是因为 Webpack 把复杂度挡在了后面。

你写 `.vue` 文件时感受到的是组件化的轻松，但这份轻松本身，就是工具链替你换来的。理解这一点之后，再看 Vue 项目的构建过程就不会那么抽象了。


Vue 单文件组件为什么离不开 Webpack：从 .vue 文件说起


单页应用最容易被忽略的一个问题，就是“什么都先打进来”。

页面少的时候感觉不到，模块一多，首屏体积和初始化时间就会慢慢拉高。用户明明只访问了首页，却被迫把后台设置页、表单向导、图表模块一起下载了。

这就是代码分割存在的理由。

## 代码分割不是高级优化

很多人第一次接触 Webpack 的代码分割，会把它当成“后面再说的优化项”。可对 Vue 这种页面越来越多的单页应用来说，它其实很早就值得考虑。

因为只要页面结构明确、访问路径分层，自然就会想到：

- 首页不该加载后台页代码
- 列表页不该提前加载编辑器
- 低频弹窗没必要跟首屏一起进来

## Vue 路由懒加载就是最常见的切入点

在 Vue 项目里，代码分割最直接的入口通常就是路由级拆分。

```javascript
const UserList = () => import('./views/UserList.vue');
```

这行代码带来的不只是“写法更现代”，而是明确告诉打包器：这部分代码可以等真正访问时再加载。

## Webpack 帮你做的，不只是拆文件

如果没有打包器，你很难优雅地把应用切成多个按需加载的模块。

Webpack 在这里做的是：

- 找出依赖关系
- 生成独立 chunk
- 在运行时按需拉取

你写起来只是一行动态导入，真正复杂的事情都在背后。

## 别为了拆而拆

代码分割当然有好处，但也不是 chunk 越多越好。

拆得太碎，可能带来：

- 请求数变多
- 资源管理复杂
- 公共依赖重复加载判断更难

所以最自然的拆分单位通常还是页面、重模块和低频功能，而不是所有组件都切成一个单独 chunk。

## 写在最后

Webpack 的代码分割真正省下来的，不只是几百 KB 体积，而是用户第一次进入页面时不必要的等待。

Vue 应用做大之后，按需加载几乎不是“可选项”，而是结构设计的一部分。你越早理解这一点，后面的性能成本越低。


Vue 项目里的代码分割：Webpack 真正帮你省下了什么


项目目录一深，前端里最先变难看的往往不是业务逻辑，而是导入路径。

你会开始看到这种东西：

```javascript
import UserCard from '../../../../components/UserCard.vue';
```

第一次还能接受，文件一多以后，这种路径本身就会变成维护负担。

## 别名解决的不只是长度问题

很多人第一次配路径别名，会觉得它只是为了少写几个 `../`。这当然算好处，但更大的价值其实是稳定。

例如：

```javascript
import UserCard from '@/components/UserCard.vue';
```

这样写之后，组件位置一眼就清楚，也不会因为当前文件所在层级不同，导入路径长得天差地别。

## 目录结构调整时会省很多事

相对路径最麻烦的一点，是它过于依赖当前位置。

只要文件换个目录，很多引用都得跟着改。项目越大，这种成本越明显。

用了别名以后，路径更像是在描述“我依赖哪个模块”，而不是“我从这里往上跳几层再往下找”。

## 在 Vue 项目里尤其常见

Vue 项目里组件、视图、store、utils 很容易形成比较清晰的目录结构，这时候别名就特别顺手。

常见做法通常是：

- `@` 指向 `src`
- 或者再拆一些业务模块别名

这样导入语句本身会清爽很多。

## 写在最后

Webpack 路径别名看起来只是一个小配置，但它会持续改善项目的可读性。

工程化很多时候就体现在这种小地方：不是让代码显得更高级，而是让后面的人少看几眼就能明白文件关系。
