
数组是 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 开发者很自然会拿它和 Vue CLI 比。

这两者表面上都能帮你起一个项目、跑开发环境、做打包，但用起来的感觉并不一样。

## Vue CLI 的强项是成熟

Vue CLI 已经陪很多项目跑了很久。

它的优点很明确：

- 上手路径清楚
- Webpack 能力完整
- 插件和配置体系成熟

如果你在一个比较传统、稳定、历史包袱多的项目里，Vue CLI 仍然很靠谱。

## Vite 的吸引力在体验

Vite 最容易让人有感知的地方，就是开发阶段反馈更快。

你甚至不需要先把一堆原理吃透，光是启动和热更新速度，已经足够让人愿意试。

## 这不是淘汰关系

在 2020 这个时间点，更合理的理解不是“谁干掉谁”，而是：

- Vue CLI 代表成熟的 Webpack 工具链
- Vite 代表一种更轻、更快的新方向

## 写在最后

如果你现在手上项目跑得稳，没必要为了新就立刻重构全部工具链；但如果你正在起新项目，Vite 已经足够值得认真看一眼。

它带来的不是小修小补，而是开发体验上的一条新路。


Vue CLI 和 Vite 该怎么看：一个成熟稳，一个轻快直接


前端页面布局一直是开发中非常重要的一部分。

在很多传统写法里，水平排列、垂直居中、间距分布这些需求都需要绕不少弯。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 布局入门：为什么它会成为前端布局的常用方案


Vue 的过渡系统很好上手，所以很多人第一次接触时都会很兴奋，觉得页面终于能“动起来”了。

问题在于，动画一旦脱离交互目的，就很容易从“有帮助”变成“看起来有点多余”。

## 过渡最重要的作用是补信息

好的过渡通常不是为了炫，而是为了告诉用户：

- 这个元素刚出现
- 这个区域已经切换
- 这个操作正在完成

当动画能补足状态变化时，它就有价值。

## Vue 让这件事变简单了

`<transition>` 把进入和离开的状态整理得比较清楚，让你不需要手写太多切换细节。

这对页面交互来说很实用，尤其是：

- 弹窗
- 下拉层
- 列表切换
- 提示信息

## 但动画不是加得越多越好

如果每个区域都在动，用户的注意力反而会被打散。

而且某些动画如果处理不好，还会带来：

- 掉帧
- 卡顿
- 响应变慢

所以比起“哪里都能动一下”，更重要的是先问一句：这个动画到底在帮助什么。

## 写在最后

Vue 的过渡能力很方便，但真正决定体验的不是 API，而是你有没有把动画放在合适的位置。

先服务交互，再追求效果，页面看起来会自然很多。


Vue 过渡动画怎么用才不显得多余：先服务交互，再谈效果


前端做一些小型功能时，本地存储是一个非常方便的能力。

比如：

- 保存主题设置
- 记录搜索历史
- 缓存草稿内容
- 记录上次浏览状态

这时不少人会第一时间想到 `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 使用笔记：前端本地存储方便，但别把它当数据库


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

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

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

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

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

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

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

这时常见情况是：

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

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

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

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

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

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

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

## 一个简单的判断标准

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

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

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

## 写在最后

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

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

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

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


Vue CLI 和 Vite 该怎么看：一个成熟稳，一个轻快直接

Vue CLI 的强项是成熟

Vite 的吸引力在体验

这不是淘汰关系

写在最后

Vue 过渡动画怎么用才不显得多余：先服务交互，再谈效果

localStorage 使用笔记：前端本地存储方便，但别把它当数据库

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