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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

更适合懒加载的通常是：

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

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

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

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

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

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

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

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

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

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

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

## 分析工具一定要用

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

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

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

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

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

例如：

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

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

## 写在最后

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

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


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


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

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

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

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

## 先区分是哪一种慢

性能问题不是只有一种。

常见至少有四类：

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

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

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

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

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

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

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

例如：

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

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

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

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

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

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

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

页面卡可能来自：

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

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

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

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

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

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

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

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

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

更有效的方式是：

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

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

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

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

例如：

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

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

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

## 一个实用顺序

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

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

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

## 写在最后

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

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


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


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

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

## 从 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 之间的关系理顺，前端资源更新问题就会清晰很多。缓存不是玄学，它说到底是资源管理策略的一部分。


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


Vue 组件写起来很顺，写着写着就容易把很多东西都塞进首屏。

登录页带上富文本编辑器，详情页顺手把图表模块一起注册，设置页里再挂一个体积不小的可视化库。页面一开始看不出问题，项目大了之后，首屏就会越来越重。

异步组件的价值，就是把这些低频内容往后放。

## 什么时候值得异步加载

一个组件如果同时满足下面几条，就很适合异步化：

- 体积不小
- 首屏不一定会看到
- 打开频率不高
- 和核心路径解耦

比如：

- 富文本编辑器
- 大图表
- 高级筛选面板
- 复杂弹窗

## 为什么说它不只是优化技巧

很多人把异步组件理解成“最后再做的性能优化”，其实不是。

当你决定某个模块应该按需加载时，本质上是在表达页面优先级：

- 哪些内容必须先到
- 哪些内容可以后到

这已经不是单纯的打包问题，而是页面结构判断。

## Vue 里的写法很直接

```javascript
components: {
  ChartPanel: () => import('./ChartPanel.vue')
}
```

写法很简单，但背后的意义很明确：这个组件不是页面一启动就必须拿到的。

## 写在最后

页面做大以后，异步组件不该只是“顺手优化一下”。它更像一种节奏控制，让用户先看到真正重要的部分。

在 Vue 项目里，越早建立这种按需加载意识，后面的性能成本越低。


Vue 异步组件值得早点用：页面越大，按需加载越像基本功


Vue 项目包一大，最容易出现的情况就是大家开始凭感觉优化。

有人觉得是图片大，有人怀疑某个 UI 库太重，也有人想先改构建参数。问题是，在没有看到真实体积分布之前，很多判断都只是猜。

这时最值得做的第一步，不是马上删代码，而是先把包看清楚。

## Bundle Analyzer 的价值不在图炫

很多人第一次看到打包分析图，会被那一堆彩色方块吸引。但真正重要的不是图好不好看，而是它让你知道体积到底花在了哪里。

例如：

- 哪个第三方库最重
- 哪些模块重复出现
- 哪个页面 chunk 明显偏大

这些问题如果不先搞清楚，后面的优化很容易瞎忙。

## Vue 项目里最常见的膨胀点

实际项目里包体积变大，常见原因通常包括：

- 引了过重的组件库
- 路由没有按需拆分
- 富文本或图表类库直接进了主包
- 工具库按整个包引入

这类问题很多并不是代码写错，而是结构没有控制住。

## 写在最后

Webpack Bundle Analyzer 最大的作用，是把“感觉有点大”变成“我知道大在哪里”。

前端优化最怕靠直觉。先把体积分布看清楚，再决定删什么、拆什么、延后加载什么，效率会高很多。


Vue 项目包太大时先别慌：Webpack Bundle Analyzer 到底能帮你看清什么


单页应用最容易被忽略的一个问题，就是“什么都先打进来”。

页面少的时候感觉不到，模块一多，首屏体积和初始化时间就会慢慢拉高。用户明明只访问了首页，却被迫把后台设置页、表单向导、图表模块一起下载了。

这就是代码分割存在的理由。

## 代码分割不是高级优化

很多人第一次接触 Webpack 的代码分割，会把它当成“后面再说的优化项”。可对 Vue 这种页面越来越多的单页应用来说，它其实很早就值得考虑。

因为只要页面结构明确、访问路径分层，自然就会想到：

- 首页不该加载后台页代码
- 列表页不该提前加载编辑器
- 低频弹窗没必要跟首屏一起进来

## Vue 路由懒加载就是最常见的切入点

在 Vue 项目里，代码分割最直接的入口通常就是路由级拆分。

```javascript
const UserList = () => import('./views/UserList.vue');
```

这行代码带来的不只是“写法更现代”，而是明确告诉打包器：这部分代码可以等真正访问时再加载。

## Webpack 帮你做的，不只是拆文件

如果没有打包器，你很难优雅地把应用切成多个按需加载的模块。

Webpack 在这里做的是：

- 找出依赖关系
- 生成独立 chunk
- 在运行时按需拉取

你写起来只是一行动态导入，真正复杂的事情都在背后。

## 别为了拆而拆

代码分割当然有好处，但也不是 chunk 越多越好。

拆得太碎，可能带来：

- 请求数变多
- 资源管理复杂
- 公共依赖重复加载判断更难

所以最自然的拆分单位通常还是页面、重模块和低频功能，而不是所有组件都切成一个单独 chunk。

## 写在最后

Webpack 的代码分割真正省下来的，不只是几百 KB 体积，而是用户第一次进入页面时不必要的等待。

Vue 应用做大之后，按需加载几乎不是“可选项”，而是结构设计的一部分。你越早理解这一点，后面的性能成本越低。
