跳至主要内容

为懂js html css基础的人写一个vue的入门文档,以便学后可以使用claude code开发vue单页应用 因此也不要有过多代码细节 着重原理概念以及用法的讲解

Vue 入门指南(面向 Claude Code 开发者)

写给已经掌握 JS / HTML / CSS 基础的你。本文只讲原理和用法,不堆代码细节——因为具体代码可以交给 Claude Code 写,你需要的是看懂它在做什么、能提出正确的需求、能读懂输出的结果。


一、Vue 解决了什么问题

原生 JS 开发页面时,你需要手动操作 DOM:数据变了,自己找到对应的 DOM 节点,手动更新内容。页面越复杂,这种"数据 → 手动改 DOM"的代码就越难维护。

Vue 的核心思路是声明式渲染 + 响应式数据

  • 你只需要描述"页面长什么样,取决于哪些数据"(模板);
  • 数据变化时,Vue 自动帮你找到需要更新的 DOM 并更新它。

你不再写"如何更新界面",只写"界面应该是什么样"。这是从命令式编程到声明式编程的转变,也是所有现代前端框架(Vue/React/Angular)共同的思路。


二、响应式数据:Vue 的核心机制

这是 Vue 最重要的概念,务必理解。

普通 JS 变量赋值后,没有人知道它变了。Vue 提供了 ref()reactive() 两个函数,把普通数据"包装"成响应式数据——本质是给数据加上了"监听器",一旦被修改,Vue 会自动通知所有用到它的地方去更新。

  • ref():包装单个值(数字、字符串、布尔值,也可以是对象),使用时需要通过 .value 访问。
  • reactive():直接包装一个对象,不需要 .value,但不能重新赋值整个对象(只能改内部属性)。

实际开发中 ref() 用得更多,因为它更灵活、限制更少。你不需要记住实现细节,只需要知道:想让一个数据"活起来"(改了就自动刷新界面),就用 ref 包一下


三、模板语法:数据如何显示到页面上

Vue 的模板本质上还是 HTML,但加了几种特殊写法:

语法 作用
{{ 变量 }} 把 JS 表达式的值插入到文本中
v-bind:属性(简写 :属性 把 HTML 属性绑定到某个变量,变量变了属性也跟着变
v-on:事件(简写 @事件 绑定事件处理函数,比如点击、输入
v-if / v-else 条件渲染,满足条件才显示这块内容
v-for 循环渲染,通常配合数组使用,生成列表
v-model 双向绑定,专门用于表单输入,输入框内容和变量自动同步

理解这张表格,你就能看懂 90% 的 Vue 模板代码。它们本质上都是"把数据和 DOM 的某个部分关联起来"的不同方式。


四、组件:把页面拆成积木

组件是 Vue 应用的基本单位。一个组件包含"这块界面长什么样 + 它自己的数据和逻辑",可以像搭积木一样在别的地方重复使用。

三个关键概念:

  1. Props(属性传递):父组件传数据给子组件,类似给积木传参数。子组件不能直接改父组件传来的数据,只能"用"。
  2. Emit(事件触发):子组件想通知父组件发生了什么(比如按钮被点了),通过触发一个自定义事件,父组件监听这个事件来做反应。数据是"单向向下流动,事件向上通知",这是 Vue(以及大多数框架)组件通信的基本模式。
  3. Slot(插槽):父组件可以往子组件"内部"塞一段自定义内容,类似 HTML 里往容器标签中放子元素。

你不需要一开始就精通这些,但要理解:一个页面 = 若干组件的组合,组件之间通过 props 向下传数据、通过事件向上传通知


五、单文件组件(.vue 文件)

Vue 项目里,每个组件通常写在一个 .vue 文件里,结构固定为三块:

<template>   ← 这块是 HTML 模板,长什么样
<script setup>  ← 这块是 JS 逻辑,数据和方法
<style>      ← 这块是 CSS 样式,只作用于当前组件

这就是所谓的"关注点分离"落地到单个文件里:结构、逻辑、样式放在一起管理,但互不干扰。<script setup> 是目前推荐的写法(组合式 API 的语法糖),比早期的"选项式 API"更简洁,Claude Code 生成的代码大概率也是这种风格。


六、计算属性与侦听器

  • 计算属性(computed:基于已有数据,自动算出一个新值,并且这个值会被缓存,只有依赖的数据变了才重新计算。适合"由其他数据派生出的值",比如根据购物车商品算总价。
  • 侦听器(watch:监听某个数据的变化,变化时执行一段逻辑(比如发请求、打日志)。适合"数据变了要做点什么副作用"的场景。

简单区分:要展示一个算出来的值 → 用 computed;数据变化后要做点动作 → 用 watch。


七、生命周期:组件的"一生"

每个组件从创建、挂载到页面、更新、最后销毁,都要经历几个阶段,Vue 允许你在特定阶段插入自己的代码,最常用的是:

  • 挂载完成时(组件已经出现在页面上):适合发起网络请求、初始化第三方库。
  • 销毁前:适合清理定时器、取消订阅,防止内存泄漏。

刚开始不用记全部生命周期钩子,知道"组件出现在页面上那一刻可以做什么"就够用了。


八、单页应用(SPA)为什么需要路由

单页应用只有一个 HTML 页面,"切换页面"其实是在不刷新浏览器的情况下,动态替换页面内容。这需要一个路由库(Vue 生态里是 vue-router)来实现:

  • 你定义一份"路径 → 组件"的映射表(比如 /home 对应首页组件,/about 对应关于页组件);
  • 路由库监听地址栏变化,自动切换显示对应组件;
  • 你可以用代码或链接跳转路由,也可以传参数(比如 /user/123 里的 123)。

只要你的项目有"多个页面/多个视图",就基本离不开路由。


九、状态管理:数据要不要"全局共享"

小项目里,组件间传数据用 props/emit 就够了。但项目变大后,经常出现"很多不相关的组件都要用同一份数据"(比如登录用户信息、购物车),一层层传参会很痛苦。

这时用状态管理库(Vue 生态目前推荐 Pinia):把这些公共数据放到一个全局的地方统一管理,任何组件都可以直接读取或修改,不用一层层传递。

判断标准很简单:只有一两个组件用的数据,不需要它;很多不相关组件都要用的数据,才考虑它。


十、项目是怎么跑起来的:构建工具

现代 Vue 项目依赖 Vite 这样的构建工具,作用是:

  • 开发时:启动一个本地服务器,代码改了自动刷新(热更新),让你实时看到效果;
  • 打包时:把所有 .vue、JS、CSS 文件处理、压缩、合并成浏览器能直接运行的静态文件,用于部署上线。

一个典型项目的目录大致是:

src/
  components/   放可复用的小组件
  views/        放页面级组件(配合路由)
  App.vue       根组件
  main.js       入口文件,创建 Vue 应用

你不需要手写这套结构,用脚手架命令(npm create vue@latest)会自动生成,Claude Code 通常也会遵循这个约定。


十一、和 Claude Code 配合开发的建议

  1. 先想清楚"页面"和"数据",再动手:一个 SPA 大致有哪几个页面(对应路由)、哪些数据需要跨组件共享(对应 Pinia),想清楚这两点,给 Claude Code 的需求描述会更准确。
  2. 按组件粒度提需求:与其说"帮我做个后台系统",不如说"做一个用户列表组件,接收 users 数组作为 props,支持点击删除并触发事件通知父组件"——描述越贴近本文的概念(props/emit/v-for),生成的代码越符合预期。
  3. 看得懂 diff 比会写代码更重要:你不需要从零手写 Vue 代码,但当 Claude Code 改了某个 .vue 文件时,你应该能看懂它改的是模板(界面结构)、脚本(数据逻辑)还是样式,判断改动是否合理。
  4. 遇到报错,先定位是哪一层:是模板语法写错了(比如指令用错)、是响应式数据没包对(该用 ref 却直接赋值)、还是组件通信断了(props 没传对,emit 没监听)——这三类是新手最常见的问题类型,报错信息通常会提示。

小结

Vue 的知识体系可以浓缩成一句话:用响应式数据描述状态,用模板声明式渲染界面,用组件拆分复杂度,用路由和状态管理解决"多页面/多组件协作"的问题。掌握这套思路后,具体的语法细节完全可以在实际用 Claude Code 开发的过程中,边看代码边熟悉。

此博客中的热门博文

Elasticsearch 读写原理指南

### 1. 什么是 segment,里面装了什么? 在 Lucene(也是 Elasticsearch)里,索引被切分成若干 **segment(段)**,每个 segment 是一个完整的、只读的倒排索引单元。一个 segment 包含: * **倒排词典** —— 用 **FST(Finite‑State Transducer)** 以高度压缩的形式保存每个字段出现的所有 term 以及 term→ord 的映射。对应的磁盘文件是 `*.tim`(新版)或 `*.tis/*.tii`(旧版)。 * **倒排列表(postings)** —— 保存每个 term 出现的文档 ID、频次、位置信息等,文件名通常是 `*.doc`、`*.pos`、`*.pay`。 * **存储字段**(_source、store:true 的字段)—— 以二进制块的形式写入 `*.fdt` / `*.fdx`。 * **doc‑values、norms、向量** 等辅助结构,分别保存在 `*.dv`、`*.norm`、`*.tv` 等文件里。 * **deleted‑docs bitmap**(`*.del`),标记哪些文档已被删除或被更新。 所有这些文件在 segment **写入磁盘后即成为只读**,后续的查询只能读取,永远不会在原文件上进行增删改。 --- ### 2. 原始文档和 FST 为什么都在 segment 里? * **原始文档**:Elasticsearch 默认把完整的 JSON(_source)以及任何 `store:true` 的字段写入 segment 的 `*.fdt/*.fdx` 文件。每个 segment 保存自己的那部分文档,旧的 segment 在合并前仍然保留,直到合并后被删除。 * **FST**:每个字段的词典在每个 segment 中单独维护,采用 FST 进行前缀共享和字节压缩。这样即使同一个 term 在多个 segment 中出现,也会在每个 segment 里拥有独立的映射,查询时只需要在对应 segment 的 FST 中定位即可。 --- ### 3. 查询时到底是怎么遍历 segment 的? 1. **请求入口**      客户端的搜索请求先到达 **协调节点**,协调节点把请求 ...

事务的ACID是什么

 事务的 ACID 是数据库事务必须满足的四个基本性质,用来保证在并发和故障情况下数据的正确性与可靠性: A(Atomicity,原子性) 一个事务中的操作要么 全部成功 ,要么 全部失败回滚 ,不存在“只做了一半”的中间状态。 C(Consistency,一致性) 事务执行前后,数据库都必须处于 一致的合法状态 ,满足约束(如主键、外键、唯一性、业务规则等)。 I(Isolation,隔离性) 并发执行的多个事务之间 相互隔离 ,一个事务未提交的中间结果对其他事务不可见(具体强弱由隔离级别决定)。 D(Durability,持久性) 一旦事务提交成功,其结果会被 永久保存 ,即使系统崩溃也不会丢失(通常依赖 WAL/redo log 等机制)。 一句话记忆: 要么全做完、前后不破坏规则、互不干扰、做完不丢。

LLM缓存详解

 可以把“大模型缓存”理解成: 把已经算过的结果(或中间结果)存下来,下次尽量复用 。但这里面其实分几层,不只是简单的“问题→答案”缓存。 1️⃣ 常见的几种缓存类型 (1)KV Cache(推理内部缓存) Transformer 在生成时,会把前面 token 的 Key/Value 向量 缓存下来。 本质:避免重复计算 attention 作用: 同一请求内部加速 特点: 👉 只对“同一上下文继续生成”有效 👉 不跨用户、不跨请求 这类缓存是你体感“流式输出越来越快”的原因之一。 (2)Prompt Cache(提示词缓存) 缓存的是: 相同(或高度相似)的 prompt → 对应的中间表示 / 输出 典型场景: 系统提示词(system prompt)很长 多轮对话里前文基本不变 👉 这里能省掉 前缀计算成本(prefill) (3)Embedding / 语义缓存(Semantic Cache) 这个才是你问题的关键 👇 不是按“字符串完全一致”,而是: 把问题转成向量 → 找“语义相似”的历史问题 → 直接复用答案 2️⃣ 为什么命中缓存成本低很多? 因为大模型推理成本主要在两块: (1)Prefill(吃 prompt) 复杂度 ~ O(n²) 很贵(尤其长 prompt) (2)Decode(逐 token 生成) 每个 token 都要算一遍模型 而缓存命中后: KV cache:不用重复 attention Prompt cache:不用重新 encode 语义缓存: 直接跳过模型推理 👉 相当于从: 几十~几百毫秒 + GPU算力 变成: 一次向量检索(毫秒级)+ 直接返回 所以成本差一个数量级是正常的。 3️⃣ “每个人问法不同,怎么命中缓存?” 这是核心难点,也是工程重点👇 ❌ 不能靠字符串匹配 比如: “今天天气怎么样” “今天外面热不热” 字符串完全不同 → 必须 miss ✅ 用语义相似度(Embedding) 流程一般是: 把问题转 embedding(向量) 在向量数据库里找 TopK 相似问题 如果相似度 > 阈值(比如 0.9) 直接返回缓存答案 一个简单示意 Q1: 北京天气怎么样 → embedding A Q2: 北京今天热吗 → embedding B cosine(A, B) ≈ 0.95...