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

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

- Cookie
- sessionStorage
- localStorage

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

## Cookie 的特点

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

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

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

## sessionStorage

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

它的典型特点是：

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

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

## localStorage

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

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

它适合：

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

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

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

可以从两个角度看：

### 1. 生命周期

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

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

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

这个区别非常关键。

## 写在最后

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

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


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


前端页面最终很大一部分价值，都来自交互。

而交互里最典型的一类，就是表单输入。

登录、注册、搜索、提交反馈、填写资料，这些几乎都离不开表单能力。所以虽然表单是基础内容，但它非常重要。

## 表单的核心作用

表单的本质是收集用户输入。

这看起来简单，但一旦进入真实业务，就会涉及：

- 文本输入
- 单选、多选
- 下拉选择
- 校验
- 提交

所以表单其实是用户和系统之间非常关键的一个桥梁。

## 常见表单元素

最常用的通常包括：

- `input`
- `textarea`
- `select`
- `button`

其中 `input` 又有多种类型，例如：

- `text`
- `password`
- `checkbox`
- `radio`

不同类型对应不同输入场景。

## label 很重要

很多人刚开始写表单时，会把重点只放在输入框上，但 `label` 同样重要。

它不仅让用户更容易理解字段含义，也让表单结构更完整。

## 表单提交不只是按钮点击

表单天然支持提交行为，这也是它和普通容器元素的重要区别之一。

理解这一点之后，你会更容易明白：

- 为什么按回车会触发表单提交
- 为什么有时要阻止默认提交行为

## 前端校验和表单体验

真实开发里，表单体验很大程度取决于：

- 提示是否清楚
- 错误信息是否及时
- 输入控件是否易用

所以表单不只是“能填进去”，而是要让用户明白自己该怎么填、哪里填错了。

## 写在最后

HTML 表单是前端交互能力里非常基础的一部分。它看起来简单，但几乎贯穿了所有和用户输入有关的功能。

只要把表单元素、标签、提交行为这些基础认知打稳，后面再学更复杂的表单逻辑时会轻松很多。


HTML 表单基础回顾：前端交互实际开发中就是从这里开始的


Vue 3 发布之后，大家讨论最多的点之一就是响应式实现变了。

对很多日常业务开发来说，最先感受到的并不是底层细节，而是一些以前容易别扭的地方开始顺了。

## 为什么大家会关心这一层

因为响应式不是 Vue 的一个外围能力，它几乎决定了你日常写组件时的基本体验。

数据怎么跟界面联动、对象新增字段时会不会更新、数组变化是否自然，这些都属于响应式系统的范围。

## 写在最后

Vue 3 响应式改动之所以值得关注，不是因为底层名词更新了，而是因为它会直接改变你写业务代码时的感觉。

很多框架变化看起来离业务很远，响应式这件事不是。它几乎就是日常开发体验本身。


Vue 3 响应式变化初看：Proxy 带来的不只是写法变化


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

比如：

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

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

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

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

实际并不是这样。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

## 写在最后

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

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


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


不少 React 项目发展到一定阶段，都会遇到一个问题：状态到底该放哪里。

最容易上手的答案通常是 Context。它不需要额外引库，接入成本低，语义也很直接，所以不少人会把登录信息、主题、权限、筛选条件、弹窗状态、列表缓存，甚至表单临时值都逐步放进去。

一开始看起来很顺，后面就开始变重。

## Context 真正适合什么

Context 更适合“跨层级共享，但变化频率不高”的信息，例如：

- 主题
- 语言
- 当前登录用户
- 权限配置

这些数据的特点是：

- 很多组件都要读
- 更新频率不算高
- 读比写更常见

如果一个状态既高频变化，又被很多组件订阅，那直接塞进 Context 往往不是最优解。

## 为什么一改就容易整片重渲染

Context 的根本问题不是“不能用”，而是更新粒度比较粗。

当 Provider 的 value 引用变化时，所有消费这个 Context 的组件都会参与更新判断。哪怕某个组件只用到了其中一个字段，也可能被连带影响。

例如：

```javascript
const AppContext = createContext(null);

function AppProvider({ children }) {
  const [theme, setTheme] = useState('light');
  const [keyword, setKeyword] = useState('');

  const value = {
    theme,
    setTheme,
    keyword,
    setKeyword
  };

  return <AppContext.Provider value={value}>{children}</AppContext.Provider>;
}
```

这时只要 `keyword` 变化，所有使用这个 Context 的消费者都会受到影响。哪怕某个组件只关心 `theme`，它也逃不掉。

## 最常见的误区

### 1. 把“共享”误解成“全都共享”

很多状态其实只在局部页面或一个模块内使用，却因为“以后可能别处也会用到”，提前被提升成全局状态。结果是维护成本上去了，收益却没有同步增加。

### 2. 一个 Context 放太多字段

把用户信息、UI 状态、搜索条件、弹窗开关全塞进一个对象里，是性能和可维护性双输的起点。

### 3. 频繁变化的数据也放进 Context

输入框内容、拖拽坐标、滚动位置、实时筛选条件，这类高频状态更适合局部管理，而不是广播给全树。

## 更稳的做法：按职责拆 Context

比起“一个大 Context 包天下”，更好的方式通常是按职责拆分。

例如：

- `AuthContext`
- `ThemeContext`
- `SettingsContext`

拆分的价值不只是性能，还有一个更关键的问题是边界更清楚。你会更容易判断某个状态到底该归谁管。

```javascript
const ThemeContext = createContext(null);
const AuthContext = createContext(null);
```

当主题变化时，不应该影响认证相关消费者；反过来也一样。

## 局部状态优先，真的不丢人

不少团队做 React 架构时，容易把“提升状态”当成一种成熟感。但从长期维护来看，局部状态优先往往更健康。

判断一个状态该不该全局共享，可以先问：

1. 这个状态真的被多个远距离组件共同依赖吗？
2. 它的生命周期是否跨页面或跨模块？
3. 它的变化是否会影响多个功能域？

如果三个问题都答不上来，那它大概率不该进 Context。

## 需要更细粒度订阅时怎么办

如果你遇到下面这些问题：

- 某一类状态变化特别频繁
- 组件订阅需求很细
- Context 拆完还是觉得重

那就说明你需要的可能已经不是 Context，而是更细粒度的状态管理方案，比如 selector、store、局部订阅模型等。

重点不是“必须换某个库”，而是要承认 Context 的能力边界。

## 一个简单的经验法则

如果某个状态是“应用配置”，优先考虑 Context。

如果某个状态是“交互过程”，优先考虑局部状态。

如果某个状态是“频繁变化、多人订阅、依赖粒度细”，优先考虑更专业的状态管理方式。

## 写在最后

到了 2025 年，Context 仍然很好用，但它从来都不是“全局状态默认解”。稳定的 React 架构，不是把状态尽可能集中，而是把状态放到最合适的层级。

Context 适合共享，不适合滥用。只要这个边界清楚，项目后面会轻松很多。


React Context 性能优化笔记：2025 年还该不该滥用全局状态


Next.js是一个用于React应用的强大框架，它提供了一系列开箱即用的功能，使得构建高性能、可扩展的web应用变得更加简单。本文将探讨Next.js的核心特性，以及为什么它正在成为开发React应用的首选框架。

## 什么是Next.js？

Next.js是一个基于React的开源JavaScript框架，由Vercel公司开发维护。它旨在简化React应用的开发过程，同时提供优秀的性能和开发体验。

## Next.js的核心特性

### 1. 服务器端渲染（SSR）

Next.js默认支持服务器端渲染，这意味着页面的初始内容是在服务器上生成的，然后发送到客户端。

```javascript
// pages/index.js
export default function Home({ data }) {
  return <div>Welcome to {data.name}</div>
}

export async function getServerSideProps() {
  const res = await fetch('https://api.example.com/data')
  const data = await res.json()
  return { props: { data } }
}
```

### 2. 静态站点生成（SSG）

Next.js还支持静态站点生成，允许在构建时预渲染页面，提高加载速度和SEO效果。

```javascript
// pages/posts/[id].js
export default function Post({ post }) {
  return <div>{post.title}</div>
}

export async function getStaticPaths() {
  const res = await fetch('https://api.example.com/posts')
  const posts = await res.json()
  const paths = posts.map((post) => ({
    params: { id: post.id.toString() },
  }))
  return { paths, fallback: false }
}

export async function getStaticProps({ params }) {
  const res = await fetch(`https://api.example.com/posts/${params.id}`)
  const post = await res.json()
  return { props: { post } }
}
```

### 3. 文件系统路由

Next.js使用文件系统作为路由基础，简化了路由配置过程。

```javascript
pages/
  index.js         // 对应 /
  about.js         // 对应 /about
  posts/
    [id].js        // 对应 /posts/:id
```

### 4. API路由

Next.js允许你直接在`pages/api`目录下创建API端点。

```javascript
// pages/api/hello.js
export default function handler(req, res) {
  res.status(200).json({ name: 'John Doe' })
}
```

### 5. 自动代码分割

Next.js会自动进行代码分割，只加载当前页面需要的JavaScript。

### 6. CSS支持

Next.js支持CSS Modules、Sass，以及CSS-in-JS解决方案如styled-components。

```javascript
// 使用CSS Modules
import styles from './Button.module.css'

export default function Button() {
  return <button className={styles.error}>Delete</button>
}
```

## Next.js的优势

1. **性能优化**：通过SSR和SSG，Next.js提供了出色的首次加载性能和SEO支持。

2. **开发体验**：自动代码分割、热模块替换等特性提升了开发效率。

3. **可扩展性**：从小型应用到大规模企业级项目，Next.js都能胜任。

4. **部署简便**：特别是在Vercel平台上，可以实现零配置部署。

## 实际应用场景

- **企业网站**：利用SSG功能构建高性能的公司官网。
- **电子商务平台**：结合SSR提供动态产品页面和优秀的SEO表现。
- **内容管理系统（CMS）**：使用动态路由和API路由功能构建灵活的CMS。
- **Web应用**：利用Next.js的全栈能力快速开发和部署复杂的Web应用。

## 结论

Next.js通过提供一系列强大的功能，极大地简化了React应用的开发过程。它解决了许多传统React应用面临的挑战，如服务器端渲染、路由配置等。无论是对于初学者还是经验丰富的开发者，Next.js都是一个值得学习和使用的框架。

随着Web开发的不断发展，Next.js正在成为构建现代化、高性能React应用的首选解决方案。通过掌握Next.js，你将能够更快、更高效地开发出优秀的Web应用。


HTML 表单基础回顾：前端交互实际开发中就是从这里开始的

表单的核心作用

常见表单元素

label 很重要

表单提交不只是按钮点击

前端校验和表单体验

写在最后

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

React Context 性能优化笔记：2025 年还该不该滥用全局状态

Next.js：React应用的未来