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

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

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

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

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

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

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

这时常见情况是：

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

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

## 写在最后

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

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