
我第一次觉得 `useEffectEvent` 真有必要，不是因为看了官方示例，而是因为我手里有一段 effect 已经快被我自己改烂了。

那是一个带实时消息的页面。页面进入时要建立连接，连接成功后要弹通知，通知文案和样式又会依赖当前主题和语言设置。这个功能最早很简单，后面边做边加，最后 effect 长成了一团。

最开始的版本只有连接逻辑：

```javascript
useEffect(() => {
  const connection = createConnection(roomId);
  connection.connect();
  return () => connection.disconnect();
}, [roomId]);
```

后来要加一个“连接成功提示”，于是 effect 里多了主题依赖；再后来国际化接进来，语言也进来了；再往后，页面切换静音状态时，回调里还要顺手读一遍用户设置。

代码还能跑，但问题越来越明显：只要主题切换、语言切换，连接就会跟着重建一次。功能上不是完全错，但体验和日志都开始变脏。开发时你会看到它反复 connect、disconnect，线上偶尔还会导致通知乱跳。

## 当时最难受的是：逻辑都“看起来有道理”

这类 effect 最麻烦的地方，不在于它明显报错，而在于每一项改动都能自圆其说。

主题确实在 effect 里用了，那依赖数组里放 `theme` 看上去没毛病。

语言也确实在回调里读了，那 `locale` 放进去似乎也合理。

可一旦这些值都放进去，effect 的同步边界就已经变了。原本它只该由 `roomId` 控制，现在任何跟通知相关的 UI 信息变化都会触发重连。

我后来才意识到，这种问题本质上不是依赖数组写错了，而是我把两类逻辑混在了一起：

- 一类是“这个 effect 到底什么时候应该重新同步”
- 另一类是“这个 effect 内部某个事件发生时，我希望读取到最新值”

这两件事不是一个层级，但以前我一直拿同一种写法在处理。

## 我一开始尝试过两个老办法，都不太舒服

第一个办法是继续把所有依赖都放齐，接受 effect 重跑。

这样 ESLint 最开心，代码也最“规矩”，但业务上不舒服。因为我不想让主题切换导致连接重建，这就是不符合语义。

第二个办法是把主题、语言这些值塞进 `useRef`。

这确实能绕开闭包旧值问题，也能避免 effect 重跑。可写到后面代码会越来越像在自己维护一个影子状态系统：

- 每次 render 同步 ref
- 回调里读 `ref.current`
- 还得提醒自己别漏字段

它不是不能用，但很难说优雅。尤其是多人协作时，别人看到 `ref.current` 往往得停一下，想想这段逻辑到底想规避什么。

## `useEffectEvent` 解决的就是这条边界

我后来把那段代码改成了这种结构：

```javascript
const onConnected = useEffectEvent(() => {
  showNotification('连接成功', theme);
});

useEffect(() => {
  const connection = createConnection(roomId);

  connection.on('connected', () => {
    onConnected();
  });

  connection.connect();
  return () => connection.disconnect();
}, [roomId]);
```

改完之后，最大的变化不是代码更短，而是语义终于对了。

`roomId` 仍然决定连接什么时候重建。

而 `theme`、`locale` 这种值，不再参与 effect 的同步边界，只在“连接成功这个事件真正发生时”读取最新值。

这一下把我之前一直拧巴的地方解开了。

## 它最适合解决的是“effect 里的事件”

我现在对 `useEffectEvent` 的理解很简单：它不是一个省依赖的捷径，而是用来表达“effect 里发生的事件”。

这个事件有几个典型特点：

- 不是用户点击按钮这种普通 UI 事件
- 是 effect 内部注册、触发的回调
- 回调里想读最新 props 或 state
- 但这些值不该反过来决定 effect 是否重跑

聊天室连接成功通知、定时器自动保存、原生事件监听回调，这些都属于这个范围。

## 一次定时器问题让我更确信它有用

后来我在另一个编辑页里也碰到过类似问题。

页面每隔几秒自动保存草稿。最早写法是把 `content` 放进依赖数组，于是每次输入都会重新建一遍定时器。功能上没错，但逻辑读起来很奇怪。

如果把依赖去掉，又会拿到旧值。

改成 `useEffectEvent` 之后，这段代码终于回到了它该有的样子：effect 只负责创建和销毁定时器，定时器触发时再读最新内容。这个分层一旦清楚，后面任何人接手都容易理解。

## 什么时候我不会用它

我现在也不会把 `useEffectEvent` 到处塞。

如果某个值真的会决定 effect 是否需要重新同步，那它就应该留在依赖数组里。这个边界不能偷懒。

比如：

- `roomId` 变了，连接就该重建
- `url` 变了，请求就该重新发
- `enabled` 变了，订阅就该开关

这些都属于 effect 的同步条件，不该用 `useEffectEvent` 偷过去。

所以我现在会先问自己一句话：

“这个值是影响 effect 是否要重跑，还是只是希望某个回调触发时读到最新值？”

前者进依赖，后者才考虑 `useEffectEvent`。

## 这类 API 真正让我有感的地方

以前写 React effect，我经常有一种感觉：逻辑明明都对，但总要在依赖数组、ref、eslint 规则之间来回妥协。

`useEffectEvent` 让我第一次觉得，React 是在正面承认这类问题确实存在，并给了一个更像“正经写法”的表达方式。

它不是为了炫新 API，而是把以前模模糊糊、只能靠经验处理的边界，正式写进了模型里。

## 写在最后

如果一个 effect 越写越乱，通常不是因为你不会写 Hook，而是它里面混进了不属于同一层的逻辑。

我现在看 `useEffectEvent`，最重要的价值不是“更高级”，而是它逼着你把 effect 里的同步条件和内部事件拆开。一旦这条边界拆清楚，代码会比以前稳很多，也更像人在维护，而不是在和依赖数组僵持。


React useEffectEvent 实战：我是怎么把一个越改越乱的 effect 拆开的


我第一次认真把乐观更新用进 React 项目，不是在点赞按钮这种玩具级例子里，而是在一个内部内容系统的评论区。

那个页面表面上不复杂：用户输入评论，点击发送，评论出现在列表里。需求也很普通，谁都觉得不难。真正把它做进业务之后，问题很快就出来了。

最开始的实现很直白。用户点击“发送”后，按钮进入 loading，等接口返回成功，再把新评论插进列表。逻辑一点都不花哨，但体验非常差。公司内网环境本来就不稳定，再加上评论接口还会顺手做审核、敏感词和通知，正常情况下一次请求经常要几百毫秒，偶尔还会上 1 秒。结果就是用户每次点完发送，页面都像卡了一下。

最烦的是，这种迟钝不是“性能慢”的那种大问题，它更像一种持续的小摩擦。用户会不自觉地点第二次，会怀疑刚刚有没有发成功，会盯着按钮看。你从埋点里也能看到，评论提交后的二次点击率很高，但接口明明没有真正失败。

## 一开始我用的是最常见的临时状态写法

我最早的处理方式其实很传统：

1. 本地先维护一份 `comments`
2. 再维护一份 `isSubmitting`
3. 提交时手动把一条临时评论插进去
4. 请求回来后用真实评论替换掉临时项
5. 如果失败，再把临时项删掉

这套方案不是不能用，问题在于它很快就会长出一堆边角逻辑。

比如：

- 临时评论的 `id` 用什么生成
- 用户连续发两条时，哪条先回来
- 如果接口失败，输入框里的文字要不要恢复
- 列表重新拉取时，临时项和真实项怎么合并

这些东西单看都不大，但它们会让“提交一条评论”这件事越来越像在修一套同步系统，而不是写一个交互。

那次改造到后面，我最大的感受不是“乐观更新可以让页面更快”，而是如果你继续手搓两套状态，迟早会把自己绕进去。

## 真正的问题不是快不快，而是状态到底该由谁来表达

我后来回头看，当时最别扭的点在于：我一边想让界面先表现得像成功了，一边又不想把真实状态提前写死。

这其实是两种状态：

- 用户当前应该看到什么
- 服务器最终确认了什么

以前我把这两层混在一起处理，所以写到后面只能不断补丁。React 的 `useOptimistic` 给我的帮助，不是“提供一个新 Hook”，而是把这两层状态硬拆开了。

你可以先明确地告诉 React：提交中的界面长什么样。然后等真实请求回来，再把真实状态落进去。这个分工一旦清楚，代码会安静很多。

## 我后来是怎么改的

改造之后，我把评论提交拆成两段：

第一段负责立即反馈。用户点发送的那一刻，先用 `useOptimistic` 往列表里加一条带 `pending` 标记的评论，这样界面立刻变化，输入框也能马上清空。

第二段负责异步收口。接口成功后，把服务端返回的真实评论写回去；失败的话，就把这条临时评论回滚掉，并把输入内容恢复出来。

核心写法和官方文档思路差不多，但我在业务里更在意的是三件事：

```javascript
const [optimisticComments, addOptimisticComment] = useOptimistic(
  comments,
  (currentComments, newComment) => [
    ...currentComments,
    { ...newComment, pending: true }
  ]
);

function handleSubmit(text) {
  const tempComment = {
    id: crypto.randomUUID(),
    text
  };

  startTransition(async () => {
    addOptimisticComment(tempComment);
    await saveComment(tempComment);
  });
}
```

第一，临时评论必须能被稳定识别。否则后面失败回滚、成功替换都会很难做。

第二，失败路径不能是“以后再说”。我一开始就是在这件事上吃亏，导致偶发失败时列表里会留下幽灵评论。

第三，乐观更新最好局部做，不要一上来改整个页面的共享状态。那次我只把评论列表这一段先改了，没有顺手去动评论数、消息中心、右侧推荐这些联动区域。事实证明这是对的，因为局部先跑通以后，边界会清楚很多。

## `startTransition` 在这里帮我的，不是“异步”，而是优先级

很多人第一次看到 `startTransition`，会下意识把它理解成异步包装器。实际开发里我更把它当成“让 React 知道这次更新不必抢最高优先级”。

像评论提交这种交互，用户最在意的是：

- 按钮点下去立刻有反馈
- 输入框别卡
- 列表看起来已经变了

至于后面那次真实状态写回，并不是最强实时的那种更新。`startTransition` 的好处就在这里，它不会把所有状态更新一股脑地压到最前面。页面整体的手感会更平顺，不是那种“逻辑都对，但总觉得哪里发沉”的状态。

## 不是所有交互都该乐观更新

那次改造之后，我有一段时间很上头，觉得很多操作都可以乐观一点。后来很快就收住了，因为有些地方用起来确实不合适。

我现在基本用这几个标准判断：

- 成功率高不高
- 失败后能不能自然回滚
- 即时反馈值不值那点复杂度

点赞、收藏、关注、评论追加，这些通常适合。

支付、库存扣减、权限切换、关键配置保存，这些我就会谨慎很多。因为一旦失败，用户看到的不是“界面闪了一下”，而是对系统信任直接下降。

## 这类改造最后给我的一个感受

我后来越来越觉得，前端很多交互问题表面上像是“等待太久”，其实根子在状态建模。

如果你的代码里只有“提交前”和“提交后”两种状态，那你只能让用户等。可真实交互里明明还有一种状态很重要，就是“用户已经做了动作，系统也应该先给反应，但后端还没最终确认”。

`useOptimistic` 的价值就在这里。它不是为了让页面看起来花哨一点，而是让这层状态终于有了正式写法。

## 写在最后

我现在看乐观更新，已经不太把它当作“体验优化技巧”了，更像是一种交互建模方式。

当你明确区分“用户现在应该看到什么”和“服务器最终确认了什么”之后，很多原来看起来只能靠补丁处理的逻辑，都会顺下来。React 这两个 API 好用的地方，不是新，而是它们终于把这件事讲清楚了。


React 中的乐观更新：我是在一次评论交互改造里真正把它用明白的


这半年里我连续碰到过两个 AI 自动化项目，表面上看都很适合做 Agent，最后做出来的路子却完全不同。也是在这两个项目里，我才真正把“Agent 和工作流的边界”想明白。

第一个项目是内部知识处理流程。输入是文档，输出是摘要、标签、结构化字段，再把结果入库。第二个项目是一个运维助手，目标是接收自然语言指令后去查资料、调用工具、生成处理建议。

最开始团队对这两个项目的直觉差不多：都上 Agent 吧，毕竟多步骤、会调用工具、看起来很智能。

后来回头看，第一个项目如果真按 Agent 做，八成会越做越乱；第二个项目如果只做死工作流，又会显得特别笨。这就是我现在越来越在意的判断点：不是任务里有没有模型，而是路径到底稳不稳。

## 第一个项目教会我的，是“很多流程根本不需要自主规划”

文档处理那个项目刚开始时，也有人提议让模型自动决定每一步怎么做。听上去很先进：先读文档，再判断要不要抽摘要、要不要分类、要不要纠错、最后决定怎么入库。

但我们真正把流程梳理完之后发现，这件事根本没那么开放。

它的真实链路其实很固定：

1. 读文档
2. 提取正文
3. 做字段清洗
4. 生成摘要和标签
5. 输出固定结构
6. 入库

这里面真正需要模型判断的，其实只有个别节点，比如分类和摘要；主流程完全是确定的。

我们后来没有做 Agent，而是把主干写成工作流，再在少数节点上接大模型。结果非常稳。日志清楚，失败能重跑，出了问题也知道卡在哪一步。

这次经历让我第一次明确地感觉到：多步骤不等于 Agent。一个任务就算有六七步，只要路径稳定，它本质上还是流程编排问题。

## 第二个项目让我看到，工作流也会有明显上限

运维助手那次就不一样了。

用户会问：

- “帮我看看这个服务为什么最近报警变多了”
- “对比一下昨天和今天的错误日志趋势”
- “如果我要排查支付回调失败，应该先看哪几个系统”

这种任务的特点是目标清楚，但路径不固定。不同问题，第一步就可能完全不同：

- 有的要先搜知识库
- 有的要先查监控
- 有的要先拉日志
- 有的还得根据前一步结果再决定下一步

我们最早也尝试过工作流化，结果非常别扭。因为你很难提前把所有路径都列出来。流程一旦写死，助手就会表现得像一个菜单系统：能做的事都在预设分支里，一旦用户问法稍微拐一点，就开始答非所问。

这时候 Agent 的价值才真正出来。不是因为它“更高级”，而是它确实更适合这种需要边走边判断的任务。

## 我现在判断 Agent 和工作流，基本看三件事

第一，看路径是不是稳定。

如果一个任务 80% 情况都走同样的步骤，那优先工作流。别为了“智能感”把稳定流程交给模型自由发挥。

第二，看失败成本高不高。

如果一步错了会影响订单、权限、资金、客户数据，那主干流程必须尽量写死。模型可以辅助判断，但不该掌握整个执行权。

第三，看任务是否要求探索未知信息。

如果模型需要先去搜、再比对、再决定下一步，甚至中途可能修正原计划，那才更像 Agent。

这三个问题我现在几乎每次都会问一遍，因为它们能很快帮我把“看起来都像 AI 自动化”的需求拆开。

## 很多团队会误把“多步工具调用”当成 Agent

这是我最近最常看到的一个偏差。

有些系统本质上只是：

1. 读输入
2. 调一个接口
3. 调另一个接口
4. 按模板输出结果

这当然是多步，但不等于 Agent。它没有动态规划，也没有真正的路径选择，只是流程比单步长了一点。

如果把这类流程也包装成 Agent，短期可能显得很先进，长期问题很多。因为一旦让模型自由控制原本可以确定的步骤，你就会开始面对一连串新问题：

- 工具参数为什么变了
- 为啥这次少走了一步
- 为什么昨天成功今天失败
- 失败后该从哪儿恢复

这些问题本来可以靠流程约束直接规避。

## Agent 真正难的地方，从来都不是“会不会想”，而是“出了事怎么兜”

这个认知也是我做第二个项目时被逼出来的。

在 Demo 环境里，Agent 往往看起来很聪明。它会拆任务，会总结，还会自己决定先调哪个工具。可一旦进入真实系统，你马上会碰到完全不同的问题：

- 工具返回半结构化垃圾怎么办
- 上一步失败后，状态存在谁那里
- 一个任务执行到一半中断，能不能恢复
- 模型选错工具时，系统能不能兜底

这些问题不是“提示词再写好一点”就能解决的，它们属于工程治理问题。

所以我现在看一个 Agent 系统，会特别关注这些东西：

- 工具是不是封得干净
- 每一步是否可观测
- 中间状态有没有地方落
- 失败后是否能人工接管

这些事情如果没做好，Agent 再能说，也只是一个容易失控的黑盒。

## 后来我越来越接受一种更务实的做法

很多项目其实不需要在“纯工作流”和“全自主 Agent”之间二选一。

更实用的方式通常是：

- 主干流程写死
- 把模型放在少数确实需要语义判断的位置
- 在开放型环节里再放开自主规划

比如文档项目就是工作流主导，分类和抽取节点交给模型。运维助手则是 Agent 主导，但工具权限、执行范围、输出格式仍然受系统约束。

这种做法没有那么“酷”，但很符合真实交付环境。它既不把模型压成死模板，也不把可控性一把丢掉。

## 写在最后

我现在对 Agent 和工作流的看法已经很简单了：稳定路径别装成智能，自由探索也别硬写成流程。

很多项目不是做不出 AI，而是选错了自动化层级。主干应该被写死的地方，就老老实实写死；真正需要模型判断和规划的地方，再给它空间。边界一旦分清，系统会比“全都交给模型”稳得多，也比“什么都手搓流程”灵活得多。


AI Agent 和工作流的边界：我是在两次自动化项目里把这个问题看清的


不少 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 年还该不该滥用全局状态


React 里最容易写、也最容易写乱的东西之一，就是表单。

刚开始做简单输入框时，`useState` 足够直接。但一旦表单里出现下面这些需求，复杂度会迅速上升：

- 动态字段
- 联动校验
- 草稿保存
- 分步提交
- 错误提示
- 异步校验

这时如果还坚持“一个字段一个 useState”，代码很快就会失控。

## 最先出问题的通常不是校验，而是状态结构

很多表单越来越难维护，并不是因为规则复杂，而是因为状态没有分层。

一个更清晰的做法通常是把表单拆成三类状态：

1. 表单值
2. 校验状态
3. 提交流程状态

例如：

```javascript
const [values, setValues] = useState({
  name: '',
  email: '',
  company: ''
});

const [errors, setErrors] = useState({});
const [isSubmitting, setIsSubmitting] = useState(false);
```

如果把这些状态混在一起，后面几乎必然出现“改一个字段，顺手影响整个提交流程”的耦合问题。

## 表单值适合集中，交互状态适合分开

`values` 可以集中管理，因为它们本质上属于一份数据快照。

但像下面这些状态，不建议都塞进一个大对象里：

- 当前是否提交中
- 哪个字段正在异步校验
- 是否显示确认弹窗
- 当前步骤是否可前进

这些属于流程或 UI 状态，和表单值不是一个层次。

## 复杂表单更适合 reducer

当字段很多、更新动作明确时，`useReducer` 往往比一堆 `setState` 更稳。

```javascript
function formReducer(state, action) {
  switch (action.type) {
    case 'update_field':
      return {
        ...state,
        values: {
          ...state.values,
          [action.name]: action.value
        }
      };
    case 'set_errors':
      return {
        ...state,
        errors: action.errors
      };
    case 'set_submitting':
      return {
        ...state,
        isSubmitting: action.value
      };
    default:
      return state;
  }
}
```

`reducer` 的价值不只是“统一写法”，而是把状态变化变成显式动作，后面调试和扩展都会更容易。

## 校验不要写成“哪里触发就在哪里拼”

表单校验最容易烂掉的方式，是在 `onChange`、`onBlur`、`onSubmit` 里各写一份条件分支。

更靠谱的方式是：

- 把校验逻辑提成单独函数
- 明确区分字段级校验和表单级校验
- 不同触发时机复用同一套规则

例如：

```javascript
function validate(values) {
  const errors = {};

  if (!values.name.trim()) {
    errors.name = '姓名不能为空';
  }

  if (!values.email.includes('@')) {
    errors.email = '邮箱格式不正确';
  }

  return errors;
}
```

这样至少能保证规则只有一个来源，而不是散落在多个事件里各写一份。

## 异步校验一定要考虑竞态

很多表单会在输入用户名、邮箱、邀请码时做异步校验。

这类场景最容易出现的问题是：

- 用户输入 A，发请求
- 很快又输入 B，再发请求
- A 的结果后回来，把 B 的结果覆盖了

所以异步校验至少要考虑：

- 请求取消
- 只处理最新一次响应
- 加上最小防抖

否则你看到的并不是“校验结果”，而是“返回顺序”。

## 提交流程不要只维护一个 loading

很多表单最后只有一个 `loading` 状态，这在简单场景没问题，但复杂一点就不够了。

例如提交过程里可能有：

1. 本地校验
2. 图片上传
3. 主表提交
4. 成功回跳

这些阶段都叫 loading，等于没有信息。

更实际的做法是用阶段状态来表达：

- `idle`
- `validating`
- `uploading`
- `submitting`
- `success`
- `error`

一旦流程出问题，你会更容易定位卡在哪一步。

## 什么时候该用表单库

如果你的表单有这些特征：

- 字段数量多
- 规则复杂
- 需要和 UI 组件库深度整合
- 多个页面都有类似模式

那引入表单库通常是合理的。

但核心依然不是“为了用库而用库”，而是你是否已经清楚：

- 状态怎么分层
- 校验怎么组织
- 提交流程怎么表达

如果这些都没想清楚，换什么库也只是在换一种混乱方式。

## 写在最后

复杂表单的难点从来不只是输入和提交，而是状态、规则和流程三者的组织方式。

在 React 里，表单写得稳不稳，关键不在于用了多少 Hook，而在于你有没有把“数据”“校验”“流程”分开建模。只要这一步做对，后面的代码会清爽很多。


React 表单状态管理经验总结：复杂表单不该一路 useState 写到底


每隔一段时间，就会有人说 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，往往不是最花哨的，而是最清楚地告诉模型：

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


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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

比如：

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

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

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

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

实际并不是这样。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

## 写在最后

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

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


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


AI 应用最容易被高估的阶段，就是 Demo 阶段。

因为 Demo 天然会挑选：

- 最能体现效果的输入
- 最干净的上下文
- 最理想的执行路径

这当然能说明“系统有潜力”，但说明不了“系统已经稳定可用”。

真正要落地，一个更现实的问题是：这个系统在反复运行、面对不同输入、进入边缘场景后，还能不能保持可接受质量。

## 为什么演示效果不等于真实效果

原因很简单，真实业务里的输入不会像 Demo 一样配合你。

真实用户会：

- 描述不完整
- 问题跳跃
- 混用口语和专业词
- 给出错误信息
- 连问多个目标

如果评估数据过于理想，最终得到的不是能力判断，而是乐观幻觉。

## 有意义的评估至少要看三件事

### 1. 准确性

系统答得对不对、分类准不准、提取结果是否符合事实。

### 2. 稳定性

同类输入下输出是否波动过大，是否经常忽好忽坏。

### 3. 可复现性

你是否能解释为什么这次成功、下次失败，以及失败集中在哪些场景。

如果只有准确率，没有稳定性和可复现性，那系统仍然很难真正用于业务。

## 建评估集时，不要只挑“漂亮样本”

评估集最好至少包含三类数据：

- 常规样本
- 边缘样本
- 对抗样本

常规样本保证你知道系统在主流程里的表现。

边缘样本保证你知道它在复杂输入下的下限。

对抗样本则能帮助你发现：

- 容易误判的词
- 容易被带偏的提示
- 容易失败的工具调用路径

如果只评估“漂亮样本”，最后上线时通常会被现实教育。

## 评估指标要贴近任务本身

不少团队会问：AI 应用到底该用什么统一指标？

其实大部分时候没有统一答案，因为任务不同，指标就不同。

例如：

- 分类任务看准确率、召回率、误判类型
- 提取任务看字段正确率、漏提率、格式合法率
- 问答任务看事实一致性、引用命中率、拒答合理性
- Agent 任务看任务完成率、路径长度、失败恢复率

真正关键的是：指标能不能反映业务风险。

## 评估一定要带失败分析

很多报表会给出一个总体分数，比如 82%、87%、91%。

这对趋势判断有用，但不够指导优化。

更关键的是把失败分出来看：

- 是检索错了
- 是上下文污染了
- 是 Prompt 边界不清
- 是工具参数传错了
- 还是模型本身就难以处理

只有把失败原因拆开，你才知道下一步该优化哪里。

## 人工评估仍然有价值

虽然大家都想自动化评估，但在很多任务上，人工评审仍然非常重要。

尤其是这些场景：

- 输出质量很主观
- 结果不只是对错，而是好坏程度
- 需要结合业务背景判断

自动评估适合规模化监控，人工评估适合建立判断标准。两者最好结合，而不是互相替代。

## 一个更实用的目标：持续评估，而不是一次评估

AI 应用不是“测完一次就结束”的系统。

因为它依赖的很多变量都会变：

- 模型版本
- Prompt
- 检索内容
- 工具输出
- 用户输入分布

所以真正稳的做法是持续评估：

- 新版本上线前回归
- 核心样本集定期复跑
- 线上失败样本持续回灌

只有这样，你才知道系统是在进步，还是只是“碰巧这周看起来不错”。

## 写在最后

AI 应用评估最怕的不是分数低，而是评估方式本身无法反映真实能力。

如果你只看演示效果，很容易高估系统；如果你开始看稳定性、失败分布和可复现性，才算真正进入工程阶段。能不能落地，实际开发中不取决于最好的那次表现，而取决于最差的时候系统还能不能被信任。


AI 应用怎么评估才有意义：不要只看演示效果，要看稳定性和可复现


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应用。


Next.js：React应用的未来


Next.js作为一个强大的React框架，提供了多种灵活的路由传参方式。本文将详细介绍这些方法，并探讨它们在不同场景下的应用。

## 基础传参方法

### 1. 动态路由

Next.js支持在文件名中使用方括号来创建动态路由。这是最常用的方法之一。

```javascript
// pages/posts/[id].js
import { useRouter } from 'next/router'

export default function Post() {
  const router = useRouter()
  const { id } = router.query

  return <p>Post: {id}</p>
}
```

访问 `/posts/1` 时，`id` 参数会被设置为 "1"。

### 2. 查询字符串

可以通过URL的查询字符串传递参数：

```javascript
// pages/about.js
import { useRouter } from 'next/router'

export default function About() {
  const router = useRouter()
  const { name } = router.query

  return <p>About: {name}</p>
}
```

访问 `/about?name=John` 时，`name` 参数会被设置为 "John"。

### 3. Link组件

使用 `Link` 组件时可以传递参数：

```jsx
import Link from 'next/link'

function Home() {
  return (
    <Link
      href={{
        pathname: '/about',
        query: { name: 'John' },
      }}
    >
      About John
    </Link>
  )
}
```

### 4. 编程式导航

使用 `router.push()` 或 `router.replace()` 进行编程式导航时也可以传递参数：

```javascript
import { useRouter } from 'next/router'

function HomePage() {
  const router = useRouter()

  return (
    <button onClick={() => router.push({
      pathname: '/about',
      query: { name: 'John' },
    })}>
      About John
    </button>
  )
}
```

## 高级传参场景

### 1. 嵌套动态路由

Next.js支持嵌套的动态路由：

```javascript
// pages/posts/[category]/[id].js
import { useRouter } from 'next/router'

export default function Post() {
  const router = useRouter()
  const { category, id } = router.query

  return <p>Post: {id} in {category}</p>
}
```

访问 `/posts/tech/123` 时，`category` 会被设置为 "tech"，`id` 会被设置为 "123"。

### 2. Catch-all 路由

使用 `...` 可以捕获所有后续的路径段：

```javascript
// pages/posts/[...slug].js
import { useRouter } from 'next/router'

export default function Post() {
  const router = useRouter()
  const { slug } = router.query

  return <p>Slug: {slug.join('/')}</p>
}
```

访问 `/posts/2023/01/01` 时，`slug` 将是一个数组 `['2023', '01', '01']`。

### 3. 国际化路由

对于多语言网站，Next.js提供了内置的国际化路由支持：

```javascript
// next.config.js
module.exports = {
  i18n: {
    locales: ['en', 'fr', 'de'],
    defaultLocale: 'en',
  },
}

// pages/blog/[slug].js
import { useRouter } from 'next/router'

export default function Blog() {
  const router = useRouter()
  const { locale, slug } = router.query

  return <p>Blog post {slug} in {locale}</p>
}
```

访问 `/fr/blog/hello-world` 时，`locale` 会被设置为 "fr"，`slug` 会被设置为 "hello-world"。

### 4. 复杂对象作为路由参数

有时需要传递复杂对象作为参数。可以使用 JSON 字符串和 `encodeURIComponent`：

```javascript
const complexObject = { key1: 'value1', key2: 'value2' }
const encodedObject = encodeURIComponent(JSON.stringify(complexObject))

router.push(`/page?data=${encodedObject}`)

// 在目标页面
const { data } = router.query
const decodedObject = JSON.parse(decodeURIComponent(data))
```

### 5. 动态API路由

Next.js的API路由也支持动态参数：

```javascript
// pages/api/users/[id].js
export default function handler(req, res) {
  const { id } = req.query
  res.status(200).json({ id, name: `User ${id}` })
}
```

## 结论

Next.js提供了丰富而灵活的路由传参方式，可以满足各种复杂的应用场景。从简单的动态路由到复杂的国际化路由，开发者可以根据具体需求选择最适合的方法。合理使用这些传参技术，可以构建出更加动态和交互性强的Web应用。

在实际开发中，要根据项目的具体需求和复杂度来选择合适的传参方法。同时，也要考虑到性能、SEO和用户体验等因素，以确保应用的整体质量。


Next.js路由传参全攻略


JavaScript的异步编程能力是其最强大的特性之一。本文将探讨JavaScript中处理异步操作的各种方法，从传统的回调函数到现代的async/await语法。

## 为什么需要异步编程？

在JavaScript中，异步编程主要用于处理可能需要一些时间才能完成的操作，如网络请求、文件读写或大量计算。异步操作允许程序继续执行其他任务，而不是一直等待某个操作完成。

## 回调函数

回调函数是处理异步操作最传统的方式。

```javascript
function fetchData(callback) {
  setTimeout(() => {
    callback('Data fetched');
  }, 2000);
}

fetchData((result) => {
  console.log(result); // 2秒后输出: Data fetched
});
console.log('Fetching data...'); // 立即输出
```

然而，当需要处理多个连续的异步操作时，回调可能会导致所谓的"回调地狱"。

## Promise

Promise提供了一种更结构化的方式来处理异步操作。

```javascript
function fetchData() {
  return new Promise((resolve, reject) => {
    setTimeout(() => {
      resolve('Data fetched');
    }, 2000);
  });
}

fetchData()
  .then(result => console.log(result))
  .catch(error => console.error(error));

console.log('Fetching data...');
```

Promise可以链式调用，避免了回调地狱问题：

```javascript
fetchUserData()
  .then(user => fetchUserPosts(user.id))
  .then(posts => fetchPostComments(posts[0].id))
  .then(comments => console.log(comments))
  .catch(error => console.error(error));
```

## Async/Await

Async/Await是基于Promise的语法糖，使异步代码看起来更像同步代码。

```javascript
async function fetchDataAndProcess() {
  try {
    const user = await fetchUserData();
    const posts = await fetchUserPosts(user.id);
    const comments = await fetchPostComments(posts[0].id);
    console.log(comments);
  } catch (error) {
    console.error(error);
  }
}

fetchDataAndProcess();
```

## 实际应用：并行请求

使用`Promise.all()`可以并行处理多个异步操作：

```javascript
async function fetchMultipleData() {
  try {
    const [users, posts, comments] = await Promise.all([
      fetchUsers(),
      fetchPosts(),
      fetchComments()
    ]);
    console.log({ users, posts, comments });
  } catch (error) {
    console.error('One of the requests failed', error);
  }
}
```

## 错误处理

在异步编程中，错误处理尤为重要。使用try/catch块或Promise的catch方法可以捕获和处理错误。

```javascript
async function fetchData() {
  try {
    const response = await fetch('https://api.example.com/data');
    if (!response.ok) {
      throw new Error('Network response was not ok');
    }
    const data = await response.json();
    return data;
  } catch (error) {
    console.error('There was a problem with the fetch operation:', error);
  }
}
```

## 结论

异步编程是JavaScript中的一个核心概念，掌握它对于编写高效、响应迅速的应用程序至关重要。从简单的回调函数到强大的async/await语法，JavaScript提供了多种处理异步操作的方法。选择合适的方法取决于具体的使用场景和个人偏好。

随着你对异步编程的深入理解，你将能够编写更加复杂和高效的JavaScript应用。继续练习和探索，你会发现异步编程在解决实际问题时的强大力量。


掌握JavaScript异步编程


前端项目里经常会强调组件化。

按钮做成组件，弹窗做成组件，表单项做成组件，最后看起来页面被拆得很细，代码也“似乎”更复用了。

但实际开发几年后，不少团队都会发现一个尴尬的问题：组件确实越来越多，可真正好用、敢复用、改起来不痛苦的组件却没有同步增加。

说到底，组件化不等于组件设计。

## 组件“能用”不代表“可维护”

很多组件第一次写出来时都很好用，因为它们只服务一个页面、一个场景、一个需求。

问题往往出在第二次、第三次复用时。

这时常见情况是：

- 新场景需要一个额外参数
- 旧交互要兼容新的样式
- 一个组件同时承担多个职责
- props 越加越多

组件没有坏，但它开始变重。

## 最常见的误区：为了复用而过度抽象

前端开发里一个很常见的问题是，过早抽象。

例如一个项目刚做了两个列表页，就急着提炼一个“超级列表组件”，希望分页、筛选、空态、加载态、表头、操作栏全部统一。

看起来很先进，实际上很容易把组件做成下面这种形态：

```javascript
<DataList
  columns={columns}
  showFilter={true}
  filterSlot={...}
  loading={loading}
  emptyText="暂无数据"
  showToolbar={true}
  toolbarActions={...}
  pagination={pagination}
  rowActions={...}
  customHeader={...}
/>
```

参数越来越多，说到底是在用 props 模拟不同页面。这不是复用，而是在制造另一个配置系统。

## 好组件通常只解决一个明确问题

稳定的组件往往有一个共同特点：边界清楚。

例如：

- Button 只负责按钮语义和样式
- Modal 只负责弹层显示与关闭
- Table 只负责表格展示，不负责业务筛选逻辑

组件边界越清楚，后面就越容易判断：

- 这个需求该不该进组件
- 这个参数是不是越界了
- 这段逻辑应该放在外层还是内层

## 展示组件和业务组件最好分开

很多组件难复用，是因为它既负责 UI，又负责业务。

例如一个“用户列表组件”里同时做了：

- 请求接口
- 数据转换
- 空状态展示
- 表格渲染
- 点击跳转详情

这种组件在第一个页面里很高效，但一旦要给第二个页面复用，就会发现绑定得太死。

更稳的做法通常是把它拆成：

- 业务容器组件
- 纯展示组件

这样后者更容易复用，前者更容易调整。

## props 太多，通常说明设计出了问题

一个组件的 props 增长到一定程度后，维护成本会明显上升。

因为这意味着：

- 使用者需要记住更多规则
- 参数组合变复杂
- 组件内部状态分支增多

这时比起继续加参数，更值得做的是回头判断：

1. 组件职责是不是混了
2. 是否应该拆成两个组件
3. 是否应该把部分逻辑交给插槽或 children

## 组合往往比继承和配置更稳

前端组件里，最稳的复用方式通常不是一个万能组件，而是小组件组合。

例如一个卡片组件可以拆成：

- `Card`
- `CardHeader`
- `CardContent`
- `CardFooter`

这样每一部分都更明确，也更容易适配不同页面，而不是所有变化都靠布尔参数来开关。

## 样式统一要靠规范，不要只靠组件兜底

很多人希望通过组件库统一所有风格，这方向没错，但不能把所有规范都压在组件本身上。

如果团队没有基础设计规范，例如：

- 间距体系
- 字号层级
- 颜色语义
- 交互反馈规则

那组件只会变成“风格打补丁”的地方。

## 一个简单的判断标准

如果你在给组件加某个功能时，需要写一句“为了兼容另一个页面”，那就应该警觉了。

这通常意味着组件开始承担不属于自己的变化。

好组件不是永远不变，而是变化仍然在边界内。

## 写在最后

组件设计真正难的地方，不是怎么把代码拆小，而是怎么把职责拆对。

能复用只是起点，真好用的组件还要满足：

- 边界明确
- 参数克制
- 组合自然
- 不被业务逻辑绑死

只有这样，组件库才会越用越轻，而不是越积越重。


前端组件设计实践：从能复用到真好用，中间差了什么


前端项目里，CSS 经常是最容易被低估、也最容易失控的一层。

功能开发阶段，大家通常更关注接口、状态、交互、性能；样式经常被视为“最后补一下”。结果项目做久了以后，最让人不敢动的反而是样式文件。

CSS 在项目里经常 问题表面看起来像“技术选型不对”，其实更常见的原因是边界不清。

## 样式为什么这么容易变脏

因为 CSS 默认就是全局生效、相互影响的。

这意味着只要你没有主动管理边界，就很容易出现：

- 修改一个类名影响多个页面
- 提高优先级去覆盖旧规则
- 新样式不断叠加补丁
- 组件样式和页面布局样式混在一起

写的时候都合理，叠久了就开始变乱。

## 最常见的反模式：为了解决一个问题，再加一层覆盖

项目里的 CSS 最终常常会演化成这样：

```css
.card-title {
  color: #333;
}

.page-a .card-title {
  color: #111;
}

.dialog .page-a .card-title {
  color: #000;
}
```

每一次覆盖都在解决眼前的问题，但长期看，其实是在提高整套样式系统的耦合度。

## 样式的职责要分层

一个更稳定的方式，是把样式按职责拆开，而不是全部混在一起。

常见可以分为：

- 基础样式
- 组件样式
- 页面布局样式
- 状态样式

基础样式负责：

- 重置
- 字体
- 颜色变量
- 间距变量

组件样式负责组件本身的外观。

页面样式负责页面结构和布局，不应该直接侵入组件内部细节。

## 命名不是形式主义

很多人觉得 CSS 命名规范只是团队洁癖，其实不是。

命名说到底是在表达边界。

比如：

- `.button`
- `.user-card`
- `.article-list__item`

这些名字会直接影响后来的人如何理解和使用这个样式。

如果命名过于模糊，例如：

- `.box`
- `.item`
- `.left`
- `.active`

那么后续维护者几乎只能靠猜。

## 不要让页面直接修改组件内部

一个很常见的问题是，页面层样式直接写到组件内部类名上。

例如某个页面为了调整卡片标题颜色，直接覆盖了组件里的 `.card-title`。这样虽然快，但组件边界已经被打破。

更稳的做法是：

- 通过 props 或变体控制样式
- 通过外层 class 控制布局
- 必要时提供明确扩展点

而不是让页面随便改组件肚子里的结构。

## 工具能帮忙，但不能代替设计

无论你用的是：

- CSS Modules
- Sass
- Tailwind CSS
- styled-components

它们都只能帮你管理样式，不会自动帮你设计边界。

如果结构本身就是乱的，换工具并不会根治问题。

稳定的样式系统，核心还是：

- 样式归谁管
- 哪一层能改哪一层
- 哪些是通用规范
- 哪些是局部特例

## 变量体系比复制颜色更重要

CSS 在项目里经常 维护难，不是规则复杂，而是设计令牌缺失。

例如颜色、边距、字号、圆角全部写死，后面你一旦想统一调整视觉风格，就会发现全项目到处散落着重复值。

比起不停复制 `#333`、`16px`、`8px`，更应该做的是先建立变量。

## 写在最后

CSS 可维护性的关键，不在于选了多高级的方案，而在于有没有把样式边界设计清楚。

只要职责明确、命名清晰、组件和页面各守边界，样式就会越来越稳；反过来，如果一切都靠覆盖和补丁推进，再现代的技术栈也救不了后期失控。


CSS 可维护性实践：样式失控通常不是技术问题，而是边界问题


CSS Grid 布局是一个强大且灵活的布局工具，可以帮助你轻松实现复杂的网页设计。与传统的布局方法（如 `float`、`flexbox`）相比，CSS Grid 具有更多的控制能力，特别是在二维布局（行和列）中。本文将深入探讨 CSS Grid 的基本概念、网格区域、响应式设计以及一些高级布局技巧。

## 基本概念

CSS Grid 布局的核心在于通过定义行（rows）和列（columns）将元素放入网格中。要使用 Grid 布局，首先需要在容器上设置 `display: grid`，然后使用 `grid-template-columns` 和 `grid-template-rows` 来定义网格的结构。

### 创建简单的网格

```css
.container {
  display: grid;
  grid-template-columns: repeat(3, 1fr);
  grid-gap: 20px;
}
```

上面的代码创建了一个三列的等宽网格，每列之间有 20px 的间距。`repeat(3, 1fr)` 是一个简写，表示创建 3 个等宽的列，每列的宽度都是 `1fr`，即 1 份剩余空间。

### 控制行的高度

除了列，你还可以通过 `grid-template-rows` 来定义行的高度：

```css
.container {
  display: grid;
  grid-template-columns: repeat(3, 1fr);
  grid-template-rows: 100px 200px auto;
  grid-gap: 20px;
}
```

这段代码创建了三行，第一行高 100px，第二行高 200px，第三行根据内容自动调整高度。

## 网格项的对齐

你可以使用 `justify-items` 和 `align-items` 属性来控制网格项的对齐方式：

- `justify-items` 控制水平对齐。
- `align-items` 控制垂直对齐。

```css
.container {
  display: grid;
  grid-template-columns: repeat(3, 1fr);
  justify-items: center;
  align-items: center;
}
```

这段代码会将网格中的每个元素水平和垂直居中对齐。

## 网格区域

通过 `grid-template-areas`，你可以为每个网格区域命名，方便直观地控制布局。以下是一个典型的页面布局例子：

```css
.container {
  display: grid;
  grid-template-areas: 
    "header header header"
    "sidebar main main"
    "footer footer footer";
  grid-gap: 10px;
}

.header { grid-area: header; }
.sidebar { grid-area: sidebar; }
.main { grid-area: main; }
.footer { grid-area: footer; }
```

在 HTML 中：

```html
<div class="container">
  <div class="header">Header</div>
  <div class="sidebar">Sidebar</div>
  <div class="main">Main Content</div>
  <div class="footer">Footer</div>
</div>
```

这种方法直观明了，让你能够轻松定义复杂的布局。

## 跨列与跨行

CSS Grid 允许元素跨越多行或多列，可以使用 `grid-column` 和 `grid-row` 来实现。

```css
.item1 {
  grid-column: 1 / 3; /* 跨越第1和第2列 */
  grid-row: 1 / 2; /* 跨越第1行 */
}
```

这段代码会让 `.item1` 横跨两列，垂直跨越一行。

## 自动布局与自适应

CSS Grid 提供了强大的自动布局能力。你可以通过 `auto-fill` 和 `auto-fit` 实现网格项的自动填充与调整。

### `auto-fill` 实现自动填充

`auto-fill` 会尽可能多地创建列，即使网格中没有足够的内容去填充这些列：

```css
.container {
  display: grid;
  grid-template-columns: repeat(auto-fill, minmax(100px, 1fr));
  grid-gap: 10px;
}
```

### `auto-fit` 实现自适应布局

与 `auto-fill` 不同，`auto-fit` 会将多余的空间重新分配给已有的网格项，使它们能够根据容器宽度调整大小。

```css
.container {
  display: grid;
  grid-template-columns: repeat(auto-fit, minmax(100px, 1fr));
  grid-gap: 10px;
}
```

## 响应式设计

CSS Grid 在处理响应式设计时非常灵活。通过媒体查询，你可以轻松地调整布局。

### 使用媒体查询调整布局

例如，当屏幕宽度小于 600px 时，将布局从三列变为单列：

```css
@media (max-width: 600px) {
  .container {
    grid-template-columns: 1fr;
    grid-template-areas: 
      "header"
      "main"
      "sidebar"
      "footer";
  }
}
```

这种设计使得布局能够根据屏幕大小进行调整，从而提供更好的用户体验。

### 嵌套网格

CSS Grid 还支持嵌套网格布局，即在网格项中再使用 `display: grid`。这对于更复杂的布局非常有用：

```css
.container {
  display: grid;
  grid-template-columns: repeat(2, 1fr);
  grid-gap: 20px;
}

.inner-container {
  display: grid;
  grid-template-columns: repeat(3, 1fr);
}
```

通过嵌套网格，可以创建更复杂的网页结构，同时保持代码的可维护性。

## 使用 `grid-auto-flow` 控制布局顺序

CSS Grid 的默认布局顺序是从左到右、从上到下。但是，通过 `grid-auto-flow` 属性，你可以改变这一行为：

- `row`（默认值）：从上到下布局。
- `column`：从左到右布局。

```css
.container {
  display: grid;
  grid-auto-flow: column; /* 先布局列，再布局行 */
  grid-template-rows: repeat(3, 100px);
  grid-template-columns: repeat(2, 1fr);
}
```

这种灵活的布局控制可以应对特殊的页面设计需求。

## 网格与 Flexbox 的结合

虽然 CSS Grid 非常适合处理二维布局（行和列），但在某些场景下，你可以结合 Flexbox 使用。例如，网格布局用于整体的页面布局，Flexbox 用于细节布局或单行排列元素。

```css
.container {
  display: grid;
  grid-template-columns: 1fr 2fr;
  grid-gap: 20px;
}

.flex-item {
  display: flex;
  justify-content: space-between;
}
```

这种结合使用可以让你在保持布局灵活性的同时，简化某些特定场景下的布局控制。

---

## 写在最后

通过掌握 CSS Grid，你可以更加自由地设计复杂的网页布局。它不仅能让你轻松创建二维布局，还能在响应式设计中表现出色。此外，结合自动布局、网格区域、跨列跨行等功能，CSS Grid 为现代网页设计提供了强大的工具。


深入理解 CSS Grid 布局


React Hooks 是 React 16.8 中引入的新特性，它让你不用编写 class 就能使用状态和其他 React 特性。本文将介绍最常用的几个 Hooks。

## useState

`useState` 是最基本的 Hook，它让你在函数组件中添加状态。

```javascript
import React, { useState } from 'react';

function Example() {
  const [count, setCount] = useState(0);

  return (
    <div>
      <p>You clicked {count} times</p>
      <button onClick={() => setCount(count + 1)}>
        Click me
      </button>
    </div>
  );
}
```

## useEffect

`useEffect` 让你在函数组件中执行副作用操作。

```javascript
import React, { useState, useEffect } from 'react';

function Example() {
  const [count, setCount] = useState(0);

  useEffect(() => {
    document.title = `You clicked ${count} times`;
  });

  return (
    <div>
      <p>You clicked {count} times</p>
      <button onClick={() => setCount(count + 1)}>
        Click me
      </button>
    </div>
  );
}
```

使用 Hooks 可以让你的代码更加简洁和易于理解。继续探索其他 Hooks，如 `useContext`、`useReducer` 等，以充分利用 React 的强大功能。

React Hooks 入门指南


提到前端打包优化，很多人的第一反应是：

- 开 gzip
- 开 brotli
- 做压缩
- 分包

这些都重要，但它们更多是结果优化，而不是根因优化。

项目包体积越来越大，并不是因为压缩没做好，而是因为依赖结构、代码组织和资源策略本身就不够克制。

## 先弄清楚体积到底是怎么长起来的

一个前端包变大，常见来源通常有：

- 引入了过大的第三方库
- 首屏加载了本不该首屏加载的代码
- 公共依赖拆分不合理
- 图片、图标、字体资源过重
- 工具函数或组件重复打进多个 chunk

如果不先定位来源，只盯着构建配置调参数，优化通常很快进入瓶颈。

## 不要把“功能能跑”当成依赖引入标准

很多包体积问题，都是从一行 import 开始的。

比如为了一个简单功能，引入一个很重的库；或者只需要某个小工具函数，却把整个工具库一起打进来。

这类问题最常见，也最容易被忽视，因为功能层面完全没问题。

但从长期看，依赖使用要有一个基本原则：

引入的不是“功能”，而是“长期成本”。

## 路由级拆分是最基本的一步

如果一个页面用户根本没访问，理论上它相关的代码就不应该在首屏里出现。

这也是代码分割最直接的价值。

对于多页面或后台系统来说，路由级拆分通常是最先该做的事情。它并不是锦上添花，而是把不必要的首屏负担拿掉。

## 组件级懒加载也要谨慎

有些团队在发现包大之后，会开始把很多组件都做成懒加载。

这不是不行，但要分场景。

如果组件本身很轻、用户几乎一定会看到，那为了“拆得更碎”而懒加载，收益未必大，反而会增加请求碎片和复杂度。

更适合懒加载的通常是：

- 富文本编辑器
- 图表模块
- 大型表格
- 低频弹窗
- 管理后台高级筛选面板

也就是说，真正重、真正低频的模块优先拆。

## 图片和图标常常是被低估的体积来源

不少人会盯着 JS 包，却忽略了静态资源。

实际项目里下面这些都很常见：

- 首页大图未压缩
- 多个页面重复加载大图资源
- 只需要几个图标，却引入整套图标包
- 字体文件过大

这些问题加起来，用户感知可能比 JS 包还明显。

## 公共代码不是越集中越好

做公共 chunk 拆分时，一个常见误区是：只要公共就全抽出来。

问题在于，如果一个公共 chunk 非常大，而其中大部分内容其实只服务少数页面，那它反而会成为新的负担。

所以公共代码拆分不是追求“集中”，而是追求“合理复用”。

## 分析工具一定要用

如果一个项目已经明显变重，最不应该做的事情就是靠猜优化。

这时最有效的办法通常是：

- 看 bundle 分析图
- 看每个 chunk 的组成
- 找出最大的第三方依赖
- 找出重复出现的模块

很多优化方向只要一可视化，就会非常明显。

## 真正长期有效的优化，往往是结构优化

例如：

- 避免滥引第三方库
- 限制公共模块膨胀
- 拆分高成本页面
- 减少重复资源
- 让低频功能延后加载

这些事情比单纯调构建参数更费脑子，但通常也更有长期价值。

## 写在最后

打包优化不是一场“把构建工具调到最极致”的比赛，而是一次对项目结构的体检。

压缩、分包、缓存当然重要，但真正决定包体积的，通常还是代码和依赖本身的组织方式。只要结构合理，很多优化会自然发生；如果结构混乱，再多构建技巧也只是延后问题爆发。


前端打包优化经验：包体积不是只靠压缩就能降下来的


前端性能问题最让人头疼的地方，不只是慢，而是不知道到底哪里慢。

页面卡顿的时候，团队里常见的第一反应通常是：

- 是不是框架太重
- 是不是组件太多
- 是不是状态管理有问题

这些方向当然可能有关，但如果一上来就把问题归因给“大框架”或“大项目”，通常并不能真正解决问题。

## 先区分是哪一种慢

性能问题不是只有一种。

常见至少有四类：

- 首屏加载慢
- 页面切换慢
- 滚动卡顿
- 输入、点击反馈慢

这四类问题对应的排查方向可能完全不同。

如果一开始不分类，只说“页面有点卡”，后面优化就很容易到处试错。

## 首屏慢先看资源和请求

如果用户第一次打开页面就慢，优先看：

- JS 包体积
- 图片资源大小
- 接口耗时
- 阻塞渲染的资源

这类问题实际开发中和框架无关，而是资源策略不合理。

例如：

- 首页一次加载太多模块
- 首屏请求串行
- 大图没有做压缩
- 字体加载阻塞首屏文本渲染

## 交互卡顿先看渲染链路

如果是点击按钮、切换筛选、输入文本时卡，优先排查：

- 是否有大量不必要的重渲染
- 是否在主线程做了重计算
- 是否列表过大但没做虚拟化
- 是否有动画或布局抖动

这类问题比起网络，更常发生在渲染阶段。

## 不要把“重渲染”当成唯一答案

很多性能文章喜欢把问题都归结为重渲染，但现实中不一定。

页面卡可能来自：

- JS 计算太重
- DOM 数量太多
- 样式重排频繁
- 动画掉帧
- 第三方脚本抢主线程

所以排查时不能只盯着组件 render 次数。

## 列表问题特别容易放大性能缺陷

列表是最常见的性能放大器。

一个页面在数据量少时运行正常，数据量一大就明显变卡，这通常说明：

- 每项渲染成本高
- 状态更新影响整表
- 没做分页或虚拟滚动
- 键值不稳定导致节点频繁重建

列表优化的关键不是“让每一项更聪明”，而是减少不必要的整体更新。

## 排查时尽量用证据，不要靠感觉

性能问题最忌讳“我觉得是这里慢”。

更有效的方式是：

- 看 Performance 面板
- 看 Network 请求瀑布
- 看哪些任务阻塞了主线程
- 看长任务出现在哪里

实际开发中，真正耗时的地方和直觉并不一致。

## 第三方代码也要纳入排查

真实项目里，性能问题不全是自己代码导致的。

例如：

- 埋点 SDK
- 在线客服
- 可视化监控
- 广告脚本
- 富文本编辑器

这些东西一旦在不合适的时机执行，也会明显拖慢页面。

所以排查性能时，不要只看业务代码。

## 一个实用顺序

页面卡顿时，比较实用的排查顺序通常是：

1. 先明确是哪一种慢
2. 再看网络还是渲染主导
3. 找出最重的资源、请求或任务
4. 再决定是拆包、减渲染、改结构，还是延后加载

这个顺序的好处是，能避免一开始就陷入“我是不是该重构整个前端架构”的过度反应。

## 写在最后

前端性能排查最重要的不是技巧，而是顺序感。

只要你先把问题分类，再用工具找证据，很多看起来复杂的性能问题都会逐渐变清楚。页面卡顿并不等于框架有罪，更常见的情况是资源、渲染和交互链路里某个环节在被放大。


前端性能排查思路：页面卡顿时，不要一上来就怀疑框架


不少团队都做代码评审，但做着做着会进入一个低效状态。

评审内容常常集中在：

- 分号要不要
- 命名够不够优雅
- 这一行能不能再简洁一点

这些问题不是完全没价值，但如果评审长期停留在这个层面，更重要的风险往往会被漏掉。

## 代码评审的目标不是“挑毛病”

更合理的理解应该是：

代码评审是在功能上线前，尽可能早地发现后续维护成本和行为风险。

也就是说，评审不只是看“能不能跑”，更要看：

- 改动边界是否清楚
- 逻辑是否容易出错
- 后面的人能不能接手
- 有没有引入新的复杂度

## 前端评审里更值得关注什么

### 1. 状态流转是否清晰

前端不少 bug，不是出在渲染，而是出在状态流转混乱。

例如：

- 一个状态被多个地方同时改
- 本地状态和服务端状态混在一起
- 提交流程和展示状态耦合

这类问题如果在评审阶段不看，后面会很难查。

### 2. 组件边界是否合理

一个组件是不是承担了太多职责，是评审里非常值得看的点。

如果一个组件同时负责：

- 请求接口
- 数据转换
- 展示渲染
- 弹窗控制
- 路由跳转

那即使当前能跑，后面也很容易变成维护热点。

### 3. 异常路径有没有考虑

很多代码在 happy path 下没有问题，但一旦接口失败、字段为空、数据延迟返回，就容易暴露问题。

评审时可以多问一句：

如果这里失败，会发生什么？

这句话比看十个命名细节更有价值。

## 不要把格式工具负责的事情留给人做

如果团队还在评审里花很多时间讨论：

- 缩进
- 引号
- 分号
- 单行还是多行

那说明很多事情还没有交给工具。

能自动化的风格问题，尽量自动化；评审时间应该用在更难自动发现的风险上。

## 评审评论要具体，不要抽象

“这里感觉不太好”“建议优化一下”这类评论，通常帮助不大。

更有效的评论方式是直接指出：

- 风险在哪里
- 为什么是风险
- 可能导致什么后果

例如：

“这里把接口状态和弹窗状态放在同一个对象里，后面如果弹窗有异步关闭逻辑，可能会让提交状态被意外覆盖。”

这种评论才真正能推动改进。

## 好评审也要控制范围

评审不是架构大会。

如果当前 PR 只是修一个 bug，而评审开始讨论整个项目状态管理方案，那很容易偏离主题。

一个比较稳的原则是：

- 优先看这次改动直接引入的风险
- 再看和当前改动强相关的结构问题
- 不相关的长期优化可以另开 issue

这样评审更聚焦，也更容易形成闭环。

## 写在最后

前端代码评审更有价值的地方，不在于把代码改得像教材，而在于提前暴露维护风险。

如果评审能多关注边界、状态、异常路径和长期复杂度，团队的代码质量通常会比单纯追求“写法漂亮”更稳定。真正好的评审，不是挑出最多问题，而是尽早发现最值得处理的问题。


前端代码评审怎么做才有效：不是挑语法，而是提前发现维护风险


前端开发做久了以后，性能问题、样式问题、交互问题，最后都会回到一个基础问题：浏览器到底是怎么把页面画出来的？

如果对这个过程完全没有概念，很多优化只能停留在“知道有这个技巧”，但不知道为什么有效。

## 从 HTML 到页面展示，中间发生了什么

浏览器拿到页面内容后，并不是一下子就把整个页面显示出来。

它通常会经历几个关键步骤：

1. 解析 HTML，构建 DOM
2. 解析 CSS，构建 CSSOM
3. 合并形成渲染树
4. 计算布局
5. 绘制页面

这几个步骤看起来抽象，但它们直接影响到前端开发中的很多实际问题。

## 为什么 CSS 会影响渲染

浏览器在构建渲染树之前，需要知道每个节点最终该长什么样。

也就是说，HTML 不够，CSS 也得准备好。

所以当样式资源还没准备完时，某些渲染工作就不能完全继续。这也是阻塞渲染的 CSS 文件会影响首屏展示的原因。

## 布局阶段在做什么

布局的核心，就是确定每个元素在页面上的位置和尺寸。

例如：

- 它有多宽
- 它有多高
- 它在父元素中的位置
- 它是否换行

一旦页面结构复杂、元素多、布局关系密集，这一步的成本就会上升。

## 什么是重排

当某些改动会影响布局时，浏览器就需要重新计算相关元素的位置和尺寸，这个过程通常被称为重排。

例如修改：

- 宽高
- 边距
- 定位
- 字体大小

这些都可能触发布局重新计算。

如果页面频繁发生这种变化，性能就容易受到影响。

## 什么是重绘

如果改动不影响布局，但影响元素外观，例如：

- 颜色
- 背景
- 阴影

浏览器可能只需要重新绘制，而不必重新计算布局。

重绘通常比重排轻，但如果发生得太频繁，同样会带来性能负担。

## 为什么频繁操作 DOM 容易卡

因为每次修改 DOM，都有可能影响后续渲染流程。

如果代码里不断读取布局信息、又不断改样式，就容易让浏览器频繁进入重新计算状态。

这也是为什么很多性能优化建议都会强调：

- 批量更新 DOM
- 减少无意义布局读取
- 避免在循环里不断改样式

## JavaScript 为什么会影响页面渲染

因为浏览器主线程既要执行 JavaScript，也要处理布局和绘制。

如果 JavaScript 长时间占住主线程，渲染相关工作就会被推迟，用户看到的就是卡顿、掉帧、响应慢。

所以前端性能优化不只是资源优化，也包括控制主线程负载。

## 建立基础认知比记技巧更重要

理解浏览器渲染流程最大的价值，不是让你背术语，而是帮助你判断：

- 某种改动大概会影响哪一层
- 某个性能问题更可能出在什么阶段
- 哪些优化建议是真的有因果关系

## 写在最后

浏览器渲染机制看起来是底层知识，但它和日常前端开发关系非常紧密。

只要你理解了 DOM、CSSOM、布局和绘制之间的关系，很多性能和样式问题都会更容易分析。基础认知建立起来之后，优化才不只是“照着做”，而是“知道为什么这么做”。


浏览器渲染基础笔记：理解页面是怎么被画出来的


做前端开发时，缓存是一个绕不开的话题。

页面访问快不快、资源更新生不生效、用户是不是还在看旧代码，这些问题很多都和缓存有关。

但缓存相关概念第一次接触时经常会有点绕，尤其是强缓存和协商缓存，很容易记混。

## 为什么浏览器要缓存资源

原因很直接：

- 减少重复请求
- 加快页面加载
- 降低服务器压力

像 JS、CSS、图片这类静态资源，如果每次访问都重新下载，成本会很高。浏览器缓存就是为了避免这种重复消耗。

## 什么是强缓存

强缓存的意思是：浏览器认为本地资源还有效，所以直接使用，不再向服务器发请求。

常见相关字段有：

- `Cache-Control`
- `Expires`

只要资源还在有效期内，浏览器就会直接从本地取。

这也是为什么有时你明明改了线上文件，但用户访问页面却看不到最新效果，因为浏览器根本没再请求服务器。

## 什么是协商缓存

协商缓存的意思是：浏览器会先去问服务器，这个资源有没有变。

如果服务器确认没变，就返回一个轻量响应，告诉浏览器继续用本地版本。

常见相关字段有：

- `Last-Modified` / `If-Modified-Since`
- `ETag` / `If-None-Match`

它和强缓存的区别在于，协商缓存会发请求，但不一定重新下载资源内容。

## 两者关系怎么理解

可以简单理解成：

- 强缓存优先
- 强缓存失效后，再走协商缓存

也就是说，一个资源如果还在强缓存有效期内，浏览器通常不会走协商缓存。

## 为什么前端项目常用带 hash 的文件名

因为静态资源更新时，最大的难题之一就是“如何让浏览器知道这个资源变了”。

如果文件名不变，浏览器可能继续用旧缓存。

所以构建工具通常会产出像下面这样的文件名：

- `app.a1b2c3.js`
- `main.9f8e7d.css`

当内容变化时，hash 也会变化，浏览器会把它当成一个新资源重新请求。

这就是为什么现代前端项目常常会把“长缓存 + 文件名 hash”组合在一起使用。

## 更新不生效的常见原因

### 1. 文件名没变

资源内容更新了，但 URL 没变，浏览器可能继续命中缓存。

### 2. HTML 本身缓存策略不合理

很多项目对静态资源做了 hash，却忘了入口 HTML 也需要合理控制缓存。

如果 HTML 还是旧的，那它引用的资源地址也可能还是旧的。

### 3. 本地调试和生产环境策略混淆

开发环境通常更强调实时更新，生产环境更强调缓存效率。两边策略如果不区分，问题就会变多。

## 缓存不是越久越好

缓存确实能提升性能，但并不是缓存时间越长越好。

如果更新策略没有设计好，过长缓存会直接变成发布风险。

所以前端缓存真正需要平衡的是：

- 性能
- 可更新性

## 写在最后

理解浏览器缓存的关键，不是死记字段，而是搞清楚浏览器什么时候直接用本地、什么时候去问服务器、什么时候必须重新下载。

只要把强缓存、协商缓存和文件 hash 之间的关系理顺，前端资源更新问题就会清晰很多。缓存不是玄学，它说到底是资源管理策略的一部分。


前端缓存基础：强缓存、协商缓存和资源更新到底该怎么理解


很多前端页面在电脑上看起来没什么问题，一到手机上就开始暴露大量细节问题：

- 字太小
- 按钮难点
- 间距太挤
- 图片被撑破
- 列表层级混乱

这说明移动端适配从来不只是“把宽度缩小”这么简单。

## 移动端和桌面端的核心差异

移动端适配最先要理解的，不是技术，而是使用环境差异。

相比桌面端，移动端通常有这些特点：

- 屏幕更窄
- 触控优先
- 用户注意力更分散
- 可见区域更小

所以同一个布局在电脑上“信息丰富”，在手机上可能就是“阅读压力很大”。

## 响应式不只是改列数

做响应式时，主要做的是：

- 三列变两列
- 两列变一列

这当然是基础，但不够。

移动端适配通常还要考虑：

- 字体大小是否适合阅读
- 行高是否足够舒适
- 点击区域是否足够大
- 信息层级是否需要重组

有些桌面端布局并不是缩小后继续摆放，而是应该重新组织内容顺序。

## 图片和媒体内容一定要自适应

图片是移动端最容易出问题的内容之一。

常见问题包括：

- 图片固定宽高导致溢出
- 多图布局在小屏里过挤
- 大图加载太慢

所以在移动端里，媒体内容通常要优先保证：

- 宽度跟容器走
- 高度按比例自适应
- 不在小屏里强行保留复杂排版

## 触控体验和鼠标体验不一样

桌面端很多交互默认依赖 hover，但移动端没有 hover 这个自然前提。

这意味着：

- 不要把关键信息只放在 hover 态里
- 不要让按钮太小
- 需要给手指点击留出足够空间

在手机上，“能点到”本身就是体验的一部分。

## 文本排版比你想的更重要

移动端不是桌面端缩小版，长文本阅读尤其能体现这一点。

如果标题过大、行距太紧、段落过长，阅读压力会明显增加。

所以移动端里更值得关注：

- 标题层级是否清楚
- 每行文字长度是否合适
- 行距是否足够
- 段间距是否有节奏

## 适配不是一次性工作

页面开发里常见的情况是第一次上线时会对几个常见机型调一下，看起来差不多就结束了。

但真实情况是，不同尺寸、不同系统、不同字体缩放设置都会影响展示效果。

所以适配更像一种持续校正，而不是一次性完成。

## 写在最后

移动端适配真正要解决的，不只是布局能不能缩进去，而是内容在小屏环境下还能不能被舒服地浏览和操作。

把响应式理解成“重新组织体验”，比理解成“改几个宽度断点”更接近实际开发。只要这个认知建立起来，很多适配 decisions 会更自然。


移动端适配入门：做前端页面时，别把响应式理解成只改宽度


Docker 是一个开源的应用容器引擎，让开发者可以打包他们的应用以及依赖包到一个可移植的容器中，然后发布到任何流行的 Linux 机器上。

## Docker 的基本概念

- **镜像（Image）**：Docker 镜像是一个只读的模板，用来创建 Docker 容器。
- **容器（Container）**：Docker 容器是镜像的可运行实例。
- **Dockerfile**：用来构建 Docker 镜像的文本文件，包含了一条条构建镜像所需的指令。

## 创建一个简单的 Dockerfile

以下是一个简单的 Node.js 应用的 Dockerfile：

```dockerfile
FROM node:14
WORKDIR /app
COPY package*.json ./
RUN npm install
COPY . .
EXPOSE 3000
CMD [ "node", "server.js" ]
```

## 构建和运行 Docker 容器

构建镜像：

```bash
docker build -t my-node-app .
```

运行容器：

```bash
docker run -p 3000:3000 my-node-app
```

## Docker Compose

对于多容器应用，可以使用 Docker Compose 来定义和运行多个 Docker 容器。

```yaml
version: '3'
services:
  web:
    build: .
    ports:
      - "3000:3000"
  db:
    image: mongo
    volumes:
      - ./data:/data/db
```

Docker 使得应用的部署和扩展变得更加简单和一致。继续学习更多关于 Docker 网络、数据卷、以及如何在生产环境中使用 Docker 的知识。

Docker 入门：容器化你的应用


前端项目一旦进入多人协作阶段，很多问题看起来像是 Git 问题，实际上往往是协作习惯问题。

例如：

- 提交信息看不懂
- 一个分支改动太大
- 冲突频繁
- 回滚困难

Git 本身并没有做错什么，问题通常出在团队怎么使用它。

## 提交粒度太大，是很多协作问题的起点

很多人习惯攒一堆改动再一起提交，结果一个 commit 里同时包含：

- 新功能
- 样式调整
- 文案修改
- 顺手重构
- 调试代码删除

这样的提交在自己脑子里可能还是清楚的，但对其他协作者来说，可读性会非常差。

更合理的方式通常是按“一个明确意图”提交。

## 提交信息是给后来的人看的

很多提交信息写成：

- `fix`
- `update`
- `修改一下`

这类信息当下可能图省事，但后面排查问题、查历史时几乎没有帮助。

好的提交信息不需要写成长文，但至少应该表达：

- 改了什么
- 为什么改

## 分支不要活得太久

一个功能分支拖得越久，后面越容易：

- 与主干偏离
- 冲突增多
- 难以 review
- 难以回滚

所以长期看，保持分支生命周期适中，比“一个大分支搞完整个版本”更稳。

## 冲突并不可怕，可怕的是不理解改动就解决

很多人处理冲突时，只想尽快让它过去，结果用的是“谁的代码看起来顺眼就保留谁”。

这在简单文件上可能没问题，但如果涉及逻辑变更，很容易把一部分正确改动无意中覆盖掉。

处理冲突时，还有一个更关键的问题是先理解两边各自改了什么。

## 前端项目尤其要注意产物文件

前端项目里常见一些自动生成内容，例如：

- 构建产物
- 锁文件
- 搜索索引
- 站点地图

这些文件是否应该进版本库，什么时候更新，团队最好有一致规则。否则很容易出现无意义冲突或脏提交。

## 写在最后

Git 协作真正决定效率的，往往不是命令熟不熟，而是团队有没有形成清晰的提交和分支习惯。

只要提交粒度更清楚、分支不要拖太久、冲突时先理解再解决，很多看起来麻烦的协作问题都会少很多。


前端团队协作中的 Git 习惯：很多低级问题其实和工具本身无关

在进行博客设计时，确保在移动端和电脑端都拥有良好的阅读体验是非常重要的。借助 Tailwind CSS，我们可以轻松实现这一目标。本文将为你介绍如何使用 Tailwind CSS 优化博客的字体设计，并确保在不同设备上获得一致的用户体验。

### 1. **基础字体大小设计**

在 Tailwind CSS 中，你可以通过 `text-base`、`text-lg` 等类来轻松设置不同设备的字体大小。以下是移动端和电脑端的基础字体大小设计建议：

- **移动端：**
  - 正文：`text-base`（默认是 16px）
  - 一级标题：`text-2xl`（默认是 24px）
  - 二级标题：`text-xl`（默认是 20px）
  - 三级标题：`text-lg`（默认是 18px）
  - 辅助文字：`text-sm`（默认是 14px）

- **电脑端：**
  - 正文：`lg:text-lg`（18px）
  - 一级标题：`lg:text-4xl`（36px）
  - 二级标题：`lg:text-2xl`（24px）
  - 三级标题：`lg:text-xl`（20px）
  - 辅助文字：`lg:text-base`（16px）

通过这种方式，你可以确保博客在不同设备上都拥有适合的阅读体验。

### 2. **响应式设计**

借助 Tailwind CSS 的响应式工具，你可以为不同的设备屏幕设置不同的样式。在 Tailwind 中，默认提供了几个断点：
- `sm`：适用于 640px 及以下的设备（移动端）
- `md`：适用于 768px 及以下的设备（平板）
- `lg`：适用于 1024px 及以上的设备（电脑端）
- `xl`：适用于 1280px 及以上的设备（大屏幕）

例如，通过以下代码，你可以为移动端和电脑端分别设置不同的字体大小：

```html

<div class="prose">
  <h1 class="text-2xl lg:text-4xl">一级标题</h1>
  <h2 class="text-xl lg:text-2xl">二级标题</h2>
  <p class="text-base lg:text-lg">这是正文内容。</p>
  <span class="text-sm lg:text-base">辅助文字</span>
</div>
```

在这个示例中，移动端会使用较小的字体，而在较大的屏幕上，字体会自动变大，以提升可读性。

### 3. **自定义行距**

在长篇阅读内容中，行距的调整同样非常重要。Tailwind CSS 提供了 `leading` 类来控制行距。例如：
```html
<p class="text-base leading-7 lg:text-lg lg:leading-8">
  这是适合博客的正文文字。
</p>
```
- `leading-7`：表示行距为字体大小的 1.75 倍，适合长时间阅读。
- `lg:leading-8`：确保在大屏设备上有更舒适的阅读体验。

### 4. **图片的自适应设计**

除了文字，图片等媒体内容也需要适应不同设备。你可以通过 `w-full` 和 `h-auto` 类来使图片根据容器自动调整大小：
```html
<img src="image.jpg" class="w-full h-auto" alt="Responsive image">
```

这确保了图片能够在移动端和电脑端都以适当的比例显示，保持良好的视觉效果。

### 5. **示例代码总结**

为了更好地理解，我们可以通过以下完整的代码示例来展示如何使用 Tailwind CSS 实现响应式的博客字体设计：
```html
<div class="prose max-w-none">
  <h1 class="text-2xl lg:text-4xl leading-tight">博客标题</h1>
  <h2 class="text-xl lg:text-2xl leading-snug mt-4">二级标题</h2>
  <p class="text-base lg:text-lg leading-7 lg:leading-8 mt-2">
    这是文章的正文，适合长时间阅读，行距设置为 1.75 倍，确保内容清晰易读。
  </p>
  <span class="text-sm lg:text-base text-gray-500 mt-1 block">日期：2024-09-04</span>
</div>
```

### 6. **结论**

借助 Tailwind CSS 的灵活性，你可以通过响应式工具轻松调整博客在不同设备上的字体大小、行距和媒体展示效果。无论是移动端还是电脑端，你的博客都将拥有良好的视觉层次感和阅读体验。

---

通过以上方案，你可以确保博客在各种设备上都有一致的视觉效果和用户体验。这种基于 Tailwind CSS 的解决方案，不仅简洁易用，还能够根据需要快速调整和优化布局。

使用 Tailwind CSS 实现博客在移动端和电脑端的字体适配


前端开发早期，很多代码都是直接挂在全局作用域里的。

页面功能少的时候问题不明显，但随着项目变大，很快就会出现：

- 变量冲突
- 依赖关系混乱
- 文件加载顺序敏感
- 代码难拆难测

模块化正是为了解决这些问题而逐渐成为前端工程基础能力的。

## 模块化到底解决了什么

可以把模块化理解成：让代码有明确边界。

一个模块通常会说明：

- 它暴露什么
- 它依赖什么
- 它内部细节不希望外界直接碰什么

这样做的最大价值，不是语法更高级，而是系统更容易组织。

## 没有模块边界时会发生什么

如果所有变量和函数都散落在全局环境里，项目一大就很难管理。

常见问题包括：

- 同名函数被覆盖
- 某个文件必须先加载
- 调整一处代码影响未知区域

这些问题本质上都是边界缺失带来的。

## 模块化让依赖关系变得显式

以前一个函数能不能用，可能取决于某个文件是否先被引入；模块化之后，依赖可以直接通过导入关系表达出来。

这会带来很多工程收益：

- 更容易理解代码结构
- 更容易拆分文件
- 更容易做按需加载
- 更容易测试

## 模块拆分也不是越细越好

模块化的目标是清晰，不是把文件切得无限碎。

如果一个功能被拆成大量细小文件，但每个文件都彼此强依赖，阅读成本反而会上升。

所以模块拆分还有一个更关键的问题是按职责，而不是按行数。

## 模块边界会直接影响维护体验

一个边界清楚的模块，通常更容易做到：

- 只改局部
- 独立测试
- 替换实现
- 复用逻辑

反过来，如果模块之间相互穿透，虽然代码形式上用了 import/export，实际维护体验还是很差。

## 写在最后

JavaScript 模块化看起来像语法层能力，但它真正改变的是前端项目的组织方式。

随着项目越来越复杂，模块边界会越来越重要。理解模块化，不只是会写导入导出，而是开始学会让代码结构更清楚、更稳定、更容易协作。


JavaScript 模块化基础：为什么前端工程越来越离不开模块边界


前端开发里，事件是最基础也最常见的能力之一。

点击按钮、输入内容、提交表单、滚动页面，这些交互的背后其实都离不开事件机制。

实际开发中大家会直接使用事件，但一旦遇到下面这些情况，就会发现自己其实并没有真正理解它：

- 为什么点击子元素时父元素的事件也触发了
- 为什么有些事件监听加在父级上也能生效
- 为什么 `stopPropagation` 有时能解决问题，有时又不够

这些问题都和 DOM 事件机制有关。

## 什么是事件传播

当你点击一个页面元素时，浏览器并不是只把这次点击交给当前元素处理。

它会沿着 DOM 树进行一轮传播，这个传播过程通常分成三个阶段：

1. 捕获阶段
2. 目标阶段
3. 冒泡阶段

简单理解就是，事件会先从外往里走，再从里往外走。

## 冒泡为什么这么重要

在日常开发中，最常遇到的通常是冒泡。

例如：

```javascript
parent.addEventListener('click', () => {
  console.log('parent clicked');
});

child.addEventListener('click', () => {
  console.log('child clicked');
});
```

当点击子元素时，通常会先触发子元素，再触发父元素。这就是冒泡。

理解这一点很重要，因为很多交互问题其实不是“事件绑错了”，而是没有意识到事件还会继续向上传播。

## 捕获阶段什么时候会用到

捕获阶段在业务开发里不像冒泡那样常见，但它确实存在。

如果你通过第三个参数或配置项启用捕获监听，事件会先在外层元素触发，再到目标元素。

```javascript
parent.addEventListener(
  'click',
  () => {
    console.log('capture');
  },
  true
);
```

大多数场景下你不一定主动用它，但知道它的存在，能帮助你更好理解事件执行顺序。

## 什么是事件委托

事件委托是前端里非常实用的一种技巧。

它的思路是：不把事件直接绑定在每个子元素上，而是绑定在它们的父元素上，再通过事件对象判断具体是哪个子元素触发的。

例如列表：

```javascript
list.addEventListener('click', (event) => {
  if (event.target.matches('li')) {
    console.log('clicked item');
  }
});
```

这样做的好处很明显：

- 减少重复绑定
- 动态新增元素也能响应
- 结构更集中

## stopPropagation 是做什么的

如果你不希望事件继续向上传播，可以调用：

```javascript
event.stopPropagation();
```

这通常用于阻止父级事件误触发。

例如一个卡片整体可点击，卡片内部又有删除按钮，这时删除按钮点击后如果不阻止传播，卡片点击逻辑也可能被触发。

## 事件对象里最常用的几个属性

日常开发中比较常见的有：

- `target`
- `currentTarget`
- `preventDefault`

其中最容易混的是：

- `event.target` 表示实际触发事件的元素
- `event.currentTarget` 表示当前正在处理事件的元素

理解这两个区别，对写事件委托特别重要。

## 默认行为和传播不是一回事

很多人刚开始会把这两个概念混在一起。

例如点击链接时：

- 阻止跳转，要用 `preventDefault`
- 阻止事件继续向父级传播，要用 `stopPropagation`

它们解决的是两类不同问题。

## 写在最后

DOM 事件机制最重要的，不是死记捕获和冒泡的定义，而是理解事件在页面中的传播路径。

只要把事件传播、事件委托、默认行为和当前目标这几个概念理顺，很多日常交互问题都会更容易分析。事件机制看起来基础，但它几乎贯穿了整个前端交互开发。


DOM 事件机制入门：捕获、冒泡和事件委托到底该怎么理解


前端开发离不开请求。

页面展示数据、提交表单、刷新列表、加载详情，这些动作几乎都要和服务端通信。

如果把时间往前拉，大家最熟悉的方式可能是 Ajax；再往后，Fetch 逐渐成为更常见的写法。它们都能完成请求，但带来的开发体验并不完全一样。

## Ajax 解决了什么问题

Ajax 最重要的价值，是让页面不必整页刷新也能和服务端交换数据。

这在早期前端开发里是一次很大的改变，因为它让页面开始具备更强的交互性和动态性。

大家最熟悉的实现通常是 `XMLHttpRequest`。

```javascript
const xhr = new XMLHttpRequest();
xhr.open('GET', '/api/list');
xhr.onreadystatechange = function () {
  if (xhr.readyState === 4 && xhr.status === 200) {
    console.log(xhr.responseText);
  }
};
xhr.send();
```

这个写法并不是不能用，但确实比较底层。

## Fetch 为什么更容易被接受

Fetch 更贴近现代 JavaScript 的编码方式。

它的 API 更简洁，也更容易和 Promise、`async/await` 组合。

```javascript
async function loadData() {
  const response = await fetch('/api/list');
  const data = await response.json();
  console.log(data);
}
```

相比 `XMLHttpRequest`，这种写法的优势主要体现在：

- 更容易阅读
- 更容易封装
- 更适合现代异步流程

## 两者的差异不只是“新旧”

不少人会简单理解成“Fetch 就是更现代的 Ajax”，但更准确地说，它们代表了两种不同层级的开发体验。

`XMLHttpRequest` 更像底层接口，你需要自己处理很多状态变化。

Fetch 则更像一个围绕请求流程设计得更现代的抽象。

## Fetch 使用时也有需要注意的地方

虽然 Fetch 更简洁，但它也有一些容易踩坑的点。

例如很多人第一次用时会以为：

- 请求失败就会进入 `catch`

实际上不是所有 HTTP 错误状态都会自动抛异常。比如返回 404、500，Fetch 依然可能算“成功收到响应”，只是 `response.ok` 为 `false`。

所以通常还要自己判断：

```javascript
const response = await fetch('/api/list');

if (!response.ok) {
  throw new Error('request failed');
}
```

## 请求封装的重要性

无论使用 Ajax 还是 Fetch，真正影响项目维护体验的，往往不是底层 API 本身，而是你有没有做好请求层封装。

例如：

- base URL
- 通用 headers
- 错误处理
- token 注入
- 超时控制

如果这些都散落在页面里，请求方式再现代，项目后期也会很难维护。

## 从工具切换到抽象思维

很多技术演进表面看起来只是 API 更新，实际上还有一个更关键的问题是推动开发者思维变化。

从 Ajax 到 Fetch，更有价值的变化不只是代码少了几行，而是前端异步请求开始更自然地融入整体工程结构。

## 写在最后

从 Ajax 到 Fetch，是前端请求方式一次很自然的演进。前者解决了页面局部更新的问题，后者则让请求代码更容易和现代 JavaScript 编程方式结合。

工具当然会变化，但真正值得沉淀的是请求层的组织方式。只要这层思路清楚，用什么接口都不会太乱。


从 Ajax 到 Fetch：前端请求方式的演进到底带来了什么


刚开始做前端时，不少人第一次接触“语义化 HTML”时，会把它理解成一个偏理论的问题。

因为在页面开发里常见的情况是里，似乎用一堆 `div` 也能把界面搭出来，看起来并不影响功能。

但只要项目稍微复杂一点，就会发现结构表达清楚和结构表达混乱，长期维护体验差别非常大。

## 什么叫语义化

语义化的核心不是标签多高级，而是让标签表达内容本身的含义。

例如：

- 文章用 `article`
- 页头用 `header`
- 导航用 `nav`
- 主要内容区用 `main`
- 按钮用 `button`

这样做的价值，是让页面结构更容易被人和工具理解。

## 为什么不能什么都用 div

`div` 本身没有错，它是一个通用容器。

问题在于，如果一个页面几乎所有地方都靠 `div` 组织，那结构信息就被大量丢失了。

你虽然看得见页面长什么样，但很难从 DOM 结构里直接判断：

- 哪里是导航
- 哪里是正文
- 哪里是列表
- 哪里是按钮

这会直接影响后续开发体验。

## 语义化对维护有什么帮助

当页面结构清楚时，后来的人会更容易理解代码。

例如看到：

```html
<article>
  <header>...</header>
  <section>...</section>
</article>
```

比起一串嵌套 `div`，它表达的信息更多，也更接近页面真实结构。

在多人协作和长期维护里，这种清晰度非常重要。

## 语义化和可访问性有很强关系

很多语义标签不只是“长得更好看”，它们还会影响辅助技术如何理解页面。

例如：

- 读屏工具可以更清楚地识别结构
- 表单控件能获得更合理的默认语义
- 按钮和链接的行为边界更明确

这就是为什么语义化往往和可访问性一起被讨论。

## 按钮和链接尤其容易用错

这是最常见的问题之一。

页面开发里常见的情况是会把一个可点击的 `div` 当按钮，也会把一个只执行动作的元素写成链接。这样虽然视觉上可行，但语义上是混乱的。

一个比较简单的原则是：

- 跳转用链接
- 操作用按钮

这个边界如果守住，很多交互和可访问性问题都会减少。

## 语义化不会让你写得更慢

很多人担心语义化会增加开发成本，但实际上大部分时候只是习惯问题。

只要你在搭结构时多想一步“这个区域本来是什么”，写出来的代码通常不会更复杂，反而更稳定。

## 写在最后

语义化 HTML 的价值，不在于它是一个标准答案，而在于它让页面结构表达得更清楚。

当你开始把 HTML 当作“内容结构语言”，而不是“页面摆放容器”，代码的可维护性、可访问性和整体质量通常都会更进一步。它并不是额外要求，而是 Web 基础的一部分。


语义化 HTML 为什么重要：它不只是面试题，而是页面质量的基础


前端做一些小型功能时，本地存储是一个非常方便的能力。

比如：

- 保存主题设置
- 记录搜索历史
- 缓存草稿内容
- 记录上次浏览状态

这时不少人会第一时间想到 `localStorage`。它确实好用，但也很容易被滥用。

## localStorage 的特点

`localStorage` 最直接的特点有两个：

- 存储在浏览器本地
- 数据会长期保留，除非手动清除

它的使用方式也很简单：

```javascript
localStorage.setItem('theme', 'dark');
const theme = localStorage.getItem('theme');
```

这也是它会成为很多前端功能第一选择的原因。

## 适合存什么

`localStorage` 更适合保存一些轻量、低风险、用户体验相关的数据，例如：

- 页面偏好设置
- 非敏感草稿
- 最近浏览记录
- 搜索关键字历史

这些数据就算丢了，影响通常也比较有限。

## 不适合存什么

虽然 `localStorage` 很方便，但它并不适合所有数据。

特别不建议直接存：

- 敏感信息
- 大量结构化数据
- 强一致性要求很高的数据

因为它本质上只是浏览器提供的一种简单存储能力，不是可靠的业务数据库。

## 数据通常要自己做序列化

`localStorage` 存的是字符串，所以如果你要保存对象，通常需要自己转换：

```javascript
const user = { name: 'Tom', age: 18 };
localStorage.setItem('user', JSON.stringify(user));

const value = JSON.parse(localStorage.getItem('user'));
```

这意味着你后面还要考虑：

- 解析失败怎么办
- 老数据结构升级怎么办
- 某个字段缺失怎么办

## 它是同步 API

很多人第一次使用时不会特别在意这一点，但 `localStorage` 的读写是同步的。

在小量数据场景问题不大，但如果你频繁读写，或者存储内容比较大，依然可能影响主线程。

所以它适合轻量场景，不适合高频、大量数据写入。

## 用它做用户体验增强很合适

`localStorage` 最适合做的，其实不是业务主数据，而是体验增强。

比如：

- 自动记住夜间模式
- 页面刷新后保留筛选项
- 输入中断后恢复草稿

这类功能的收益很高，实现成本也低。

## 写在最后

`localStorage` 是前端开发里一个很实用的工具，但它的定位更像“本地轻量缓存”，而不是一个通用数据库。

只要你清楚它适合什么、不适合什么，就能在很多小功能里很好地提升用户体验。方便当然重要，但边界同样重要。


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 常用特性回顾：真正改变前端开发体验的是哪些能力


CSS 里最基础的一步，其实不是写什么样式，而是先把元素选对。

如果选择器本身理解不清楚，后面写出来的样式很容易出现：

- 命中了不该命中的元素
- 优先级不好控制
- 结构一变样式就失效

所以选择器虽然基础，但值得认真整理一下。

## 最常见的几种选择器

日常开发里最常见的通常有：

- 标签选择器
- 类选择器
- ID 选择器

例如：

```css
p {}
.title {}
#app {}
```

其中类选择器通常是最常用的，因为它既灵活，又不会像 ID 那样过于绑定唯一结构。

## 后代选择器和子选择器不要混

这是很多初学者容易混淆的地方。

```css
.card p {}
.card > p {}
```

第一种表示选中 `.card` 内部所有后代 `p`。

第二种表示只选中 `.card` 的直接子元素 `p`。

看起来只是一个符号差异，但实际命中范围差很多。

## 并列选择器和多类选择器也不同

例如：

```css
.title.highlight {}
.title, .highlight {}
```

前者表示同一个元素同时拥有两个类。

后者表示匹配两个不同规则集合。

这类细节如果没搞清楚，写样式时很容易误判作用范围。

## 伪类和伪元素的作用

CSS 里还有两类很常用的能力：

- 伪类
- 伪元素

例如：

```css
a:hover {}
li:first-child {}
p::before {}
```

伪类更偏向元素状态，伪元素更偏向附加生成内容。

## 选择器不要写得过深

样式后期失控，一个常见原因就是选择器链写得太长。

例如：

```css
.page .content .list .item .title {}
```

这种写法短期看很精确，长期看却会带来两个问题：

- 结构耦合过强
- 后期难以复用和覆盖

所以选择器不是越精确越好，而是要在清晰和可维护之间平衡。

## 写在最后

CSS 选择器看起来只是基础语法，但它直接决定了样式命中范围和后期维护成本。

写样式之前，先把元素选对，比后面不断修补覆盖更重要。基础打稳之后，很多样式问题其实一开始就可以避免。


CSS 选择器整理：写样式之前，先把元素选对


Vue 3 刚出来时，很多人的第一反应是：又换写法了。

这很正常。毕竟从 Options API 切到 Composition API，表面上最明显的变化就是组织方式完全不一样。

可如果只把它理解成“语法新不新”，就很容易低估它真正想解决的问题。

## Composition API 主要解决的是组织问题

Options API 在小组件里其实很好用，`data`、`methods`、`computed` 一眼就能看明白。

问题主要出在组件越来越大时。

一个功能要跨 `data`、`watch`、`methods`、生命周期来回跳，读代码会越来越碎。这时候 Composition API 的价值才会显出来：把同一类逻辑收拢到一起。

## 它不是为了让代码更短

有些例子会把 Composition API 写得很紧凑，看起来像是“更高级的写法”。但真实项目里，它更大的价值不是短，而是能把一个功能模块放在一起看。

比如搜索逻辑、分页逻辑、表单逻辑，各自可以有自己的状态和动作，不必再拆散在不同选项里。

## 写在最后

Composition API 真正值得关注的地方，不是新，而是它给了 Vue 组件一种新的组织方式。

如果你的组件规模还很小，Options API 依然很好用；但一旦逻辑开始变长、横切面增多，Composition API 的优势就会越来越明显。


Vue 3 Composition API 初看：它不是为了替代一切，而是为了解决组织问题


我第一次真正对 Vite 上心，不是因为它是个新工具，而是因为我当时手上的一个 Vue 项目，开发体验已经被等待感拖得很明显了。

那个项目是典型的后台系统。页面不算特别花哨，但模块很多，表单、表格、弹窗、权限、图表、富文本都有。项目刚起的时候，Vue CLI 配 Webpack 跑得挺稳，谁也没觉得有什么问题。可越往后做，团队对开发环境的抱怨越多，而且大家抱怨的不是“不能用”，而是“总得等一下”。

启动要等。
切分支后重启要等。
改个样式保存要等。
偶尔热更新失效，再等。

这种等待单看都不算灾难，可它分散在一天里几十次操作中，最后会把人磨得很烦。尤其是做页面微调的时候，明明只是想看个字号或间距变化，却得不断在保存和刷新之间停顿。

## 我当时并不是真的想“换工具链”

说实话，2020 那会儿我对“再来一个新工具”没有特别强的热情。

因为从项目角度看，Webpack 并不差：

- 配置成熟
- 生态足够全
- Vue CLI 也很顺手

问题主要不在功能，而在开发过程里的反馈速度。

所以我最开始看 Vite，不是因为想追新，而是因为它正好踩在了那个痛点上。大家讨论它快，我就真的想知道，到底是“宣传里的快”，还是那种开发时一上手就能感受到的快。

## 第一次跑起来时，最直观的感受不是理念，而是轻

我还记得第一次拿一个小 Vue 页面试跑 Vite 的感觉。不是说配置多神奇，也不是说 API 多颠覆，而是那种很直接的轻快感一下子就出来了。

以前习惯了先启动一套 bundler，再等它把东西准备好。Vite 给人的第一反应则是：怎么这么快就起来了？

再改一个组件试一下，热更新的反馈也明显更利落。

这种体验不是靠 benchmark 才能说明的，它是开发者每天都能感知到的东西。尤其当你已经习惯“保存之后等一小会儿”这种节奏时，那种几乎立刻看到变化的感觉会很强。

## 后来我才慢慢理解，它打动人的不是“新”，而是它瞄准了一个长期被忽视的问题

很多前端工具都在强调能力完整、插件丰富、配置灵活。这些当然重要，但开发环境里的等待问题，过去经常被默认成“没办法，只能忍”。

Vite 让我第一次明显感觉到：这件事原来不是只能忍着。

它之所以会让很多 Vue 开发者迅速有反应，不是因为大家突然厌倦了 Webpack，而是因为我们都已经在真实项目里对那种启动慢、热更新钝的体验积累了足够多的不耐烦。

## 我没有马上迁项目，但我对工具链的判断开始变了

那次试完之后，我并没有立刻把手头的大项目迁过去。原因很现实：

- 旧项目的自定义配置很多
- 构建脚本和部署流程已经跑顺了
- 当时 Vite 还很新，不适合轻易全量切

但它还是改变了我对工具链的一些判断。

以前我更容易把开发工具看成“只要能跑就行”的基础设施。那次之后，我开始更认真地看待开发反馈本身。因为它并不是次要体验，而是每天都在影响写代码节奏的核心部分。

一个工具链如果让你每天多等几十次，每次只多几秒，最后吞掉的不是时间总量那么简单，还有注意力和耐心。

## 为什么 Vue 开发者会特别关注它

Vite 是 Evan You 发起的项目，这当然会天然吸引 Vue 社区的注意力。但我后来越来越觉得，真正让它被讨论起来的，不是“出身”，而是它刚好回应了 Vue 工程实践里一个持续存在的问题。

Vue 一直强调开发体验，这也是很多人喜欢它的原因。那当开发环境本身开始拖后腿时，大家自然会对一种更轻、更快的方案特别敏感。

换句话说，Vite 不是凭空冒出来的热点，它更像是对长期积累的不满给出的一个回答。

## 回头看，那次体验给我留下的感受其实很朴素

我现在再回想第一次接触 Vite，印象最深的不是它做了多少“革命性改变”，而是它让我重新感受到前端开发本来可以更顺。

很多工具发布时都会讲愿景、讲架构、讲趋势，这些都值得看。但真正让开发者决定继续用下去的，往往还是那种非常朴素的体验：

- 我改完代码能不能更快看到结果
- 我每天是不是少被打断一点
- 我是不是终于不用一直等

## 写在最后

Vite 在 2020 这个时间点最吸引我的地方，从来都不是“它很新”，而是它把开发过程里那种长期存在但经常被忽略的等待感，正面拿出来解决了。

它未必会立刻替掉所有工具链，但它至少让人意识到，开发环境的迟钝并不是只能接受的现实。对 Vue 开发者来说，这种感受很直接，也很难假装没发生过。


第一次用 Vite 跑 Vue 项目，最强烈的感受不是新，而是终于不用一直等


前端页面布局一直是开发中非常重要的一部分。

在很多传统写法里，水平排列、垂直居中、间距分布这些需求都需要绕不少弯。Flex 布局之所以被广泛接受，就是因为它让这些常见布局问题变得更自然了。

## Flex 布局解决了什么问题

Flex 更适合处理一维布局，也就是：

- 一行里的元素怎么排
- 一列里的元素怎么排
- 元素之间怎么分配剩余空间

比如导航、按钮组、表单操作栏、卡片头部，这些都非常适合用 Flex。

## 最基础的一步是设置 display: flex

只要一个容器设置了：

```css
.container {
  display: flex;
}
```

它的直接子元素就会进入 Flex 布局上下文。

这也是理解 Flex 的第一个重点：Flex 影响的是容器和直接子元素之间的关系。

## 主轴和交叉轴的概念

Flex 最核心的两个概念是：

- 主轴
- 交叉轴

默认情况下，主轴是水平方向。

也就是说，子元素默认会沿着一行排列。

如果通过：

```css
flex-direction: column;
```

改成纵向，那么主轴就会变成垂直方向。

## justify-content 和 align-items 的区别

这是最容易混淆的一组属性。

- `justify-content` 控制主轴对齐
- `align-items` 控制交叉轴对齐

如果主轴是横向，那么：

- `justify-content` 管水平分布
- `align-items` 管垂直对齐

## 为什么垂直居中变简单了

以前做一个内容水平垂直居中，经常要借助复杂技巧。Flex 之后可以直接这样写：

```css
.box {
  display: flex;
  justify-content: center;
  align-items: center;
}
```

这也是很多人开始喜欢 Flex 的原因之一。

## flex-grow 的作用

Flex 还有一个很实用的能力，就是让某些元素自动占据剩余空间。

例如：

```css
.content {
  flex: 1;
}
```

这样某个区域就可以根据剩余空间自动伸展，非常适合做：

- 左右布局
- 自适应内容区
- 页头中间区域撑满

## 写在最后

Flex 布局之所以会成为前端常用方案，不是因为它万能，而是因为它非常适合解决页面里大量常见的一维布局问题。

只要你理解了主轴、交叉轴、对齐方式和伸缩逻辑，很多过去看起来麻烦的布局都会变得简单很多。


Flex 布局入门：为什么它会成为前端布局的常用方案


Vite 出来之后，Vue 开发者很自然会拿它和 Vue CLI 比。

这两者表面上都能帮你起一个项目、跑开发环境、做打包，但用起来的感觉并不一样。

## Vue CLI 的强项是成熟

Vue CLI 已经陪很多项目跑了很久。

它的优点很明确：

- 上手路径清楚
- Webpack 能力完整
- 插件和配置体系成熟

如果你在一个比较传统、稳定、历史包袱多的项目里，Vue CLI 仍然很靠谱。

## Vite 的吸引力在体验

Vite 最容易让人有感知的地方，就是开发阶段反馈更快。

你甚至不需要先把一堆原理吃透，光是启动和热更新速度，已经足够让人愿意试。

## 这不是淘汰关系

在 2020 这个时间点，更合理的理解不是“谁干掉谁”，而是：

- Vue CLI 代表成熟的 Webpack 工具链
- Vite 代表一种更轻、更快的新方向

## 写在最后

如果你现在手上项目跑得稳，没必要为了新就立刻重构全部工具链；但如果你正在起新项目，Vite 已经足够值得认真看一眼。

它带来的不是小修小补，而是开发体验上的一条新路。


Vue CLI 和 Vite 该怎么看：一个成熟稳，一个轻快直接


数组是 JavaScript 里使用频率非常高的数据结构。

无论是列表渲染、接口数据处理、条件筛选，还是状态更新，很多逻辑最后都会落到数组操作上。

所以理解常用数组方法的区别，比死记语法更重要。

## map：把一个数组变成另一个数组

`map` 最适合做转换。

```javascript
const numbers = [1, 2, 3];
const result = numbers.map(item => item * 2);
```

它不会修改原数组，而是返回一个新数组。

这也是它在前端渲染里特别常见的原因，例如把数据列表映射成组件列表。

## filter：筛选出符合条件的项

`filter` 用来保留符合条件的元素。

```javascript
const users = [
  { name: 'Tom', active: true },
  { name: 'Jerry', active: false }
];

const activeUsers = users.filter(user => user.active);
```

它同样会返回一个新数组。

## find：找到第一个符合条件的元素

如果你只需要一个结果，而不是一个数组，`find` 更合适。

```javascript
const user = users.find(item => item.name === 'Tom');
```

它找到后就会返回对应项，没有找到则返回 `undefined`。

## forEach：只做遍历，不返回结果

`forEach` 更适合执行某些副作用操作。

例如：

```javascript
list.forEach(item => {
  console.log(item);
});
```

如果你的目标是生成新数组，那通常不该用 `forEach`。

## some 和 every

这两个方法也很实用：

- `some`：只要有一个满足条件就返回 `true`
- `every`：必须全部满足才返回 `true`

它们特别适合做条件判断。

## 写在最后

数组方法的关键不在于记住名字，而在于先想清楚你的意图：

- 要转换，就用 `map`
- 要筛选，就用 `filter`
- 要找一个，就用 `find`
- 只遍历执行逻辑，就用 `forEach`

只要意图和方法对上，代码会更清楚，也更不容易写乱。


JavaScript 数组常用方法整理：写业务代码时最常用的是哪几个


Vite 很快，这一点几乎不用太多证明。问题是，项目迁移从来都不只是“新工具更快，所以换过去”。

真正值得先想清楚的是：你现在的 Vue 项目依赖了多少旧工具链假设。

## 迁移前最该先看什么

通常至少要先盘一盘这几类东西：

- 自定义 Webpack 配置有多少
- 别名、环境变量、插件是否深度绑定
- 第三方 loader 是否很多
- 构建脚本和部署流程有没有耦合

如果这些东西很重，迁移就不只是换个启动命令。

## 快是收益，但不是全部收益

Vite 最明显的优势确实是开发快。

但迁移值不值得，最终还是看两件事：

- 迁移成本高不高
- 长期收益能不能覆盖这次改动

## 写在最后

Vue 项目迁到 Vite，最怕的不是踩坑，而是预期太轻。

如果把它看成一次工具升级，准备往往不够；如果把它看成工程假设切换，很多判断就会更稳。


把 Vue 项目迁到 Vite 之前，先想清楚你迁的是速度，还是整套工程假设


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

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

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

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

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

## 写在最后

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

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


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


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

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

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

## 表单的核心作用

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

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

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

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

## 常见表单元素

最常用的通常包括：

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

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

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

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

## label 很重要

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

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

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

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

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

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

## 前端校验和表单体验

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

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

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

## 写在最后

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

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


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


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

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

- Cookie
- sessionStorage
- localStorage

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

## Cookie 的特点

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

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

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

## sessionStorage

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

它的典型特点是：

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

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

## localStorage

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

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

它适合：

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

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

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

可以从两个角度看：

### 1. 生命周期

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

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

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

这个区别非常关键。

## 写在最后

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

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


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


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

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

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

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

一个组件如果同时承担：

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

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

## 写在最后

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

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


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


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

很多人一开始会背：

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

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

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

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

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

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

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

所以这个阶段更适合：

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

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

## mounted 才适合碰 DOM

如果你要做的是：

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

那就更适合放在 `mounted`。

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

## updated 不是补丁桶

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

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

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

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

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

例如：

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

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

## 写在最后

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

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


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


Vue 组件写起来很顺，写着写着就容易把很多东西都塞进首屏。

登录页带上富文本编辑器，详情页顺手把图表模块一起注册，设置页里再挂一个体积不小的可视化库。页面一开始看不出问题，项目大了之后，首屏就会越来越重。

异步组件的价值，就是把这些低频内容往后放。

## 什么时候值得异步加载

一个组件如果同时满足下面几条，就很适合异步化：

- 体积不小
- 首屏不一定会看到
- 打开频率不高
- 和核心路径解耦

比如：

- 富文本编辑器
- 大图表
- 高级筛选面板
- 复杂弹窗

## 为什么说它不只是优化技巧

很多人把异步组件理解成“最后再做的性能优化”，其实不是。

当你决定某个模块应该按需加载时，本质上是在表达页面优先级：

- 哪些内容必须先到
- 哪些内容可以后到

这已经不是单纯的打包问题，而是页面结构判断。

## Vue 里的写法很直接

```javascript
components: {
  ChartPanel: () => import('./ChartPanel.vue')
}
```

写法很简单，但背后的意义很明确：这个组件不是页面一启动就必须拿到的。

## 写在最后

页面做大以后，异步组件不该只是“顺手优化一下”。它更像一种节奏控制，让用户先看到真正重要的部分。

在 Vue 项目里，越早建立这种按需加载意识，后面的性能成本越低。


Vue 异步组件值得早点用：页面越大，按需加载越像基本功


Vue 里做逻辑复用时，Mixins 是很自然会接触到的一种方式。

刚开始用时它很顺手：提一段公共逻辑，多个组件混进来就能复用。可一旦项目做久，很多团队都会感受到同一个问题：Mixin 好写，但不太好管。

## Mixin 最大的问题是“隐式”

组件引入一个 Mixin 后，表面上只是多了一行配置，实际上它可能带来：

- data
- methods
- computed
- 生命周期

这些能力会直接混进当前组件里。

功能上当然成立，但阅读代码的人很容易看不出来某个字段到底来自哪里。

## 一开始省事，后面成本会上来

Mixin 常常在项目前期特别讨喜，因为它能很快解决：

- 表单通用逻辑
- 列表加载逻辑
- 权限判断逻辑

可随着 Mixin 越来越多，组件就开始出现两个典型问题：

- 命名冲突
- 来源不清

这时调试体验会明显变差。

## 复用逻辑不能只看“抽没抽出来”

真正稳定的复用，不只是把代码搬到另一个文件，而是要让依赖关系仍然清楚。

如果一个组件用了多个 Mixin，后面想知道：

- 哪个方法是谁提供的
- 哪个生命周期里做了什么
- 为什么这个字段会突然存在

这些问题都会变得不那么直观。

## 写在最后

Mixin 当然能用，但它更适合短期、简单、边界清楚的逻辑复用。

一旦项目越来越复杂，光“能复用”已经不够，来源和边界同样重要。代码复用如果把可读性搭进去，后面通常会还回来更多维护成本。


Vue Mixins 用久了为什么容易乱：复用逻辑不等于把代码拼在一起


Vue 项目包一大，最容易出现的情况就是大家开始凭感觉优化。

有人觉得是图片大，有人怀疑某个 UI 库太重，也有人想先改构建参数。问题是，在没有看到真实体积分布之前，很多判断都只是猜。

这时最值得做的第一步，不是马上删代码，而是先把包看清楚。

## Bundle Analyzer 的价值不在图炫

很多人第一次看到打包分析图，会被那一堆彩色方块吸引。但真正重要的不是图好不好看，而是它让你知道体积到底花在了哪里。

例如：

- 哪个第三方库最重
- 哪些模块重复出现
- 哪个页面 chunk 明显偏大

这些问题如果不先搞清楚，后面的优化很容易瞎忙。

## Vue 项目里最常见的膨胀点

实际项目里包体积变大，常见原因通常包括：

- 引了过重的组件库
- 路由没有按需拆分
- 富文本或图表类库直接进了主包
- 工具库按整个包引入

这类问题很多并不是代码写错，而是结构没有控制住。

## 写在最后

Webpack Bundle Analyzer 最大的作用，是把“感觉有点大”变成“我知道大在哪里”。

前端优化最怕靠直觉。先把体积分布看清楚，再决定删什么、拆什么、延后加载什么，效率会高很多。


Vue 项目包太大时先别慌：Webpack Bundle Analyzer 到底能帮你看清什么


做表单页面时，很多团队都会很快开始抽输入组件。

这方向没问题。文本框、下拉框、日期选择器这些东西确实值得复用。问题通常出在复用方式上：刚开始只是想统一样式，后面慢慢开始加校验、加联动、加提示、加布局控制，最后组件越做越胖。

## 先统一外观，再考虑行为

表单组件一开始最值得统一的，通常是这些：

- label 展示
- 错误提示
- 间距
- 基础交互样式

如果一上来就把业务校验、字段联动、接口逻辑一起塞进去，组件很快就会失去边界。

## props 多到一定程度，复用就开始走样

一旦出现下面这种趋势，就要警觉了：

- `showError`
- `validateOnBlur`
- `customRule`
- `layoutMode`
- `extraTip`
- `beforeChange`

参数越来越多，看起来像组件更通用了，实际上往往说明它开始同时服务太多场景。

## 写在最后

Vue 表单组件做得稳不稳，关键不在于抽没抽，而在于抽象边界是不是克制。

输入组件最适合统一的是外观和基础交互，不该顺手把整个业务逻辑也吞进去。复用是为了减轻页面压力，不是为了再造一个更复杂的配置层。


Vue 表单组件拆分经验：可复用输入框不是把所有 props 都塞进去


Vue 的过渡系统很好上手，所以很多人第一次接触时都会很兴奋，觉得页面终于能“动起来”了。

问题在于，动画一旦脱离交互目的，就很容易从“有帮助”变成“看起来有点多余”。

## 过渡最重要的作用是补信息

好的过渡通常不是为了炫，而是为了告诉用户：

- 这个元素刚出现
- 这个区域已经切换
- 这个操作正在完成

当动画能补足状态变化时，它就有价值。

## Vue 让这件事变简单了

`<transition>` 把进入和离开的状态整理得比较清楚，让你不需要手写太多切换细节。

这对页面交互来说很实用，尤其是：

- 弹窗
- 下拉层
- 列表切换
- 提示信息

## 但动画不是加得越多越好

如果每个区域都在动，用户的注意力反而会被打散。

而且某些动画如果处理不好，还会带来：

- 掉帧
- 卡顿
- 响应变慢

所以比起“哪里都能动一下”，更重要的是先问一句：这个动画到底在帮助什么。

## 写在最后

Vue 的过渡能力很方便，但真正决定体验的不是 API，而是你有没有把动画放在合适的位置。

先服务交互，再追求效果，页面看起来会自然很多。


Vue 过渡动画怎么用才不显得多余：先服务交互，再谈效果


刚开始用 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 路径别名看起来只是一个小配置，但它会持续改善项目的可读性。

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