
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 单文件组件最大的优势，是让组件边界更完整；但如果把太多职责硬塞进一个文件，这个优势也会被自己抵消掉。

组件写久了以后，真正拉开差距的不是格式，而是组织节奏。
