
前端开发里，事件是最基础也最常见的能力之一。

点击按钮、输入内容、提交表单、滚动页面，这些交互的背后其实都离不开事件机制。

实际开发中大家会直接使用事件，但一旦遇到下面这些情况，就会发现自己其实并没有真正理解它：

- 为什么点击子元素时父元素的事件也触发了
- 为什么有些事件监听加在父级上也能生效
- 为什么 `stopPropagation` 有时能解决问题，有时又不够

这些问题都和 DOM 事件机制有关。

## 什么是事件传播

当你点击一个页面元素时，浏览器并不是只把这次点击交给当前元素处理。

它会沿着 DOM 树进行一轮传播，这个传播过程通常分成三个阶段：

1. 捕获阶段
2. 目标阶段
3. 冒泡阶段

简单理解就是，事件会先从外往里走，再从里往外走。

## 冒泡为什么这么重要

在日常开发中，最常遇到的通常是冒泡。

例如：

```javascript
parent.addEventListener('click', () => {
  console.log('parent clicked');
});

child.addEventListener('click', () => {
  console.log('child clicked');
});
```

当点击子元素时，通常会先触发子元素，再触发父元素。这就是冒泡。

理解这一点很重要，因为很多交互问题其实不是“事件绑错了”，而是没有意识到事件还会继续向上传播。

## 捕获阶段什么时候会用到

捕获阶段在业务开发里不像冒泡那样常见，但它确实存在。

如果你通过第三个参数或配置项启用捕获监听，事件会先在外层元素触发，再到目标元素。

```javascript
parent.addEventListener(
  'click',
  () => {
    console.log('capture');
  },
  true
);
```

大多数场景下你不一定主动用它，但知道它的存在，能帮助你更好理解事件执行顺序。

## 什么是事件委托

事件委托是前端里非常实用的一种技巧。

它的思路是：不把事件直接绑定在每个子元素上，而是绑定在它们的父元素上，再通过事件对象判断具体是哪个子元素触发的。

例如列表：

```javascript
list.addEventListener('click', (event) => {
  if (event.target.matches('li')) {
    console.log('clicked item');
  }
});
```

这样做的好处很明显：

- 减少重复绑定
- 动态新增元素也能响应
- 结构更集中

## stopPropagation 是做什么的

如果你不希望事件继续向上传播，可以调用：

```javascript
event.stopPropagation();
```

这通常用于阻止父级事件误触发。

例如一个卡片整体可点击，卡片内部又有删除按钮，这时删除按钮点击后如果不阻止传播，卡片点击逻辑也可能被触发。

## 事件对象里最常用的几个属性

日常开发中比较常见的有：

- `target`
- `currentTarget`
- `preventDefault`

其中最容易混的是：

- `event.target` 表示实际触发事件的元素
- `event.currentTarget` 表示当前正在处理事件的元素

理解这两个区别，对写事件委托特别重要。

## 默认行为和传播不是一回事

很多人刚开始会把这两个概念混在一起。

例如点击链接时：

- 阻止跳转，要用 `preventDefault`
- 阻止事件继续向父级传播，要用 `stopPropagation`

它们解决的是两类不同问题。

## 写在最后

DOM 事件机制最重要的，不是死记捕获和冒泡的定义，而是理解事件在页面中的传播路径。

只要把事件传播、事件委托、默认行为和当前目标这几个概念理顺，很多日常交互问题都会更容易分析。事件机制看起来基础，但它几乎贯穿了整个前端交互开发。


DOM 事件机制入门：捕获、冒泡和事件委托到底该怎么理解


前端开发离不开请求。

页面展示数据、提交表单、刷新列表、加载详情，这些动作几乎都要和服务端通信。

如果把时间往前拉，大家最熟悉的方式可能是 Ajax；再往后，Fetch 逐渐成为更常见的写法。它们都能完成请求，但带来的开发体验并不完全一样。

## Ajax 解决了什么问题

Ajax 最重要的价值，是让页面不必整页刷新也能和服务端交换数据。

这在早期前端开发里是一次很大的改变，因为它让页面开始具备更强的交互性和动态性。

大家最熟悉的实现通常是 `XMLHttpRequest`。

```javascript
const xhr = new XMLHttpRequest();
xhr.open('GET', '/api/list');
xhr.onreadystatechange = function () {
  if (xhr.readyState === 4 && xhr.status === 200) {
    console.log(xhr.responseText);
  }
};
xhr.send();
```

这个写法并不是不能用，但确实比较底层。

## Fetch 为什么更容易被接受

Fetch 更贴近现代 JavaScript 的编码方式。

它的 API 更简洁，也更容易和 Promise、`async/await` 组合。

```javascript
async function loadData() {
  const response = await fetch('/api/list');
  const data = await response.json();
  console.log(data);
}
```

相比 `XMLHttpRequest`，这种写法的优势主要体现在：

- 更容易阅读
- 更容易封装
- 更适合现代异步流程

## 两者的差异不只是“新旧”

不少人会简单理解成“Fetch 就是更现代的 Ajax”，但更准确地说，它们代表了两种不同层级的开发体验。

`XMLHttpRequest` 更像底层接口，你需要自己处理很多状态变化。

Fetch 则更像一个围绕请求流程设计得更现代的抽象。

## Fetch 使用时也有需要注意的地方

虽然 Fetch 更简洁，但它也有一些容易踩坑的点。

例如很多人第一次用时会以为：

- 请求失败就会进入 `catch`

实际上不是所有 HTTP 错误状态都会自动抛异常。比如返回 404、500，Fetch 依然可能算“成功收到响应”，只是 `response.ok` 为 `false`。

所以通常还要自己判断：

```javascript
const response = await fetch('/api/list');

if (!response.ok) {
  throw new Error('request failed');
}
```

## 请求封装的重要性

无论使用 Ajax 还是 Fetch，真正影响项目维护体验的，往往不是底层 API 本身，而是你有没有做好请求层封装。

例如：

- base URL
- 通用 headers
- 错误处理
- token 注入
- 超时控制

如果这些都散落在页面里，请求方式再现代，项目后期也会很难维护。

## 从工具切换到抽象思维

很多技术演进表面看起来只是 API 更新，实际上还有一个更关键的问题是推动开发者思维变化。

从 Ajax 到 Fetch，更有价值的变化不只是代码少了几行，而是前端异步请求开始更自然地融入整体工程结构。

## 写在最后

从 Ajax 到 Fetch，是前端请求方式一次很自然的演进。前者解决了页面局部更新的问题，后者则让请求代码更容易和现代 JavaScript 编程方式结合。

工具当然会变化，但真正值得沉淀的是请求层的组织方式。只要这层思路清楚，用什么接口都不会太乱。


从 Ajax 到 Fetch：前端请求方式的演进到底带来了什么


刚开始做前端时，不少人第一次接触“语义化 HTML”时，会把它理解成一个偏理论的问题。

因为在页面开发里常见的情况是里，似乎用一堆 `div` 也能把界面搭出来，看起来并不影响功能。

但只要项目稍微复杂一点，就会发现结构表达清楚和结构表达混乱，长期维护体验差别非常大。

## 什么叫语义化

语义化的核心不是标签多高级，而是让标签表达内容本身的含义。

例如：

- 文章用 `article`
- 页头用 `header`
- 导航用 `nav`
- 主要内容区用 `main`
- 按钮用 `button`

这样做的价值，是让页面结构更容易被人和工具理解。

## 为什么不能什么都用 div

`div` 本身没有错，它是一个通用容器。

问题在于，如果一个页面几乎所有地方都靠 `div` 组织，那结构信息就被大量丢失了。

你虽然看得见页面长什么样，但很难从 DOM 结构里直接判断：

- 哪里是导航
- 哪里是正文
- 哪里是列表
- 哪里是按钮

这会直接影响后续开发体验。

## 语义化对维护有什么帮助

当页面结构清楚时，后来的人会更容易理解代码。

例如看到：

```html
<article>
  <header>...</header>
  <section>...</section>
</article>
```

比起一串嵌套 `div`，它表达的信息更多，也更接近页面真实结构。

在多人协作和长期维护里，这种清晰度非常重要。

## 语义化和可访问性有很强关系

很多语义标签不只是“长得更好看”，它们还会影响辅助技术如何理解页面。

例如：

- 读屏工具可以更清楚地识别结构
- 表单控件能获得更合理的默认语义
- 按钮和链接的行为边界更明确

这就是为什么语义化往往和可访问性一起被讨论。

## 按钮和链接尤其容易用错

这是最常见的问题之一。

页面开发里常见的情况是会把一个可点击的 `div` 当按钮，也会把一个只执行动作的元素写成链接。这样虽然视觉上可行，但语义上是混乱的。

一个比较简单的原则是：

- 跳转用链接
- 操作用按钮

这个边界如果守住，很多交互和可访问性问题都会减少。

## 语义化不会让你写得更慢

很多人担心语义化会增加开发成本，但实际上大部分时候只是习惯问题。

只要你在搭结构时多想一步“这个区域本来是什么”，写出来的代码通常不会更复杂，反而更稳定。

## 写在最后

语义化 HTML 的价值，不在于它是一个标准答案，而在于它让页面结构表达得更清楚。

当你开始把 HTML 当作“内容结构语言”，而不是“页面摆放容器”，代码的可维护性、可访问性和整体质量通常都会更进一步。它并不是额外要求，而是 Web 基础的一部分。


语义化 HTML 为什么重要：它不只是面试题，而是页面质量的基础


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

比如：

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

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


前端开发近几年的编码体验变化，很大一部分都来自 JavaScript 语言本身的演进。

ES6 之后，很多过去写起来很别扭的代码，开始变得更自然。它的价值不只是语法更好看，而是让代码表达能力更强了。

## let 和 const 让变量语义更清楚

以前大家主要使用 `var`，它在作用域和提升上的行为比较容易引发困惑。

`let` 和 `const` 的出现，让变量声明的意图更明确：

- `let` 表示后续可能修改
- `const` 表示引用不再重新赋值

这能显著减少一些低级错误。

## 模板字符串让拼接更自然

过去拼接字符串时，代码经常会变得很碎：

```javascript
var text = 'Hello, ' + name + '!';
```

模板字符串让这种表达更直观：

```javascript
const text = `Hello, ${name}!`;
```

这看起来只是语法糖，但在构造复杂文本时体验差别非常明显。

## 解构赋值提升了可读性

对象和数组解构是 ES6 里非常实用的能力。

例如：

```javascript
const user = { name: 'Tom', age: 18 };
const { name, age } = user;
```

它的价值在于，把“我要用哪些字段”直接写在赋值处，让代码更聚焦。

## 箭头函数简化了函数表达

箭头函数最大的好处不只是短，而是让很多短小逻辑写起来更自然。

例如：

```javascript
const list = items.map(item => item.name);
```

这种写法在数组操作、回调和函数组合里非常常见，也大幅提升了函数式写法的可读性。

## Promise 改变了异步代码结构

虽然异步问题并不是 ES6 才出现，但 Promise 让异步流程开始有了更统一的表达方式。

相比层层嵌套的回调，它至少让流程关系更清楚。

这也为后来的 `async/await` 铺平了道路。

## 模块化能力意义很大

ES6 模块并不只是语法更新，它实际上推动了前端工程结构进一步标准化。

通过 `import` 和 `export`，代码之间的依赖关系变得更清楚，也更适合现代构建工具处理。

## 新特性的价值不在“高级”，而在“更稳定”

很多人学习 ES6 时会关注“有哪些新语法”，但真正更重要的问题其实是：

这些能力是不是让代码更容易读、写、改和协作。

从这个角度看，不少 ES6 特性之所以重要，不是因为它们炫，而是因为它们让前端开发更成熟了。

## 写在最后

ES6 对前端开发的影响，远不只是多了几种新写法。它真正改变的是代码组织方式和表达效率。

当你回头看这些常用能力，会发现它们已经逐渐成为现代前端开发的基础配置。好的语言特性不是让代码显得更高级，而是让日常开发更顺手、更稳定。
