
我第一次觉得 `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 中的乐观更新：我是在一次评论交互改造里真正把它用明白的


不少 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 写到底


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路由传参全攻略


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

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

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

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

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

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

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

这时常见情况是：

- 新场景需要一个额外参数
- 旧交互要兼容新的样式
- 一个组件同时承担多个职责
- 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`

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

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

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

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

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

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

## 一个简单的判断标准

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

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

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

## 写在最后

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

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

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

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