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

很多人一开始会背：

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

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

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

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

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

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

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

所以这个阶段更适合：

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

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

## mounted 才适合碰 DOM

如果你要做的是：

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

那就更适合放在 `mounted`。

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

## updated 不是补丁桶

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

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

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

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

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

例如：

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

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

## 写在最后

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

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


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


Vue 的单文件组件很舒服，这点几乎不用争。

可写得舒服，并不代表天然就能一直保持清晰。很多 `.vue` 文件一开始只有几十行，后面慢慢加请求、加校验、加交互、加样式，最后变成几百行的“大组件”。

## 真正的问题不在文件后缀

`.vue` 文件只是容器，问题还是回到组织方式。

一个组件如果同时承担：

- 数据请求
- 状态处理
- 页面布局
- 表单逻辑
- 弹窗控制

那无论是不是单文件组件，后面都会变重。

## 写在最后

Vue 单文件组件最大的优势，是让组件边界更完整；但如果把太多职责硬塞进一个文件，这个优势也会被自己抵消掉。

组件写久了以后，真正拉开差距的不是格式，而是组织节奏。


Vue 单文件组件写久了以后，真正拉开差距的是组织方式


前端开发里经常会遇到“这个数据要不要存在浏览器里”的问题。

这时大家最常接触到的几种能力通常是：

- Cookie
- sessionStorage
- localStorage

它们都能在浏览器端保存数据，但用途和边界并不完全一样。

## Cookie 的特点

Cookie 出现得比较早，最重要的特点之一是，它可以随请求一起带到服务端。

这也是它在登录状态、会话相关场景里经常被提到的原因。

但 Cookie 本身不适合保存太多数据，因为它体积有限，而且每次请求都可能附带。

## sessionStorage

`sessionStorage` 更适合保存当前会话期间的数据。

它的典型特点是：

- 只在当前标签页会话中有效
- 页面关闭后通常会清除

所以它适合一些短期状态，例如当前页面的临时输入、某个流程中的中间值等。

## localStorage

`localStorage` 的特点是保存时间更长。

只要用户没有手动清除，数据通常会一直保留。

它适合：

- 用户偏好设置
- 搜索历史
- 草稿缓存

但也要注意，不要把敏感信息随意长期存在本地。

## 它们最大的区别是什么

可以从两个角度看：

### 1. 生命周期

- Cookie 可以设置过期时间
- `sessionStorage` 跟随当前会话
- `localStorage` 更持久

### 2. 是否自动参与请求

- Cookie 会和请求一起发送
- `sessionStorage` 和 `localStorage` 不会自动带给服务端

这个区别非常关键。

## 写在最后

浏览器端存储方式很多，但关键还是要理解它们各自的边界。

Cookie 更偏会话和服务端协同，`sessionStorage` 更适合短期会话数据，`localStorage` 更适合本地长期偏好类信息。只要把生命周期和使用场景理清楚，选择起来就不会太混乱。


浏览器存储方式简单梳理：Cookie、sessionStorage 和 localStorage 有什么区别


前端开发近几年的编码体验变化，很大一部分都来自 JavaScript 语言本身的演进。

ES6 之后，很多过去写起来很别扭的代码，开始变得更自然。它的价值不只是语法更好看，而是让代码表达能力更强了。

## let 和 const 让变量语义更清楚

以前大家主要使用 `var`，它在作用域和提升上的行为比较容易引发困惑。

`let` 和 `const` 的出现，让变量声明的意图更明确：

- `let` 表示后续可能修改
- `const` 表示引用不再重新赋值

这能显著减少一些低级错误。

## 模板字符串让拼接更自然

过去拼接字符串时，代码经常会变得很碎：

```javascript
var text = 'Hello, ' + name + '!';
```

模板字符串让这种表达更直观：

```javascript
const text = `Hello, ${name}!`;
```

这看起来只是语法糖，但在构造复杂文本时体验差别非常明显。

## 解构赋值提升了可读性

对象和数组解构是 ES6 里非常实用的能力。

例如：

```javascript
const user = { name: 'Tom', age: 18 };
const { name, age } = user;
```

它的价值在于，把“我要用哪些字段”直接写在赋值处，让代码更聚焦。

## 箭头函数简化了函数表达

箭头函数最大的好处不只是短，而是让很多短小逻辑写起来更自然。

例如：

```javascript
const list = items.map(item => item.name);
```

这种写法在数组操作、回调和函数组合里非常常见，也大幅提升了函数式写法的可读性。

## Promise 改变了异步代码结构

虽然异步问题并不是 ES6 才出现，但 Promise 让异步流程开始有了更统一的表达方式。

相比层层嵌套的回调，它至少让流程关系更清楚。

这也为后来的 `async/await` 铺平了道路。

## 模块化能力意义很大

ES6 模块并不只是语法更新，它实际上推动了前端工程结构进一步标准化。

通过 `import` 和 `export`，代码之间的依赖关系变得更清楚，也更适合现代构建工具处理。

## 新特性的价值不在“高级”，而在“更稳定”

很多人学习 ES6 时会关注“有哪些新语法”，但真正更重要的问题其实是：

这些能力是不是让代码更容易读、写、改和协作。

从这个角度看，不少 ES6 特性之所以重要，不是因为它们炫，而是因为它们让前端开发更成熟了。

## 写在最后

ES6 对前端开发的影响，远不只是多了几种新写法。它真正改变的是代码组织方式和表达效率。

当你回头看这些常用能力，会发现它们已经逐渐成为现代前端开发的基础配置。好的语言特性不是让代码显得更高级，而是让日常开发更顺手、更稳定。


ES6 常用特性回顾：真正改变前端开发体验的是哪些能力


去年做一个 AI 写作辅助功能的时候，我们前后换了两次模型。第一次是因为结果不稳，第二次是因为延迟偏高。换完以后效果确实有变化，但那种“有时很好，有时很飘”的感觉一直没有消失。

最开始团队里很自然地把问题归到模型头上。毕竟结果是模型吐出来的，出问题先怀疑模型很正常。可后来排查得越多，我越觉得另一个东西更像根源：上下文。

那个功能的目标并不复杂，用户给一个主题，系统结合历史记录、模板偏好和参考资料，帮他起草一段内容。听上去很像是一个“选模型 + 写 prompt”的问题，实际做下来，最难控的反而是给模型喂什么。

## 我第一次意识到问题不在模型，是在一次线上回放里

那次用户问的是一个非常具体的问题，理论上系统应该直接围绕当前主题写。结果模型先引用了上一次会话里的偏好，又混进了一段不相干的参考资料，最后写出来的内容语气对、格式也对，但方向完全偏了。

如果只看最终结果，你会觉得是模型在胡说。可把整条输入链路拆开看，其实它只是很认真地在错误材料上做推断。

那一刻我才真正意识到：模型根本不“知道自己在哪个产品里”，它只知道当前这坨上下文长什么样。

你给它干净输入，它就大概率干净输出。

你给它混乱输入，它再强也很难一直稳。

## 上下文管理最容易出问题的地方，不是少，而是乱

最开始我们总怕模型信息不够，于是策略非常朴素：尽量多给。

历史对话带上。
用户偏好带上。
参考资料多拿几段。
系统规则写长一点。
模板说明也顺手塞进去。

表面上看很周全，实际效果却越来越不稳定。后面回头看，这种“尽量多给”的思路有两个明显问题。

第一，重要信息比例被稀释了。

用户当前真正的问题，可能只占整个上下文的一小截。模型当然能看到它，但也同样看到了很多次要甚至过期的信息。

第二，旧信息会持续污染新任务。

一旦历史里有过错误判断、过时意图或者已经无效的中间结论，它们就可能继续影响当前回答。你以为自己是在做“多轮记忆”，实际上是在把噪声不断续上去。

## 后来我们做的第一件事，不是换模型，而是拆信息层级

那次改完之后，我们不再把所有信息简单拼成长文本，而是先把上下文按层次拆开。

我现在做 AI 应用时，基本都会先把输入分成这几层：

1. 系统规则
2. 当前任务目标
3. 用户本轮输入
4. 历史记忆
5. 外部检索或工具结果

这几层最重要的价值，不是格式好看，而是你终于能问自己一句：这个信息到底为什么出现在这里？

比如：

- 系统规则是长期边界，不该混进具体任务噪声
- 当前任务目标应该比历史会话优先级更高
- 历史记忆只保留必要背景，不该变成聊天记录堆积
- 检索结果必须为当前问题服务，而不是“顺手都带上”

一旦这么拆，很多以前糊在一起的问题会立刻显形。

## 历史记忆不是越长越好，这一点我后来感受很深

做对话型 AI 功能时，最容易陷进去的就是“记忆越多越聪明”。

实际并不是这样。

我们后面专门抽了一批失败样本看，发现最容易出问题的往往不是信息太少，而是带着一堆不该留下来的历史过程：

- 上一轮试错里的错误结论
- 已经被用户否定的方向
- 某次临时偏好
- 中间工具返回的半成品数据

这些东西只要留在上下文里，模型就有可能继续把它们当真。

后来我们把历史记忆改成“只保留长期偏好和关键事实”，效果反而稳了很多。比如保留：

- 用户偏好中文输出
- 用户正在做 React 项目
- 当前会话在写技术博客

而不是把整段过程都背下去。

## 检索上下文也一样，重点不是多，而是贴题

RAG 场景下这个问题会更明显。

以前我们的做法是召回多一点，觉得总比漏掉好。结果经常出现一种情况：模型拿到了十段资料，里面只有两段真有用，剩下八段只是“看着也有点关系”。这些噪声不会直接报错，但会把注意力拉散。

后来我越来越认可一个更朴素的判断标准：

- 这段内容是不是和当前问题强相关
- 它能不能减少模型猜测

如果答案都是否定的，那它就不该进上下文。

这也是我现在看检索系统时最在意的地方。它不是负责“多给内容”，而是负责“别把不该给的内容也塞进去”。

## 工具调用结果如果不清洗，也是在制造噪声

另一个很容易被低估的点，是工具结果。

很多 Agent 类应用会把工具输出原样拼回模型，图省事，但这一步经常会埋雷。

例如一个搜索工具可能返回：

- 大量无关字段
- 多个候选结果
- 冗长元数据
- 不统一的格式

模型当然可以继续读，但这等于又把一轮筛选工作丢给它了。这样不只是浪费上下文窗口，更会让后续推理开始飘。

我们后来处理工具结果时，会先做一轮清洗：

- 只保留关键字段
- 统一格式
- 必要时做小摘要

这一步做完之后，模型输出明显稳了一截。不是因为它突然更聪明了，而是因为前面的输入终于更像人给它整理过的材料。

## 我现在看 AI 应用，越来越像在看一个信息编排系统

以前我会更多地把注意力放在模型本身：哪个版本更强，哪个延迟更低，哪个价格更合适。

现在还是会看这些，但我更先问的是：

- 当前任务到底需要哪些信息
- 这些信息谁先谁后
- 哪些该长期保留，哪些只对本轮有效
- 哪些内容可能污染后续回答

如果这些问题没想清楚，换再好的模型也很难彻底解决“有时很好，有时很怪”的波动。

## 写在最后

我现在越来越相信，AI 应用里真正难的，不是把模型接上，而是把上下文管住。

模型当然重要，但很多所谓“模型不稳定”的问题，最后都能追溯到输入组织得不够干净。谁能把对的内容、按对的层级、在对的时机交给模型，谁的系统通常就更稳。模型选型会变，上下文治理能力才是更长期的竞争力。


做 AI 应用时，为什么上下文管理比模型选型更容易决定成败


每隔一段时间，就会有人说 Prompt 工程不重要了。

理由也总是类似：

- 模型更强了
- 指令理解更好了
- 多模态更完整了
- 工具调用更成熟了

这些判断不算错，但如果因此得出“Prompt 随便写就行”，那通常会在业务落地时很快吃亏。

## Prompt 真正的价值，不是花哨，而是约束

一提到 Prompt 工程，想到的是：

- 角色扮演
- 语气模板
- 一长串提示词咒语

这些东西有时有用，但不是核心。

在真实业务里，Prompt 更重要的作用通常是三件事：

1. 定义任务边界
2. 约束输出格式
3. 降低不必要的自由发挥

大模型本质上非常擅长“补全一个看起来合理的答案”。如果你不给边界，它往往就会把“有帮助”理解成“多说一点也没关系”。

这在聊天场景可能还好，在业务系统里就不稳定了。

## 业务系统里的 Prompt，首先要解决“不要乱答”

比如一个工单分类系统，如果你的目标是输出固定标签，那么最重要的就不是“写得像资深分析师”，而是：

- 只输出枚举值
- 不要附加解释
- 信息不足时返回兜底项

例如：

```text
你需要判断用户问题所属类别。

可选类别只有：
- 退款
- 发货
- 售后
- 账户
- 其他

只返回一个类别名称，不要返回解释。
如果信息不足，返回“其他”。
```

这个 Prompt 的重点不是优雅，而是稳定。

## 输入结构比形容词更重要

不少 Prompt 效果不稳定，不是因为措辞不够“高级”，而是输入结构太乱。

例如下面两种写法：

```text
帮我总结这段内容。
```

和：

```text
任务：总结以下用户反馈
目标：提炼 3 条主要问题
输出要求：
1. 使用中文
2. 每条不超过 20 字
3. 不要复述原文

原始内容：
...
```

后者更稳定，不是因为字更多，而是因为结构更清楚。

在业务里，模型通常更怕“输入混乱”，而不是“提示词不够华丽”。

## 输出格式必须显式

如果结果要被后续程序消费，Prompt 里一定要明确输出格式。

例如：

- JSON
- Markdown 表格
- 固定字段列表
- 单标签结果

否则模型很容易：

- 多加说明文字
- 改字段名
- 改层级结构
- 在某些边缘输入下换一种表达

这些变化对人看问题不大，对程序来说却可能直接出错。

## 少承诺，多兜底

一个成熟 Prompt 的特征，不是“无论什么问题都答得像专家”，而是：

- 知道什么时候该回答
- 知道什么时候该拒答
- 知道什么时候该返回不确定

例如加入这样的约束：

- 如果缺少必要信息，明确说明信息不足
- 如果输入超出知识范围，直接返回兜底结果
- 不要猜测未提供的事实

这类约束看起来保守，但在业务里通常更值钱。

## Prompt 需要和系统设计一起看

Prompt 工程从来都不只是写一段文本。

在真实系统里，它通常要和下面这些东西一起设计：

- 上下文拼装
- 检索结果质量
- 工具调用协议
- 输出解析器
- 错误重试策略

如果上游上下文已经很差，Prompt 再精致也救不了。

反过来，如果上下文质量高、输入结构清晰、输出格式受控，Prompt 往往不需要特别花哨也能很稳定。

## 什么时候应该“少写 Prompt”

这点也很重要。

如果你发现一个 Prompt 越写越长，加入了大量例外条件、补丁规则和边缘说明，通常意味着问题不只是 Prompt 的问题，而是：

- 任务定义不清
- 类别设计有歧义
- 系统边界没划清
- 上下文输入不稳定

这时继续堆提示词，收益往往越来越低。

更有效的方式通常是回头改任务设计，而不是继续往 Prompt 里加 paragraph。

## 写在最后

到了 2025 年，Prompt 工程当然还重要，但重要的不是“提示词玄学”，而是约束设计。

如果你把 Prompt 当成系统边界的一部分，而不是一句自然语言指令，它的价值会非常稳定。真正好用的 Prompt，往往不是最花哨的，而是最清楚地告诉模型：

- 该做什么
- 不该做什么
- 输出必须长什么样


Vue 单文件组件写久了以后，真正拉开差距的是组织方式

真正的问题不在文件后缀

写在最后

ES6 常用特性回顾：真正改变前端开发体验的是哪些能力

做 AI 应用时，为什么上下文管理比模型选型更容易决定成败

Prompt 工程在 2025 年还有价值吗：真正有用的不是技巧，而是约束