Vue 3 on 方糖猫Blog

前端 UI 开发从入门到精通（Vue 技术栈）：HTTP、CSS 与主流组件库实战

Tue, 16 Aug 2022 09:00:00 +0800

前端 UI 开发从入门到精通（Vue 技术栈）：HTTP、CSS 与主流组件库实战

目标读者：会写一点 Vue，但面对「这个布局怎么调」「这个接口怎么接」「组件库样式怎么改」还是会心里发虚的同学。
姊妹篇：《前端开发从入门到精通：JavaScript → TypeScript → Vue 3 实战指南》讲的是语言内功，这篇讲的是 UI 实战。

先说一句可能得罪人的话：很多前端写了两三年业务，其实一直在「UI 开发的入门区」打转。会调组件库的 API ≠ 会做 UI 开发。真正的分水岭在于：你能不能在没有设计稿的情况下把页面排得不难看，能不能在接口报错时五分钟内定位是前端问题还是后端问题，能不能在组件库不满足需求时优雅地绕过去而不是对着它硬改。

这篇文章讲三块内容，对应 UI 开发的三个基本功：

flowchart LR
    A["HTTP<br/>数据从哪来"] --> D["UI 页面"]
    B["CSS<br/>页面长什么样"] --> D
    C["组件库<br/>用什么零件搭"] --> D
    D --> E["一个完整页面<br/>= 数据 + 布局 + 组件"]
    E --> F["精通<br/>= 能排错 能绕坑 能设计"]

HTTP：页面不是孤立的，数据要从服务器来。请求发不出去、发出去收不到、收到了不渲染，每一种「不工作」背后都是一类知识。
CSS：UI 开发的半壁江山。大部分人不是不会 CSS，而是「会一半」——能写出来，但不知道为什么生效、为什么失效。
组件库：Element Plus、Ant Design Vue、Naive UI 怎么选，怎么用出「高级感」，以及怎么避开它们各自的坑。

老规矩，知识点之外，我会穿插真实的踩坑故事和可以运行的 Demo。

第一篇 HTTP：数据是怎么到页面上的

1.1 一次请求的完整旅程

很多新人对 HTTP 的理解停留在「axios.get(url) 然后 .then 拿数据」。我们先看看这一次调用背后发生了什么：

sequenceDiagram
    participant P as 页面组件
    participant A as axios 实例
    participant I as 请求拦截器
    participant B as 浏览器
    participant S as 后端服务
    P->>A: http.get('/api/users')
    A->>I: 带上 token、组装 baseURL
    I->>B: 发起真实网络请求
    B->>S: DNS 解析 → TCP 连接 → TLS 握手 → 发送报文
    S-->>B: 状态码 + 响应体
    B-->>I: 进入响应拦截器
    I-->>A: 统一解包 { code, data, message }
    A-->>P: 返回 data 或抛出业务错误

这张图里每一个环节都可能出错，而「精通」的标志就是：看到现象，能立刻判断问题出在哪一层。

请求根本没发出去（Network 面板里看不到）→ 你的 JS 代码有问题，或者拦截器里 throw 了。
请求发出去了，状态码是 4xx/5xx → 后端或网关的问题，但参数对不对还得你自己查。
状态码 200，但页面上没数据 → 响应拦截器解包逻辑或组件渲染的问题。
状态码是 (blocked:cors) 或者红色的 OPTIONS → 跨域，见下面的踩坑故事。

1.2 先懂协议，再谈封装

不需要背 RFC，但这几件事必须形成肌肉记忆：

方法语义：GET 查询、POST 创建、PUT 全量更新、PATCH 局部更新、DELETE 删除。语义不止是给后端看的——GET 请求会被浏览器和 CDN 缓存、会被浏览器历史记录保留，你拿 GET 做删除操作，等于给自己埋雷。
状态码：200（成功）/ 301 302（重定向）/ 400（参数错，你的锅）/ 401（没登录或 token 过期）/ 403（登录了但没权限）/ 404（路径错）/ 500（后端炸了）/ 502 504（网关或后端挂了）。
Content-Type：application/json 是今天的默认；multipart/form-data 用于文件上传。踩坑点：用 axios 上传文件时不要手动设置 Content-Type，浏览器需要自动生成带 boundary 的头部，手动设置反而会让后端解析不了。

1.3 一个生产可用的请求封装（Demo）

下面是我这些年沉淀下来的一版 axios 封装骨架，去掉公司特定逻辑后依然可直接用：

// src/utils/http.ts
import axios, { AxiosError, type AxiosRequestConfig } from 'axios'
import { ElMessage } from 'element-plus'

// 后端统一响应格式：{ code: 0, data: T, message: 'ok' }
interface ApiResponse<T = unknown> {
  code: number
  data: T
  message: string
}

const http = axios.create({
  baseURL: import.meta.env.VITE_API_BASE ?? '/api',
  timeout: 15000,
})

// 请求拦截：带 token
http.interceptors.request.use((config) => {
  const token = localStorage.getItem('token')
  if (token) config.headers.Authorization = `Bearer ${token}`
  return config
})

// 响应拦截：统一解包 + 统一错误提示
http.interceptors.response.use(
  (res) => {
    const body = res.data as ApiResponse
    if (body.code === 0) return body.data          // 成功：直接把 data 交出去
    if (body.code === 401) {
      // token 过期：清登录态，跳登录页
      localStorage.removeItem('token')
      location.href = '/login'
      return Promise.reject(new Error(body.message))
    }
    ElMessage.error(body.message || '请求失败')
    return Promise.reject(new Error(body.message))
  },
  (err: AxiosError) => {
    // 网络层错误：超时、断网、5xx
    if (err.code === 'ECONNABORTED') ElMessage.error('请求超时，请重试')
    else ElMessage.error(err.response ? `服务异常(${err.response.status})` : '网络异常')
    return Promise.reject(err)
  },
)

export function get<T>(url: string, config?: AxiosRequestConfig) {
  return http.get<unknown, T>(url, config)
}
export function post<T>(url: string, data?: unknown, config?: AxiosRequestConfig) {
  return http.post<unknown, T>(url, data, config)
}

用法：

import { get } from '@/utils/http'

interface User { id: number; name: string; email: string }

const users = await get<User[]>('/users')   // 拿到的就是解包后的 data

这个封装的核心思想只有一句话：让业务代码只关心成功路径。解包、错误提示、登录跳转全部收敛到拦截器里，组件里不需要到处写 if (res.code === 0)。

1.4 踩坑故事一：那个只在测试环境出现的跨域

现象：本地开发一切正常，部署到测试环境后所有接口报 CORS 错误，后端同事说「我配了 Access-Control-Allow-Origin: * 了啊」。

排查：打开 Network 面板，发现带 Authorization 头的请求之前，浏览器先发了一个 OPTIONS 预检请求，而预检请求返回 404——Nginx 配置里只把 GET/POST 转发给了后端，OPTIONS 落到了静态文件规则上。

教训，一次记住三个知识点：

flowchart TD
    A["浏览器要发跨域请求"] --> B{"是简单请求吗？<br/>GET/POST + 无自定义头<br/>+ 特定 Content-Type"}
    B -->|"是"| C["直接发真实请求<br/>靠响应头 ACAO 放行"]
    B -->|"否（比如带 Authorization）"| D["先发 OPTIONS 预检"]
    D --> E{"预检返回 2xx 且<br/>CORS 头齐全？"}
    E -->|"是"| C
    E -->|"否（404/405/缺头）"| F["报 CORS 错误<br/>真实请求根本没发"]
    style F fill:#ffe4e1

带自定义头（如 Authorization）的请求一定会触发预检。
预检失败时，真实请求根本没有发出，后端日志里查不到，容易误判成「后端没问题」。
开发环境不跨域是因为 Vite 的 server.proxy 帮你转发了——代理方案只在开发环境存在，上线后跨域问题会准时出现。

1.5 踩坑故事二：疯狂抖动的搜索框

现象：搜索建议框，用户每敲一个字就发一次请求。结果因为网络延迟，先发的请求后返回，后返回的旧结果覆盖了新结果，搜索「北京」时页面一闪而过地显示「北」的结果。

解法，三板斧，按成本从低到高：

import { refDebounced } from '@vueuse/core'  // 或者手写防抖

// 方案 1：防抖，减少请求次数（300ms 内不重复触发）
const keyword = ref('')
const debouncedKeyword = refDebounced(keyword, 300)

// 方案 2：竞态防护，只接受最后一次请求的结果
let seq = 0
watch(debouncedKeyword, async (kw) => {
  const mySeq = ++seq
  const list = await get<Suggestion[]>('/suggest', { params: { kw } })
  if (mySeq !== seq) return    // 这期间又发了新请求，丢弃旧结果
  suggestions.value = list
})

// 方案 3：AbortController 直接取消旧请求（axios 支持 signal）

真实项目里我通常 1 + 2 组合用。方案 3 最彻底，但要小心把取消错误误报成「请求失败」的 toast。

1.6 思考：请求封装是在封装「约定」

很多人封装 axios 只是在封装函数调用，其实真正值钱的是把团队协作约定固化进代码：token 放哪个头、错误码怎么定、401 怎么处理、超时多久算超时。这些约定一旦写进拦截器，新人在第一天就「被迫」遵守了整个团队的规范。好的基础设施，是让正确的事情自动发生。

第二篇 CSS：UI 开发的半壁江山

2.1 先建立一个心智模型

CSS 难学的根源是：它不是一个「语言」，而是一堆相互独立的机制的合集。布局、层叠、盒模型、格式化上下文各自为政，你以为是玄学的问题，拆开看都是明确的规则。

mindmap
  root((CSS 四大机制))
    盒模型
      content-box
      border-box
      margin 折叠
    布局
      normal flow 文档流
      flex 一维布局
      grid 二维布局
      position 定位
    层叠
      优先级 选择器权重
      继承
      z-index 与层叠上下文
    格式化上下文
      BFC
      IFC

入门阶段我建议只抓两条主线：盒模型 + flex/grid 布局，能解决 90% 的日常问题；层叠和 BFC 等踩到坑再回头补。

2.2 盒模型：一切从盒子开始

flowchart LR
    subgraph box["border-box 盒模型"]
        M["margin<br/>(外边距，不算进盒子)"] --> B["border<br/>边框"]
        B --> P["padding<br/>内边距"]
        P --> C["content<br/>内容"]
    end

一句话规则：项目全局设置 box-sizing: border-box，然后你写的 width: 200px 就是「视觉上的 200px 宽」，padding 和 border 往内挤，不再往外扩。这条规则值得写进每个项目的 reset 里：

*, *::before, *::after {
  box-sizing: border-box;
}

2.3 布局：Flex 管一维，Grid 管二维

记住这个分工就不会纠结选型：

一排或一列的元素（导航栏、表单行、卡片列表的某一排）→ Flex。
有行有列的整体结构（页面骨架、照片墙、仪表盘）→ Grid。

Flex 日常 90% 的用法就这几个：

.toolbar {
  display: flex;
  align-items: center;      /* 交叉轴居中（垂直居中） */
  justify-content: space-between; /* 主轴两端对齐 */
  gap: 12px;                /* 元素间距，别再给子元素写 margin-right 了 */
}

.toolbar .spacer {
  flex: 1;                  /* 占满剩余空间，把后面的元素顶到最右 */
  min-width: 0;             /* ⚠️ 踩坑点，见 2.5 */
}

Grid 搭页面骨架，三行 CSS 出「头-侧-主」经典布局：

.admin-layout {
  display: grid;
  height: 100vh;
  grid-template:
    "header header" 56px
    "aside  main"   1fr
    / 220px 1fr;
}
.admin-layout > header { grid-area: header; }
.admin-layout > aside  { grid-area: aside; }
.admin-layout > main   { grid-area: main; overflow: auto; }

grid-template 的「ASCII 画」语法是我认为 CSS 里最优雅的设计之一——布局长什么样，代码里就画成什么样。

2.4 现代 CSS 三件套：变量、容器查询、:has()

如果你的项目不再需要兼容 IE（2026 年了，真的不需要了），这三样东西能显著减少 JS 代码量：

:root {
  --primary: #409eff;
  --radius: 6px;
}
[data-theme='dark'] {
  --primary: #79bbff;
}

.btn {
  background: var(--primary);
  border-radius: var(--radius);
}

/* :has() —— 终于可以「父选子」了 */
.form-item:has(.el-input.is-error) {
  border-color: red;
}

CSS 变量配合 Vue 更是绝配——在组件里改一个变量，整个子树的样式跟着变，比传 props 干净得多：

<template>
  <section :style="{ '--card-color': themeColor }">
    <slot />
  </section>
</template>

2.5 踩坑故事三：flex: 1 了，为什么还是不生效

现象：侧边栏固定宽度 + 主内容 flex: 1 的经典布局，主内容里放了一张表格，结果表格把主内容越撑越宽，整个页面出现了横向滚动条。

原因：flex 子项的默认 min-width 是 auto，意思是「最小也不能比内容窄」。表格内容很宽，flex: 1 就压不住它。

解法：一行代码，但不知道的人能查一下午：

.main { flex: 1; min-width: 0; overflow: auto; }

同理，grid 里是 minmax(0, 1fr)。这是前端面试的高频题，更是实际项目的高频坑。

2.6 踩坑故事四：z-index: 9999 的军备竞赛

现象：项目里的 z-index 从 10 涨到 100，再到 999、9999，最后有人写了 z-index: 2147483647（32 位整数最大值），结果弹窗还是被遮罩盖住。

原因：z-index 只在同一个层叠上下文内比较。某个父元素一旦因为 transform、opacity < 1、position: fixed 等属性创建了新的层叠上下文，它内部天大的 z-index 也突破不了父级的层级。

flowchart TD
    R["根层叠上下文"] --> A["父容器 A<br/>z-index: 10<br/>(因 transform 成为新层叠上下文)"]
    R --> B["遮罩层 B<br/>z-index: 100"]
    A --> C["弹窗 C<br/>z-index: 99999999<br/>❌ 依然被 B 盖住"]
    style C fill:#ffe4e1

解法：别玩军备竞赛。Vue 项目里弹窗、通知这类组件一律用 <Teleport to="body"> 挂到 body 下，跳出业务 DOM 的层叠上下文，然后从一份常量表里管理有限的几个层级：

// src/constants/z-index.ts —— 全项目只允许用这几个值
export const Z_INDEX = {
  dropdown: 1000,
  sticky: 1020,
  overlay: 1030,
  modal: 1040,
  toast: 1050,
} as const

2.7 踩坑故事五：scoped 样式改不动组件库

现象：想改 Element Plus 按钮的圆角，在 .vue 文件里写了 .el-button { border-radius: 20px; }，毫无效果。

原因：Vue 的 scoped 会给你的选择器加上 [data-v-xxx] 属性后缀，而组件库渲染出来的 DOM 上没有这个属性，选择器匹配不上。

解法：用深度选择器 :deep()：

<style scoped>
/* ✅ 正确：穿透 scoped，作用到子组件内部 DOM */
.my-page :deep(.el-button) {
  border-radius: 20px;
}

/* 注意：前面最好带一个自己页面的类名，避免穿透后污染全局 */
</style>

更进一步的感悟：单组件改样式用 :deep()，但如果是全局性的设计调整（比如全公司项目按钮都用 20px 圆角），应该用组件库的 CSS 变量定制（见第三篇），而不是到处写覆盖。覆盖样式是技术债，CSS 变量才是正路。

2.8 一个完整的小 Demo：响应式卡片列表

把上面讲的 flex/grid、CSS 变量、响应式串起来：

<template>
  <div class="card-grid">
    <article v-for="item in list" :key="item.id" class="card">
      <h3>{{ item.title }}</h3>
      <p>{{ item.desc }}</p>
    </article>
  </div>
</template>

<style scoped>
.card-grid {
  /* 自动填充：每列至少 260px，剩下的均分。不需要媒体查询！ */
  display: grid;
  grid-template-columns: repeat(auto-fill, minmax(260px, 1fr));
  gap: 16px;
  padding: 16px;
}
.card {
  border: 1px solid var(--border-color, #e4e7ed);
  border-radius: 8px;
  padding: 16px;
  transition: box-shadow 0.2s;
}
.card:hover {
  box-shadow: 0 4px 16px rgb(0 0 0 / 10%);
}
</style>

repeat(auto-fill, minmax(260px, 1fr)) 这一行值得抄进你的代码库：一行 CSS 实现「宽屏四列、窄屏一列」的响应式，不需要任何媒体查询和 JS。

2.9 思考：CSS 的功夫在「约束」不在「技巧」

年轻时我以为 CSS 高手是知道很多冷门属性的人。后来带项目才发现，CSS 写得好的人，是给自己设了约束的人：颜色只用变量表里那十几个、间距只用 4 的倍数、z-index 只用常量表里的值。没有约束的自由发挥，三个月后就变成没人敢动的样式屎山。这其实也是设计系统（Design System）的思想雏形。

第三篇主流 UI 组件库：选型、驾驭与避坑

3.1 2026 年的 Vue 组件库格局

flowchart TD
    Q{"你的项目是什么类型？"}
    Q -->|"中后台管理系统"| A["Element Plus<br/>或 Ant Design Vue"]
    Q -->|"追求现代 DX 和 TypeScript"| B["Naive UI"]
    Q -->|"Material Design 风格 / 海外项目"| C["Vuetify"]
    Q -->|"高度定制设计 / 自有设计体系"| D["无样式方案<br/>Headless UI / Radix Vue<br/>+ Tailwind CSS"]

逐个说说我深度使用后的体感：

Element Plus：国内中后台的事实标准。生态最大、资料最多、招人最好招。缺点是默认样式有点「年代感」，以及某些复杂组件（表格、表单）的细节坑比较多。团队项目、要交接给别人的项目，选它不会错。
Ant Design Vue：蚂蚁设计体系的 Vue 移植版，设计规范完整、文档里连「什么时候该用什么组件」都讲了。表单项的校验体验比 Element Plus 细腻。缺点：Vue 版毕竟是移植，更新节奏和细节打磨略逊于 React 版。
Naive UI：一个「很有性格」的库——TypeScript 原生写成，主题系统全部走 JS/TS（不是 CSS 变量），配合 Volar 类型提示非常爽。个人项目、新项目我首推它。缺点是生态相对小，遇到问题搜答案没 Element Plus 那么容易。
Vuetify：Material Design 的完整实现，功能大而全。海外项目或甲方指定 Material 风格时用。包体积偏大，需要做好按需引入。

3.2 踩坑故事六：一次「手贱」升级引发的全站样式错乱

现象：pnpm update 顺手把 Element Plus 从 2.3 升到了 2.7，页面上所有 el-select 的下拉框宽度和位置全乱了。

原因：Element Plus 在中间版本重构了下拉浮层的实现（从旧的 popper 换成新版 floating 机制），类名和结构都变了，我们项目里靠 :deep(.el-select-dropdown) 写的覆盖样式全部失效。

教训，三条：

组件库锁版本：package.json 里组件库版本号不要带 ^，写死，升级走单独 PR，升级前把 CHANGELOG 里的 Breaking Changes 看完。
少写 deep 覆盖，多用官方变量：Element Plus 2.x 大部分视觉定制都能通过 CSS 变量完成：

// styles/element-theme.scss —— 官方推荐的定制方式
@forward 'element-plus/theme-chalk/src/common/var.scss' with (
  $colors: ('primary': ('base': #6c5ce7)),
  $border-radius: ('base': 8px),
);

给 UI 留回归测试的预算：哪怕只是几张关键页面的截图对比（Playwright 的 toHaveScreenshot()），也能让这类升级从「全站翻车」变成「CI 变红，改完再发」。

3.3 踩坑故事七：表格一万行，页面卡成 PPT

现象：后端一次返回了一万条数据（「反正前端会分页的嘛」），el-table 直接渲染，页面滚动时帧率掉到个位数。

解法路线图：

flowchart TD
    A["大数据量表格卡顿"] --> B{"能说服后端分页吗？"}
    B -->|"能，首选"| C["服务端分页<br/>每页 20-50 条"]
    B -->|"不能，数据必须一次展示"| D["虚拟滚动<br/>el-table-v2 / vxe-table"]
    D --> E{"还需要复杂单元格？"}
    E -->|"是"| F["vxe-table<br/>虚拟滚动 + 复杂表格之王"]
    E -->|"否，纯展示"| G["el-table-v2<br/>官方虚拟表格"]

几句实在话：

长列表性能问题，第一解永远是分页。一万条数据对人没有任何浏览价值，只有检索价值。
真要全量展示，普通 el-table 趁早放弃，直接上虚拟滚动（只渲染可视区域的几十行 DOM）。
表格重渲染还常因为每一行都内联了处理函数和作用域插槽，数据量大时把行组件抽出来 + v-memo 能再救一把。

3.4 踩坑故事八：表单校验「有时候不触发」

现象：el-form 的校验规则明明写了，用户快速输入时偶尔能绕过校验提交。

原因：两个叠加问题——表单项的 prop 和 v-model 绑定的字段名不一致（校验根本没绑定上），以及提交时没有 await formRef.validate()，直接发了请求。

正确姿势，背下来这个模板：

<template>
  <el-form ref="formRef" :model="form" :rules="rules">
    <!-- prop 必须等于 form 里的字段名，一字不差 -->
    <el-form-item label="邮箱" prop="email">
      <el-input v-model="form.email" />
    </el-form-item>
  </el-form>
</template>

<script setup lang="ts">
import type { FormInstance, FormRules } from 'element-plus'

const formRef = ref<FormInstance>()
const form = reactive({ email: '' })
const rules: FormRules = {
  email: [
    { required: true, message: '邮箱必填', trigger: 'blur' },
    { type: 'email', message: '邮箱格式不对', trigger: 'blur' },
  ],
}

async function submit() {
  // ✅ 校验不过直接 return，永远不要让请求绕过校验
  const valid = await formRef.value?.validate().catch(() => false)
  if (!valid) return
  await post('/users', form)
}
</script>

3.5 综合 Demo：一个「五脏俱全」的用户管理页

把三篇内容合在一起：HTTP 封装拿数据、Grid/Flex 做布局、Element Plus 出组件。这是中后台最常见的页面形态，也是检验三项基本功的试金石：

<template>
  <div class="user-page">
    <!-- 工具栏：Flex 布局，左侧搜索，右侧操作 -->
    <div class="toolbar">
      <el-input
        v-model="keyword"
        placeholder="搜索用户名"
        clearable
        style="width: 240px"
        @input="onSearch"
      />
      <el-button type="primary" @click="openCreate">新建用户</el-button>
    </div>

    <!-- 表格：服务端分页 -->
    <el-table v-loading="loading" :data="users" stripe>
      <el-table-column prop="name" label="姓名" />
      <el-table-column prop="email" label="email" show-overflow-tooltip />
      <el-table-column label="操作" width="160">
        <template #default="{ row }">
          <el-button link type="primary" @click="openEdit(row)">编辑</el-button>
          <el-button link type="danger" @click="remove(row)">删除</el-button>
        </template>
      </el-table-column>
    </el-table>

    <el-pagination
      v-model:current-page="page"
      v-model:page-size="pageSize"
      :total="total"
      layout="total, prev, pager, next"
      @current-change="fetchUsers"
    />
  </div>
</template>

<script setup lang="ts">
import { ref, onMounted } from 'vue'
import { ElMessageBox, ElMessage } from 'element-plus'
import { get, post } from '@/utils/http'

interface User { id: number; name: string; email: string }

const users = ref<User[]>([])
const total = ref(0)
const page = ref(1)
const pageSize = ref(20)
const keyword = ref('')
const loading = ref(false)

let seq = 0   // 竞态防护：只认最后一次请求
async function fetchUsers() {
  const mySeq = ++seq
  loading.value = true
  try {
    const res = await get<{ list: User[]; total: number }>('/users', {
      params: { page: page.value, size: pageSize.value, kw: keyword.value },
    })
    if (mySeq !== seq) return
    users.value = res.list
    total.value = res.total
  } finally {
    if (mySeq === seq) loading.value = false
  }
}

let timer: ReturnType<typeof setTimeout>
function onSearch() {
  clearTimeout(timer)
  timer = setTimeout(() => { page.value = 1; fetchUsers() }, 300)  // 防抖
}

async function remove(row: User) {
  await ElMessageBox.confirm(`确认删除 ${row.name}？`, '警告', { type: 'warning' })
  await post(`/users/${row.id}/delete`)
  ElMessage.success('已删除')
  fetchUsers()
}

onMounted(fetchUsers)
</script>

<style scoped>
.user-page {
  padding: 16px;
}
.toolbar {
  display: flex;
  justify-content: space-between;
  align-items: center;
  margin-bottom: 16px;
}
</style>

这个页面看起来平平无奇，但里面藏着前面讲的所有功课：请求解包、loading 状态、防抖、竞态防护、服务端分页、flex 工具栏、scoped 样式。「精通」从来不是会多少奇技淫巧，而是这些基本功每一环都不掉链子。

第四篇从「会用」到「精通」：我的几点感悟

4.1 UI 的本质是状态，样式是状态的投影

写久了你会发现，一个页面真正的复杂度不在布局，而在状态：加载中、为空、加载失败、部分成功、无权限、已过期……新手只设计「一切正常」的那个画面，老手写组件前先列状态机：

stateDiagram-v2
    [*] --> Loading: 进入页面
    Loading --> Empty: 请求成功 数据为空
    Loading --> Success: 请求成功 有数据
    Loading --> Error: 请求失败
    Error --> Loading: 点击重试
    Success --> Loading: 刷新/搜索

每个状态对应的 UI 都提前想好，页面就永远不会有「白屏」「转圈转到天荒地老」这种低级体验问题。

4.2 别和组件库对着干

我年轻时花过两周时间，试图把 Element 的表格改成设计师画的「无边框卡片式表格」，覆盖了上百行样式，升级到下个版本全废了。后来的做法是：在组件库的设计体系内做选择，而不是对抗它。设计师给的稿子和组件库默认风格差距大时，拿着组件库的主题定制能力去和设计谈，99% 的情况能在「改三个 CSS 变量」的范围内达成一致。剩下 1% 真正需要高度定制的场景，那就该上无样式方案（Headless UI + Tailwind），而不是魔改有样式库。

4.3 学习路线建议

flowchart LR
    A["第 1-2 个月<br/>HTTP 基础 + flex/grid<br/>能独立写出页面"] --> B["第 3-6 个月<br/>吃透一个组件库<br/>+ 请求封装 + 表单表格"]
    B --> C["第 6-12 个月<br/>性能 虚拟滚动<br/>主题定制 设计系统"]
    C --> D["一年以后<br/>组件设计本身<br/>给团队写基础设施"]

几个反直觉的建议：

CSS 不要靠看视频学，靠调。把你欣赏的网站用 DevTools 打开，把它的布局一层层拆出来，比任何课程都快。
组件库文档要通读一遍，不是背 API，而是知道「它有什么」。不知道有 el-table-v2 的人，遇到性能问题只会想到魔改。
每踩一个坑，写三条笔记：现象、根因、以后怎么一眼认出它。这篇文章里的故事，就是这么攒出来的。

结语

回到开头那张图：UI 页面 = 数据 + 布局 + 组件。HTTP 决定数据来不来得了，CSS 决定页面好不好看，组件库决定你搭得快不快。三样都是「入门一个月、精通好几年」的东西，但好在它们的学习曲线有一个共同点——坑是有限集。本文里的八个坑，你每绕开一个，就离精通近了一步。

祝你的页面没有横向滚动条，弹窗永远在最上层。

前端开发从入门到精通：JavaScript → TypeScript → Vue 3 实战指南

Wed, 10 Aug 2022 09:00:00 +0800

前端开发从入门到精通：JavaScript → TypeScript → Vue 3 实战指南

目标读者：会一点 HTML/CSS，想系统进入前端世界；或者写过大半年 Vue，但总觉得「代码能跑，心里没底」的同学。

这篇文章是我这些年写前端、带新人、修线上事故的一份复盘。它不讲完所有 API（MDN 和官方文档做得比我好），而是讲三件事：

主干知识：每个阶段真正重要的 20% 是什么。
踩坑故事：我自己和身边人真实踩过的坑，比知识点本身更值钱。
思考与感悟：为什么这条路线是 JavaScript → TypeScript → Vue 3，而不是反过来。

先给一张全文的路线图：

flowchart LR
    A["HTML / CSS<br/>页面骨架与样式"] --> B["JavaScript<br/>让页面动起来"]
    B -->|"语言内功"| C["执行模型<br/>作用域 闭包 原型<br/>事件循环 异步"]
    C --> D["TypeScript<br/>类型系统<br/>编译期排错"]
    D --> E["Vue 3<br/>响应式 + 组件化"]
    E --> F["工程化<br/>Vite / Pinia / Router"]
    F --> G["真实项目<br/>能写 能改 能扛事"]

很多新人想跳过 B 和 D 直接学 E，结果写 setup 里的每一行代码都像在背课文。框架是皮，语言是骨。这篇文章的顺序，就是我认为唯一正确的顺序。

第一篇 JavaScript：先把语言的骨头长出来

1.1 JavaScript 到底是什么

一句话版本：一门单线程、基于事件循环、动态类型的脚本语言。

flowchart TB
    subgraph 浏览器
        A["调用栈 Call Stack<br/>同步代码在这里执行"]
        B["宏任务队列<br/>setTimeout / setInterval / IO"]
        C["微任务队列<br/>Promise.then / queueMicrotask"]
        D["Event Loop"]
    end
    A -->|"栈空了就问 D"| D
    D -->|"先清空"| C
    C -->|"清空了再取"| B
    B --> A

「单线程」是理解 JavaScript 一切怪异行为的总钥匙：因为它只有一个调用栈，所以耗时操作绝对不能阻塞它，于是有了回调、Promise、async/await 这一整条异步进化链。

1.2 事件循环：一道面试题背后的真功夫

先看这段代码，你猜输出是什么？

console.log('1');

setTimeout(() => console.log('2'), 0);

Promise.resolve().then(() => console.log('3'));

console.log('4');

答案是 1 4 3 2。规则只有两条：

同步代码在调用栈里，先跑完。
栈空之后，先清空所有微任务，再取一个宏任务。

踩坑故事 1：一个 0ms 的 setTimeout 引发的「灵异事件」

早年我维护一个老后台系统，有个 bug 时好时坏：弹窗打开后表单偶尔是空的。翻代码发现数据加载和弹窗渲染是两拨人写的，中间靠一个 setTimeout(..., 0) 「协调顺序」。它的潜台词是「让数据先加载完」——但 0ms 宏任务只是排到下一轮，数据请求是网络 IO，什么时候回来全看运气。上线第一周没事，用户网络一差就炸。

修复方法不是把 0 改成 100（那是赌得更大），而是用 Promise 把依赖关系显式写出来：fetchData().then(openDialog)。从那以后我立了个规矩：代码里出现魔法数字延时，一律当 bug 处理。

1.3 作用域与闭包：var 的原罪

for (var i = 0; i < 3; i++) {
  setTimeout(() => console.log(i), 100);
}
// 输出：3 3 3

因为 var 没有块级作用域，循环结束后 i 只有一个，三个回调共享同一个 i。改成 let 就好了，因为 let 每次迭代都创建一个新的绑定。

for (let i = 0; i < 3; i++) {
  setTimeout(() => console.log(i), 100);
}
// 输出：0 1 2

闭包就是「函数 + 它出生时看到的词法环境」。下面这个计数器是闭包的标准用法：

function createCounter() {
  let count = 0;          // 外部拿不到，只能通过返回的函数碰它
  return {
    inc() { return ++count; },
    get() { return count; },
  };
}

const counter = createCounter();
counter.inc();
counter.inc();
console.log(counter.get()); // 2

思考：新人常把闭包当面试八股，其实它是 JavaScript 最重要的封装手段。ES Module 普及之前，整个前端世界的模块化都建立在闭包之上（IIFE）。理解了闭包，你就理解了「私有状态」这件事在没有 class 的时代是怎么做到的。

1.4 this：JavaScript 最大的心理阴影

this 的判定规则其实只有一句话：看它怎么被调用，而不是在哪里定义。

flowchart TD
    A["函数被调用时 this 是什么？"] --> B{"new 调用？"}
    B -->|是| C["新创建的对象"]
    B -->|否| D{"call / apply / bind？"}
    D -->|是| E["显式传入的对象"]
    D -->|否| F{"作为对象方法调用 obj.fn()？"}
    F -->|是| G["点号前面的 obj"]
    F -->|否| H["undefined（严格模式）<br/>或 window（非严格）"]
    I["箭头函数：没有自己的 this<br/>永远用定义处的 this"] -.-> A

踩坑故事 2：回调里的 this 丢了

团队新人写过这样的代码：
class UserService {
  constructor() { this.name = '方糖猫'; }
  greet() { console.log(`你好，${this.name}`); }
}
const svc = new UserService();
document.querySelector('#btn').addEventListener('click', svc.greet);
// 点击后输出：你好，undefined
svc.greet 被取出来当回调传递时，调用者变成了 DOM 元素，this 就丢了。排查时新人百思不得其解：「我明明在 class 里定义的！」——这正是 1.4 开头那句话的意思。修法两个：addEventListener('click', () => svc.greet())，或者构造器里 this.greet = this.greet.bind(this)。

这件事对后面学 Vue 很重要：Vue 的 setup 和 Composition API 大量使用普通函数和箭头函数，从根上绕开了 this 的坑，这是它相对 Options API 被推崇的深层原因之一。

1.5 异步进化史：从回调地狱到 async/await

flowchart LR
    A["回调函数<br/>callback"] -->|"嵌套过深<br/>回调地狱"| B["Promise<br/>链式调用"]
    B -->|"then 链仍啰嗦"| C["async / await<br/>同步写法"]
    C -.->|"语法糖"| B

Promise 三种状态的流转是面试和实战的双重重点：

stateDiagram-v2
    [*] --> Pending: new Promise(executor)
    Pending --> Fulfilled: resolve(value)
    Pending --> Rejected: reject(reason) 或抛异常
    Fulfilled --> [*]: .then(onFulfilled)
    Rejected --> [*]: .catch(onRejected)
    note right of Pending
        状态只能流转一次
        且不可逆
    end note

同一个逻辑，三种写法对比：

// 回调时代
getUser(id, function (err, user) {
  if (err) return handle(err);
  getOrders(user.id, function (err, orders) {
    if (err) return handle(err);
    render(orders);
  });
});

// Promise 时代
getUser(id)
  .then(user => getOrders(user.id))
  .then(orders => render(orders))
  .catch(handle);

// async/await 时代
async function showOrders(id) {
  try {
    const user = await getUser(id);
    const orders = await getOrders(user.id);
    render(orders);
  } catch (err) {
    handle(err);
  }
}

踩坑故事 3：await 放进 forEach 里「不生效」
const ids = [1, 2, 3];
ids.forEach(async id => {
  await saveRecord(id);
});
console.log('全部保存完成'); // 这行会先执行！
forEach 不会等回调里的 Promise，它只是把三个 async 函数同时踢出去就完事了。需要串行用 for...of，需要并行用 await Promise.all(ids.map(saveRecord))。这个坑我在 Code Review 里至少见过五次，堪称 async 时代第一坑。

1.6 引用类型与拷贝：看不见的共享

const a = { name: '猫', tags: ['前端'] };
const b = a;            // 不是拷贝，是同一个对象的另一张门牌
b.name = '狗';
console.log(a.name);    // '狗' —— a 也变了

浅拷贝（Object.assign、{...obj}）：只拷第一层，嵌套对象还是共享。
深拷贝：现代浏览器直接用 structuredClone(obj)，别再手写递归了。

踩坑故事 4：改了这个表单，那个弹窗也跟着变

一个配置页有两处编辑入口，打开弹窗时 this.form = rowData。用户在弹窗里改着改着，背后的表格行数据实时跟着变——因为两个变量指向同一个对象。测试没测出来（他们只点了保存），用户取消编辑时发现数据「没保存也生效了」，提了 P1 故障。修法一行：this.form = structuredClone(rowData)。

感悟：JavaScript 里 90% 的「数据莫名变化」，最后都能追到共享引用上。这也是后来 Vue 3 的响应式、Pinia 的 state 管理反复强调「数据流向要清晰」的原因——可变的共享状态是万恶之源。

1.7 Demo：手写防抖与节流

这两个函数是真实项目里用得最多的工具函数，也是检验你闭包和 this 是否真懂了的试金石：

// 防抖：停止触发 n 毫秒后才执行（搜索框联想）
function debounce(fn, delay = 300) {
  let timer = null;
  return function (...args) {
    clearTimeout(timer);              // 闭包记住了上一次的 timer
    timer = setTimeout(() => fn.apply(this, args), delay);
  };
}

// 节流：n 毫秒内最多执行一次（滚动监听）
function throttle(fn, interval = 200) {
  let last = 0;
  return function (...args) {
    const now = Date.now();
    if (now - last >= interval) {
      last = now;
      fn.apply(this, args);
    }
  };
}

// 用法
document.querySelector('#search')
  .addEventListener('input', debounce(e => searchApi(e.target.value), 300));
window.addEventListener('scroll', throttle(onScroll, 200));

记忆法：防抖像电梯门——有人进就重新计时；节流像技能 CD——冷却时间内按了也白按。

1.8 阶段小结

JavaScript 学到什么程度算「入门通关」？我的标准：

能徒手画出事件循环图，并解释任意一段代码的输出顺序。
能写对一个不借助库的 debounce，并且说得清为什么 this 要透传。
知道 let/const 与 var 的全部区别，代码里不再出现 var。
看到共享引用引起的 bug，能在一分钟内定位到「是同一个对象」。

第二篇 TypeScript：给代码买一份编译期保险

2.1 为什么需要 TypeScript

先看一段纯 JavaScript 的日常事故：

function formatPrice(price) {
  return '¥' + price.toFixed(2);
}

formatPrice('19.9');  // 运行时才炸：price.toFixed is not a function

这个错误要到用户点了那个按钮才暴露。TypeScript 做的事，就是把这类错误从「运行时炸给用户看」提前到「写代码时编辑器就红线警告」：

flowchart LR
    A["你写的 TS 代码"] -->|"tsc 编译<br/>类型检查"| B{"有类型错误？"}
    B -->|"是：当场拦住"| C["编辑器红线<br/>CI 直接失败"]
    B -->|"否"| D["擦掉类型<br/>生成纯 JS"]
    D --> E["浏览器运行"]

感悟：很多人对 TS 的第一印象是「麻烦」——要写类型、要应付编译器报错。但我的体会是：TS 不是让你多写代码，而是让你把脑子里本来就该想清楚的东西写下来。一个函数的参数到底是什么形状，本来就该想明白；TS 只是逼你别含糊。项目越大、接手的人越多，这份「写下来」的回报越惊人。

2.2 核心类型速览

// 基础类型
let count: number = 0;
let title: string = '前端之路';
let done: boolean = false;

// 数组与元组
let tags: string[] = ['vue', 'ts'];
let pair: [string, number] = ['vue', 3];

// 联合类型：要么是这个，要么是那个
type Status = 'pending' | 'success' | 'failed';

// interface：描述对象的形状
interface User {
  id: number;
  name: string;
  email?: string;        // 可选
  readonly createdAt: Date;  // 只读
}

// type：更灵活，可以做联合、交叉、映射
type Admin = User & { permissions: string[] };

interface 和 type 的区别不用背，记一句经验法则：描述对象结构优先 interface（可被继承扩展、报错信息更友好），需要联合/交叉/工具类型时用 type。

2.3 泛型：类型的「函数参数」

不写泛型时，你只能二选一：要么 any 放弃检查，要么为每种类型复制一份代码。泛型让你把「类型」当参数传：

// 一个通用的 API 响应包装
interface ApiResponse<T> {
  code: number;
  message: string;
  data: T;
}

interface User {
  id: number;
  name: string;
}

async function fetchUser(id: number): Promise<ApiResponse<User>> {
  const res = await fetch(`/api/users/${id}`);
  return res.json();
}

// 使用时，data 自动推断为 User，点 name 有提示，点 naem 会报错
const resp = await fetchUser(1);
console.log(resp.data.name);

2.4 类型守卫：收窄的艺术

function handle(value: string | number) {
  if (typeof value === 'string') {
    value.toUpperCase();  // 这里 TS 知道 value 是 string
  } else {
    value.toFixed(2);     // 这里 TS 知道 value 是 number
  }
}

自定义守卫在解析后端数据时特别有用：

function isUser(data: unknown): data is User {
  return typeof data === 'object'
    && data !== null
    && 'id' in data
    && typeof (data as User).id === 'number';
}

const raw: unknown = await (await fetch('/api/user/1')).json();
if (isUser(raw)) {
  console.log(raw.name); // 安全
}

2.5 踩坑故事：那些年我们踩过的 TS 坑

踩坑故事 5：any 是会传染的

接手过一个项目，前人为了赶进度，在一个核心工具函数上写了 (data: any)。这个函数的返回值被到处使用，于是 any 像病毒一样扩散——凡是碰过它的变量全部失去类型检查。半年后统计，全项目 40% 的「类型报错被绕过」都能追到这一个 any。最后的修复花了两个人周，从它开始一层层把类型补回来。

教训：any 不是「暂时不管」，是「把错误埋给未来」。实在搞不定第三方数据的类型，用 unknown——它强迫你使用前先做守卫，安全得多。

踩坑故事 6：as 断言骗过了编译器，没骗过运行时
const user = JSON.parse(localStorage.getItem('user')!) as User;
user.name.toUpperCase(); // 某天 localStorage 里是旧版数据，没有 name 字段，线上白屏
as 的意思是「我比编译器更懂」，运行时零校验。localStorage、接口返回、URL 参数——凡是程序边界进来的数据，都不能信。该写守卫写守卫，别偷懒。

2.6 阶段小结

TS 入门标准：

项目里 any 的出现次数趋近于 0，且每次出现都能说出理由。
能给项目的所有 API 请求和响应写出 interface。
会写 Partial<T>、Pick<T, K>、Record<K, V> 这三个最常用的工具类型。
看到 unknown 不慌，知道用守卫收窄。

第三篇 Vue 3：响应式与组件化的艺术

3.1 Vue 3 解决了什么问题

框架存在的意义，一句话：让视图自动跟随数据变化，你只管改数据。

flowchart LR
    A["你修改数据<br/>state.count++"] --> B["Vue 响应式系统<br/>Proxy 拦截到变化"]
    B --> C["找到依赖该数据的<br/>组件渲染函数"]
    C --> D["重新渲染<br/>虚拟 DOM diff"]
    D --> E["最小化更新真实 DOM"]

没有框架时你要写 document.querySelector('#count').textContent = count；有了 Vue，你写 count++，剩下的它管。心智负担从「操作 DOM」变成「操作数据」，这是前端开发史上最重要的一次抽象升级。

3.2 响应式原理：Proxy 魔法

Vue 2 用 Object.defineProperty，Vue 3 换成了 Proxy。这个改变解决了 Vue 2 的两个著名痛点：

flowchart TB
    subgraph Vue2 的痛点
        A1["新增属性不响应<br/>要 this.$set"]
        A2["数组下标修改不响应<br/>要 splice"]
    end
    subgraph Vue3 Proxy
        B1["拦截整个对象<br/>新增属性也能捕获"]
        B2["数组天然支持"]
    end
    Vue2 的痛点 -->|"升级"| Vue3

简化版原理，三十行代码让你理解响应式：

// 极简响应式：不是生产实现，只为理解原理
let activeEffect = null;

function reactive(obj) {
  return new Proxy(obj, {
    get(target, key) {
      track(target, key);        // 收集依赖：谁在用我
      return Reflect.get(target, key);
    },
    set(target, key, value) {
      const result = Reflect.set(target, key, value);
      trigger(target, key);      // 派发更新：通知用我的人
      return result;
    },
  });
}

const state = reactive({ count: 0 });
effect(() => console.log(state.count)); // 建立依赖
state.count++;                           // 自动打印新值

理解了「get 时收集依赖、set 时派发更新」，Vue 3 的响应式在你眼里就没有魔法了。

3.3 第一个 Vue 3 应用：环境搭建

Vue 3 时代的标配工具链是 Vite（冷启动毫秒级，谁用谁知道）：

npm create vite@latest my-app -- --template vue-ts
cd my-app
npm install
npm run dev

项目结构速览：

flowchart TB
    A["src/"] --> B["main.ts<br/>应用入口"]
    A --> C["App.vue<br/>根组件"]
    A --> D["components/<br/>业务组件"]
    A --> E["stores/<br/>Pinia 状态"]
    A --> F["router/<br/>路由"]
    B -->|"createApp(App)<br/>.use(router)<br/>.use(pinia)<br/>.mount('#app')"| C

3.4 Composition API：setup 语法糖

这是 Vue 3 写法的核心。一个计数器组件：

<script setup lang="ts">
import { ref, computed } from 'vue';

const count = ref(0);

// computed：依赖 count，自动缓存，自动更新
const double = computed(() => count.value * 2);

function increment() {
  count.value++;  // 注意：script 里要 .value，template 里不用
}
</script>

<template>
  <p>当前：{{ count }}，翻倍：{{ double }}</p>
  <button @click="increment">+1</button>
</template>

ref vs reactive，新人必问的问题，我的答案：

统一用 ref，除非你明确知道自己在做什么。
ref 包基本类型和对象都行，行为一致；reactive 只能包对象，且解构会失去响应式（见下面的坑）。

3.5 踩坑故事：Vue 3 的那些坑

踩坑故事 7：解构 reactive，响应式当场消失
<script setup lang="ts">
import { reactive } from 'vue';

const state = reactive({ count: 0, name: '猫' });
const { count } = state;  // 完蛋：count 只是个普通数字了

setTimeout(() => { state.count = 99; }, 1000);
// 模板里的 {{ count }} 永远停在 0
</script>
解法：要么不解构（state.count），要么用 toRefs(state)。这个坑的原理很直白：解构出来的是那一刻的值，跟 Proxy 再没有关系了。想通这一点，你对响应式的理解就及格了。

踩坑故事 8：watch 监听对象，怎么不触发？
const user = ref({ name: '猫', age: 3 });

watch(user, (val) => console.log('变了'));  // user.value.age = 4 时不触发！
watch 默认只盯引用的变化（整个对象被替换），user.value.age = 4 改的是内部属性，引用没变。要么 watch(user, cb, { deep: true })，要么更推荐——监听 getter，精确指定你关心什么：
watch(() => user.value.age, (val) => console.log('年龄变了', val));
deep: true 会递归遍历整个对象，大对象上性能开销不小。我见过一个列表页卡成 PPT，就是有人给万行数据加了 deep watch。

踩坑故事 9：v-for 用 index 当 key，列表一排序就乱
<li v-for="(item, index) in list" :key="index">{{ item.name }}</li>
用 index 当 key，列表中间插入或删除一项时，Vue 的 diff 会复用错误的 DOM 和组件状态。真实的症状是：删除第二行，结果第三行的勾选状态「跑」到了第二行上。key 必须用数据里唯一且稳定的标识，通常是 item.id。没有 id？那就造一个，别用 index。

3.6 组件通信：一张图说清所有方式

flowchart TB
    P["父组件"] -->|"props 单向传下去"| C["子组件"]
    C -->|"emit 事件冒上去"| P
    S["兄弟组件 A"] -->|"共享状态"| Store["Pinia Store"]
    Store --> S2["兄弟组件 B"]
    G["祖组件"] -->|"provide"| GG["隔代孙组件"]

铁律只有一条：props 是单向的，子组件不许直接改。

<!-- 子组件：定义 props 和 emits -->
<script setup lang="ts">
const props = defineProps<{ title: string; count: number }>();
const emit = defineEmits<{ (e: 'update', value: number): void }>();

function onClick() {
  // props.count++;  // 错误！单向数据流被破坏
  emit('update', props.count + 1);  // 正确：通知父组件去改
}
</script>

踩坑故事 10：子组件直接改 props，两个人的状态打架

一个弹窗子组件收到父组件传来的 visible，关闭按钮直接写 props.visible = false。表面上能用（基本类型甚至会报错，对象类型能偷偷改成功），但父组件的状态没跟着变，于是出现「弹窗关了，父组件还以为它开着，下次点不开」的灵异 bug。

Vue 官方把这叫做单向数据流，我更愿意叫它「状态的唯一权威来源」：每个状态只能有一个主人，其他人想要变化，只能向主人申请。这条原则在 Pinia、React、Redux 里是通用的，值得刻进肌肉记忆。

3.7 生命周期：什么时候干什么事

flowchart LR
    A["setup()<br/>最早的时机"] --> B["onBeforeMount"]
    B --> C["onMounted<br/>DOM 已就绪<br/>发请求 操作 DOM"]
    C --> D["onBeforeUpdate"]
    D --> E["onUpdated"]
    E -.->|"数据再变"| D
    C --> F["onBeforeUnmount"]
    F --> G["onUnmounted<br/>清定时器 解绑事件"]

最常见的需求对应关系：

发接口请求：onMounted（或 setup 里直接发，视 SSR 需求而定）。
注册定时器/事件监听：onMounted 里注册，onUnmounted 里必须清理，否则组件反复挂载会内存泄漏。

<script setup lang="ts">
import { onMounted, onUnmounted } from 'vue';

let timer: number;

onMounted(() => {
  timer = window.setInterval(fetchData, 5000);
});

onUnmounted(() => {
  clearInterval(timer);  // 不清这个，路由来回切几次就有 N 个定时器在跑
});
</script>

3.8 Demo：一个完整的 TodoList

把上面的知识全部串起来，这是一个可以直接跑的真实组件：

<script setup lang="ts">
import { ref, computed } from 'vue';

interface Todo {
  id: number;
  text: string;
  done: boolean;
}

const todos = ref<Todo[]>([]);
const newText = ref('');
let nextId = 1;

const remaining = computed(() => todos.value.filter(t => !t.done).length);

function addTodo() {
  const text = newText.value.trim();
  if (!text) return;
  todos.value.push({ id: nextId++, text, done: false });
  newText.value = '';
}

function removeTodo(id: number) {
  todos.value = todos.value.filter(t => t.id !== id);
}
</script>

<template>
  <div class="todo">
    <h2>待办（还剩 {{ remaining }} 件）</h2>
    <input
      v-model="newText"
      placeholder="回车添加"
      @keyup.enter="addTodo"
    />
    <ul>
      <!-- 注意：key 用 item.id，不是 index -->
      <li v-for="item in todos" :key="item.id">
        <label :class="{ done: item.done }">
          <input type="checkbox" v-model="item.done" />
          {{ item.text }}
        </label>
        <button @click="removeTodo(item.id)">删除</button>
      </li>
    </ul>
  </div>
</template>

<style scoped>
.done { text-decoration: line-through; color: #999; }
</style>

这个不到 50 行的组件里，藏着这些考点：ref + 泛型、计算属性、v-model 双向绑定、事件修饰符（@keyup.enter）、列表渲染的 key、scoped 样式。面试时让你手写一个，能 10 分钟写出来且 key 用对，Vue 基础就算过关。

3.9 Pinia：跨组件状态的正确姿势

组件多了以后，「A 改了状态 B 也要知道」的需求越来越多，props 一层层传会疯掉。Pinia 是 Vue 3 官方推荐的状态管理：

// stores/user.ts
import { defineStore } from 'pinia';

interface UserState {
  name: string;
  token: string | null;
}

export const useUserStore = defineStore('user', {
  state: (): UserState => ({
    name: '',
    token: null,
  }),
  getters: {
    isLoggedIn: (state) => state.token !== null,
  },
  actions: {
    async login(name: string, password: string) {
      const res = await loginApi(name, password);
      this.name = res.name;
      this.token = res.token;
    },
    logout() {
      this.name = '';
      this.token = null;
    },
  },
});

组件里使用：

<script setup lang="ts">
import { useUserStore } from '@/stores/user';
import { storeToRefs } from 'pinia';

const userStore = useUserStore();
const { name, isLoggedIn } = storeToRefs(userStore); // 保持响应式
// const { name } = userStore;  // 又踩坑 7：解构丢响应式！
</script>

注意 storeToRefs——它和 toRefs 解决的是同一个问题，所以我说坑 7 是 Vue 3 第一大坑，它会换着花样反复出现。

3.10 Vue Router：单页应用的路由

// router/index.ts
import { createRouter, createWebHistory } from 'vue-router';

const router = createRouter({
  history: createWebHistory(),
  routes: [
    { path: '/', component: () => import('@/views/Home.vue') },
    { path: '/user/:id', component: () => import('@/views/User.vue') },
    { path: '/admin', component: () => import('@/views/Admin.vue'),
      meta: { requiresAuth: true } },
  ],
});

// 路由守卫：登录校验的标准位置
router.beforeEach((to) => {
  const userStore = useUserStore();
  if (to.meta.requiresAuth && !userStore.isLoggedIn) {
    return { path: '/login', query: { redirect: to.fullPath } };
  }
});

export default router;

注意路由组件用 () => import(...) 的懒加载写法——首屏只加载首页代码，其余按需加载，这是性能优化的免费午餐。

第四篇工程化与心智成长

4.1 一个项目从代码到上线的完整链路

flowchart LR
    A["本地开发<br/>vite dev 热更新"] --> B["提交代码<br/>ESLint + 类型检查"]
    B --> C["构建<br/>vite build<br/>压缩 分包 指纹"]
    C --> D["部署<br/>静态资源上 CDN / Nginx"]
    D --> E["线上监控<br/>错误上报 性能指标"]
    E -.->|"发现 bug"| A

4.2 从入门到精通的真实分水岭

我带过不少新人，观察下来，「入门」到「精通」之间隔着的从来不是更多 API，而是这几件事：

能从现象推回原理。弹窗数据不同步，能想到共享引用；列表状态错乱，能想到 key；数据改了视图没变，能想到响应式丢失。原理是那把万能钥匙。
对异步有敬畏心。接口时序、竞态、取消请求，这些才是真实项目里最贵的 bug 来源。
状态有主人。任何一份数据，都能一句话说清「谁拥有它、谁能改它」。
敢看源码。从 structuredClone 到 Vue 的 track/trigger，你会发现那些「魔法」拆开看都朴素得很。

4.3 一些真心话

关于学习顺序：直接学 Vue 能不能干活？能。但你会在第一次遇到 this 丢失、响应式消失、异步时序问题时卡住，因为你缺的是底下的地基。JavaScript → TypeScript → Vue 3 这条路看着绕，其实是最短的。

关于框架之争：React、Vue、Angular 吵了很多年，但响应式、组件化、单向数据流这些核心思想是相通的。把一门学透，换另一门是周级别的事；门门都浅尝，换哪门都是从头开始。

关于 AI 时代：现在让 AI 写一个 TodoList 只要十秒钟。但上面那些坑——共享引用、解构丢响应式、await forEach——AI 生成的代码照样会犯，而能看出来它错了的人，才能驾驭它。越是工具强大，基本功越不是可有可无，而是你最硬的议价能力。

结语

这条路线走下来，你收获的不仅是「会写 Vue」，而是一套完整的思维方式：用 JavaScript 理解运行，用 TypeScript 管理复杂度，用 Vue 组织界面，用工程化把这一切交付给真实用户。

入门的标志是你能写出功能；精通的标志，是你能在深夜的故障群里，三分钟说出一句：「我知道问题出在哪。」

祝你也早日成为那样的人。

Vue 3 on 方糖猫Blog

前端 UI 开发从入门到精通（Vue 技术栈）：HTTP、CSS 与主流组件库实战

前端 UI 开发从入门到精通（Vue 技术栈）：HTTP、CSS 与主流组件库实战

第一篇 HTTP：数据是怎么到页面上的

1.1 一次请求的完整旅程

1.2 先懂协议，再谈封装

1.3 一个生产可用的请求封装（Demo）

1.4 踩坑故事一：那个只在测试环境出现的跨域

1.5 踩坑故事二：疯狂抖动的搜索框

1.6 思考：请求封装是在封装「约定」

第二篇 CSS：UI 开发的半壁江山

2.1 先建立一个心智模型

2.2 盒模型：一切从盒子开始

2.3 布局：Flex 管一维，Grid 管二维

2.4 现代 CSS 三件套：变量、容器查询、:has()

2.5 踩坑故事三：flex: 1 了，为什么还是不生效

2.6 踩坑故事四：z-index: 9999 的军备竞赛

2.7 踩坑故事五：scoped 样式改不动组件库

2.8 一个完整的小 Demo：响应式卡片列表

2.9 思考：CSS 的功夫在「约束」不在「技巧」

第三篇 主流 UI 组件库：选型、驾驭与避坑

3.1 2026 年的 Vue 组件库格局

3.2 踩坑故事六：一次「手贱」升级引发的全站样式错乱

3.3 踩坑故事七：表格一万行，页面卡成 PPT

3.4 踩坑故事八：表单校验「有时候不触发」

3.5 综合 Demo：一个「五脏俱全」的用户管理页

第四篇 从「会用」到「精通」：我的几点感悟

4.1 UI 的本质是状态，样式是状态的投影

4.2 别和组件库对着干

4.3 学习路线建议

结语

前端开发从入门到精通：JavaScript → TypeScript → Vue 3 实战指南

前端开发从入门到精通：JavaScript → TypeScript → Vue 3 实战指南

第一篇 JavaScript：先把语言的骨头长出来

1.1 JavaScript 到底是什么

1.2 事件循环：一道面试题背后的真功夫

1.3 作用域与闭包：var 的原罪

1.4 this：JavaScript 最大的心理阴影

1.5 异步进化史：从回调地狱到 async/await

1.6 引用类型与拷贝：看不见的共享

1.7 Demo：手写防抖与节流

1.8 阶段小结

第二篇 TypeScript：给代码买一份编译期保险

2.1 为什么需要 TypeScript

2.2 核心类型速览

2.3 泛型：类型的「函数参数」

2.4 类型守卫：收窄的艺术

2.5 踩坑故事：那些年我们踩过的 TS 坑

2.6 阶段小结

第三篇 Vue 3：响应式与组件化的艺术

3.1 Vue 3 解决了什么问题

3.2 响应式原理：Proxy 魔法

3.3 第一个 Vue 3 应用：环境搭建

3.4 Composition API：setup 语法糖

3.5 踩坑故事：Vue 3 的那些坑

3.6 组件通信：一张图说清所有方式

3.7 生命周期：什么时候干什么事

3.8 Demo：一个完整的 TodoList

3.9 Pinia：跨组件状态的正确姿势

3.10 Vue Router：单页应用的路由

第四篇 工程化与心智成长

4.1 一个项目从代码到上线的完整链路

4.2 从入门到精通的真实分水岭

4.3 一些真心话

结语

第三篇主流 UI 组件库：选型、驾驭与避坑

第四篇从「会用」到「精通」：我的几点感悟

第四篇工程化与心智成长