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

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

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


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


很多前端页面在电脑上看起来没什么问题，一到手机上就开始暴露大量细节问题：

- 字太小
- 按钮难点
- 间距太挤
- 图片被撑破
- 列表层级混乱

这说明移动端适配从来不只是“把宽度缩小”这么简单。

## 移动端和桌面端的核心差异

移动端适配最先要理解的，不是技术，而是使用环境差异。

相比桌面端，移动端通常有这些特点：

- 屏幕更窄
- 触控优先
- 用户注意力更分散
- 可见区域更小

所以同一个布局在电脑上“信息丰富”，在手机上可能就是“阅读压力很大”。

## 响应式不只是改列数

做响应式时，主要做的是：

- 三列变两列
- 两列变一列

这当然是基础，但不够。

移动端适配通常还要考虑：

- 字体大小是否适合阅读
- 行高是否足够舒适
- 点击区域是否足够大
- 信息层级是否需要重组

有些桌面端布局并不是缩小后继续摆放，而是应该重新组织内容顺序。

## 图片和媒体内容一定要自适应

图片是移动端最容易出问题的内容之一。

常见问题包括：

- 图片固定宽高导致溢出
- 多图布局在小屏里过挤
- 大图加载太慢

所以在移动端里，媒体内容通常要优先保证：

- 宽度跟容器走
- 高度按比例自适应
- 不在小屏里强行保留复杂排版

## 触控体验和鼠标体验不一样

桌面端很多交互默认依赖 hover，但移动端没有 hover 这个自然前提。

这意味着：

- 不要把关键信息只放在 hover 态里
- 不要让按钮太小
- 需要给手指点击留出足够空间

在手机上，“能点到”本身就是体验的一部分。

## 文本排版比你想的更重要

移动端不是桌面端缩小版，长文本阅读尤其能体现这一点。

如果标题过大、行距太紧、段落过长，阅读压力会明显增加。

所以移动端里更值得关注：

- 标题层级是否清楚
- 每行文字长度是否合适
- 行距是否足够
- 段间距是否有节奏

## 适配不是一次性工作

页面开发里常见的情况是第一次上线时会对几个常见机型调一下，看起来差不多就结束了。

但真实情况是，不同尺寸、不同系统、不同字体缩放设置都会影响展示效果。

所以适配更像一种持续校正，而不是一次性完成。

## 写在最后

移动端适配真正要解决的，不只是布局能不能缩进去，而是内容在小屏环境下还能不能被舒服地浏览和操作。

把响应式理解成“重新组织体验”，比理解成“改几个宽度断点”更接近实际开发。只要这个认知建立起来，很多适配 decisions 会更自然。


移动端适配入门：做前端页面时，别把响应式理解成只改宽度


Docker 是一个开源的应用容器引擎，让开发者可以打包他们的应用以及依赖包到一个可移植的容器中，然后发布到任何流行的 Linux 机器上。

## Docker 的基本概念

- **镜像（Image）**：Docker 镜像是一个只读的模板，用来创建 Docker 容器。
- **容器（Container）**：Docker 容器是镜像的可运行实例。
- **Dockerfile**：用来构建 Docker 镜像的文本文件，包含了一条条构建镜像所需的指令。

## 创建一个简单的 Dockerfile

以下是一个简单的 Node.js 应用的 Dockerfile：

```dockerfile
FROM node:14
WORKDIR /app
COPY package*.json ./
RUN npm install
COPY . .
EXPOSE 3000
CMD [ "node", "server.js" ]
```

## 构建和运行 Docker 容器

构建镜像：

```bash
docker build -t my-node-app .
```

运行容器：

```bash
docker run -p 3000:3000 my-node-app
```

## Docker Compose

对于多容器应用，可以使用 Docker Compose 来定义和运行多个 Docker 容器。

```yaml
version: '3'
services:
  web:
    build: .
    ports:
      - "3000:3000"
  db:
    image: mongo
    volumes:
      - ./data:/data/db
```

Docker 使得应用的部署和扩展变得更加简单和一致。继续学习更多关于 Docker 网络、数据卷、以及如何在生产环境中使用 Docker 的知识。

Docker 入门：容器化你的应用


前端项目一旦进入多人协作阶段，很多问题看起来像是 Git 问题，实际上往往是协作习惯问题。

例如：

- 提交信息看不懂
- 一个分支改动太大
- 冲突频繁
- 回滚困难

Git 本身并没有做错什么，问题通常出在团队怎么使用它。

## 提交粒度太大，是很多协作问题的起点

很多人习惯攒一堆改动再一起提交，结果一个 commit 里同时包含：

- 新功能
- 样式调整
- 文案修改
- 顺手重构
- 调试代码删除

这样的提交在自己脑子里可能还是清楚的，但对其他协作者来说，可读性会非常差。

更合理的方式通常是按“一个明确意图”提交。

## 提交信息是给后来的人看的

很多提交信息写成：

- `fix`
- `update`
- `修改一下`

这类信息当下可能图省事，但后面排查问题、查历史时几乎没有帮助。

好的提交信息不需要写成长文，但至少应该表达：

- 改了什么
- 为什么改

## 分支不要活得太久

一个功能分支拖得越久，后面越容易：

- 与主干偏离
- 冲突增多
- 难以 review
- 难以回滚

所以长期看，保持分支生命周期适中，比“一个大分支搞完整个版本”更稳。

## 冲突并不可怕，可怕的是不理解改动就解决

很多人处理冲突时，只想尽快让它过去，结果用的是“谁的代码看起来顺眼就保留谁”。

这在简单文件上可能没问题，但如果涉及逻辑变更，很容易把一部分正确改动无意中覆盖掉。

处理冲突时，还有一个更关键的问题是先理解两边各自改了什么。

## 前端项目尤其要注意产物文件

前端项目里常见一些自动生成内容，例如：

- 构建产物
- 锁文件
- 搜索索引
- 站点地图

这些文件是否应该进版本库，什么时候更新，团队最好有一致规则。否则很容易出现无意义冲突或脏提交。

## 写在最后

Git 协作真正决定效率的，往往不是命令熟不熟，而是团队有没有形成清晰的提交和分支习惯。

只要提交粒度更清楚、分支不要拖太久、冲突时先理解再解决，很多看起来麻烦的协作问题都会少很多。


前端团队协作中的 Git 习惯：很多低级问题其实和工具本身无关

在进行博客设计时，确保在移动端和电脑端都拥有良好的阅读体验是非常重要的。借助 Tailwind CSS，我们可以轻松实现这一目标。本文将为你介绍如何使用 Tailwind CSS 优化博客的字体设计，并确保在不同设备上获得一致的用户体验。

### 1. **基础字体大小设计**

在 Tailwind CSS 中，你可以通过 `text-base`、`text-lg` 等类来轻松设置不同设备的字体大小。以下是移动端和电脑端的基础字体大小设计建议：

- **移动端：**
  - 正文：`text-base`（默认是 16px）
  - 一级标题：`text-2xl`（默认是 24px）
  - 二级标题：`text-xl`（默认是 20px）
  - 三级标题：`text-lg`（默认是 18px）
  - 辅助文字：`text-sm`（默认是 14px）

- **电脑端：**
  - 正文：`lg:text-lg`（18px）
  - 一级标题：`lg:text-4xl`（36px）
  - 二级标题：`lg:text-2xl`（24px）
  - 三级标题：`lg:text-xl`（20px）
  - 辅助文字：`lg:text-base`（16px）

通过这种方式，你可以确保博客在不同设备上都拥有适合的阅读体验。

### 2. **响应式设计**

借助 Tailwind CSS 的响应式工具，你可以为不同的设备屏幕设置不同的样式。在 Tailwind 中，默认提供了几个断点：
- `sm`：适用于 640px 及以下的设备（移动端）
- `md`：适用于 768px 及以下的设备（平板）
- `lg`：适用于 1024px 及以上的设备（电脑端）
- `xl`：适用于 1280px 及以上的设备（大屏幕）

例如，通过以下代码，你可以为移动端和电脑端分别设置不同的字体大小：

```html

<div class="prose">
  <h1 class="text-2xl lg:text-4xl">一级标题</h1>
  <h2 class="text-xl lg:text-2xl">二级标题</h2>
  <p class="text-base lg:text-lg">这是正文内容。</p>
  <span class="text-sm lg:text-base">辅助文字</span>
</div>
```

在这个示例中，移动端会使用较小的字体，而在较大的屏幕上，字体会自动变大，以提升可读性。

### 3. **自定义行距**

在长篇阅读内容中，行距的调整同样非常重要。Tailwind CSS 提供了 `leading` 类来控制行距。例如：
```html
<p class="text-base leading-7 lg:text-lg lg:leading-8">
  这是适合博客的正文文字。
</p>
```
- `leading-7`：表示行距为字体大小的 1.75 倍，适合长时间阅读。
- `lg:leading-8`：确保在大屏设备上有更舒适的阅读体验。

### 4. **图片的自适应设计**

除了文字，图片等媒体内容也需要适应不同设备。你可以通过 `w-full` 和 `h-auto` 类来使图片根据容器自动调整大小：
```html
<img src="image.jpg" class="w-full h-auto" alt="Responsive image">
```

这确保了图片能够在移动端和电脑端都以适当的比例显示，保持良好的视觉效果。

### 5. **示例代码总结**

为了更好地理解，我们可以通过以下完整的代码示例来展示如何使用 Tailwind CSS 实现响应式的博客字体设计：
```html
<div class="prose max-w-none">
  <h1 class="text-2xl lg:text-4xl leading-tight">博客标题</h1>
  <h2 class="text-xl lg:text-2xl leading-snug mt-4">二级标题</h2>
  <p class="text-base lg:text-lg leading-7 lg:leading-8 mt-2">
    这是文章的正文，适合长时间阅读，行距设置为 1.75 倍，确保内容清晰易读。
  </p>
  <span class="text-sm lg:text-base text-gray-500 mt-1 block">日期：2024-09-04</span>
</div>
```

### 6. **结论**

借助 Tailwind CSS 的灵活性，你可以通过响应式工具轻松调整博客在不同设备上的字体大小、行距和媒体展示效果。无论是移动端还是电脑端，你的博客都将拥有良好的视觉层次感和阅读体验。

---

通过以上方案，你可以确保博客在各种设备上都有一致的视觉效果和用户体验。这种基于 Tailwind CSS 的解决方案，不仅简洁易用，还能够根据需要快速调整和优化布局。

使用 Tailwind CSS 实现博客在移动端和电脑端的字体适配


前端开发早期，很多代码都是直接挂在全局作用域里的。

页面功能少的时候问题不明显，但随着项目变大，很快就会出现：

- 变量冲突
- 依赖关系混乱
- 文件加载顺序敏感
- 代码难拆难测

模块化正是为了解决这些问题而逐渐成为前端工程基础能力的。

## 模块化到底解决了什么

可以把模块化理解成：让代码有明确边界。

一个模块通常会说明：

- 它暴露什么
- 它依赖什么
- 它内部细节不希望外界直接碰什么

这样做的最大价值，不是语法更高级，而是系统更容易组织。

## 没有模块边界时会发生什么

如果所有变量和函数都散落在全局环境里，项目一大就很难管理。

常见问题包括：

- 同名函数被覆盖
- 某个文件必须先加载
- 调整一处代码影响未知区域

这些问题本质上都是边界缺失带来的。

## 模块化让依赖关系变得显式

以前一个函数能不能用，可能取决于某个文件是否先被引入；模块化之后，依赖可以直接通过导入关系表达出来。

这会带来很多工程收益：

- 更容易理解代码结构
- 更容易拆分文件
- 更容易做按需加载
- 更容易测试

## 模块拆分也不是越细越好

模块化的目标是清晰，不是把文件切得无限碎。

如果一个功能被拆成大量细小文件，但每个文件都彼此强依赖，阅读成本反而会上升。

所以模块拆分还有一个更关键的问题是按职责，而不是按行数。

## 模块边界会直接影响维护体验

一个边界清楚的模块，通常更容易做到：

- 只改局部
- 独立测试
- 替换实现
- 复用逻辑

反过来，如果模块之间相互穿透，虽然代码形式上用了 import/export，实际维护体验还是很差。

## 写在最后

JavaScript 模块化看起来像语法层能力，但它真正改变的是前端项目的组织方式。

随着项目越来越复杂，模块边界会越来越重要。理解模块化，不只是会写导入导出，而是开始学会让代码结构更清楚、更稳定、更容易协作。
