JavaScript 的 Error 对象

发表于 2025-03-24

理解 JavaScript 的 Error 对象：超越 `.stack` 的全面解析

在日常的 JavaScript 开发中，处理错误就像处理 bug 一样是家常便饭。我们最熟悉的可能就是 Error 对象的 .message 属性了——它用最直白的话告诉我们出了什么问题。不过说实话，一个完整的 Error 对象包含的信息可比这丰富多了。除了常用的 .message，还有 .stack、.name、.cause 等属性，如果你能掌握这些关键属性，写出来的代码会更健壮，调试起来也会轻松不少。

`.message`：错误信息的简明扼要

.message 属性是个字符串，它用最直白的话告诉你”到底出了什么问题”。这可能是你在 catch 块里最先看到的东西。

当错误发生时，message 就像是错误的”自我介绍”。比如一个 TypeError 的 message 可能会说 "Cannot read properties of undefined"，一看就知道是在访问 undefined 的属性。

try {
  JSON.parse('invalid json');
} catch (error) {
  // .message 提供了错误的简短描述
  console.log(error.message); // 输出: "Unexpected token 'i', "invalid json" is not valid JSON"
}

`.name`：错误类型的身份证

.name 属性是个字符串，标识了错误的具体类型。JavaScript 内置了很多错误类型，像 TypeError（类型错误）、ReferenceError（引用错误）、SyntaxError（语法错误）等等。

通过 .name，我们可以精确判断错误类型，而不用去猜测或者解析错误消息。这样就能针对不同类型的错误做不同的处理，让代码更可控。

try {
  throw new TypeError('Invalid type');
} catch (error) {
  // 根据错误类型执行不同的处理逻辑
  if (error.name === 'TypeError') {
    console.log('这是类型错误，检查一下数据类型吧！');
  } else if (error.name === 'ReferenceError') {
    console.log('引用了不存在的变量');
  } else {
    console.log('其他类型的错误');
  }
}

`.stack`：错误的”犯罪现场”重现

.stack 属性提供了调用堆栈跟踪，记录了导致错误发生的完整调用链路。这绝对是调试时最有用的信息，能帮你快速定位问题根源。

理解调用堆栈的工作原理

JavaScript 的函数调用遵循”后进先出”（Last-In, First-Out）的规则，由**调用堆栈（Call Stack）**管理：

当函数被调用时，会被**压入（push）**到堆栈顶部
当函数执行完毕返回时，会从堆栈中弹出（pop）

当 Error 对象被创建时，它会”拍快照”——捕获并保存当前调用堆栈的状态。

`.stack` 的输出格式

.stack 返回的是个字符串，虽然格式没有统一标准，但主流浏览器和 Node.js 的格式都很相似：

第一行：错误信息（类型 + 描述）
后续行：调用帧（Call Frames），按时间倒序排列
- 最新的调用在最上面
- 每个调用帧包含：函数名、文件名、行号和列号

实际案例分析

假设你有个多文件的项目，调用链是：app.js → api.js → data-processor.js

app.js

const { fetchDataAndProcess } = require('./api.js');

try {
  fetchDataAndProcess();
} catch (e) {
  console.error(e.stack);
}

api.js

const { processData } = require('./data-processor.js');

function fetchDataAndProcess() {
  const data = null; // 模拟获取数据失败
  processData(data); // 传入 null，会引发错误
}

module.exports = { fetchDataAndProcess };

data-processor.js

function processData(data) {
  return data.map(item => item.name); // data 是 null，这里会抛出 TypeError
}

module.exports = { processData };

运行后你会看到类似这样的堆栈跟踪：

TypeError: Cannot read properties of null (reading 'map')
    at processData (data-processor.js:2:16)
    at fetchDataAndProcess (api.js:6:3)
    at Object.<anonymous> (app.js:4:3)
    at Module._compile (node:internal/modules/cjs/loader:1254:14)
    at Module._extensions..js (node:internal/modules/cjs/loader:1308:10)
    ...

从这个 stack 信息可以清楚地看到：

错误发生在 data-processor.js 第 2 行的 processData 函数
该函数被 api.js 的 fetchDataAndProcess 调用
fetchDataAndProcess 又被 app.js 调用

这样你就能准确定位到 api.js 中传入 null 的那一行代码了。

`.cause`：错误的”前世今生”

.cause 是一个相对新的属性，它让你可以把多个错误”串联”起来。当你捕获到底层错误，但想抛出一个更有业务意义的新错误时，.cause 就能派上用场了。

这在复杂应用中特别有用，因为它能保持错误的完整上下文，让你沿着错误的”因果链”追溯到最初的问题。

async function loadConfig(path) {
  try {
    // 底层文件读取操作
    const content = await fs.readFile(path, 'utf8');
    return JSON.parse(content);
  } catch (originalError) {
    // 抛出更有意义的业务错误，但保留原始错误信息
    throw new Error(`配置文件加载失败: ${path}`, { 
      cause: originalError 
    });
  }
}

try {
  await loadConfig('/config/app.json');
} catch (err) {
  console.log(err.message); // "配置文件加载失败: /config/app.json"
  
  if (err.cause) {
    console.log('根本原因:', err.cause.message); // 原始的文件系统错误
  }
}

Mustache 语法：那些双大括号的故事

发表于 2025-03-18

Mustache 语法：那些双大括号的故事

你肯定见过 Vue 和微信小程序里的这种写法：{{name}}。这玩意儿叫 Mustache 语法，也有人叫它”胡子语法”。为啥叫胡子？因为 {{ }} 看起来像胡子呗 😄

这东西是从哪来的？

起源故事

其实这个语法并不是 Vue 或者小程序发明的，它早就存在了。最早来自一个叫 Mustache 的模板引擎，这货的设计理念特别简单粗暴：模板就是模板，别掺和业务逻辑。

你想想，以前我们写模板的时候，经常会在里面塞各种 if、for，结果模板越写越复杂，后来维护起来要人命。Mustache 就说：不行，你们这样搞不对，模板就应该纯粹一点，只管展示数据就行了。

设计思路很朴素

Mustache 的几个核心想法：

简单到没朋友：看到 {{variable}} 你就知道这是个变量，小学生都能看懂
哪种语言都能用：不管你用 JavaScript、Python 还是 Ruby，都有对应的实现
强制分离关注点：复杂逻辑你放到别的地方去处理，模板就负责把数据展示出来

说白了，就是让你写代码的时候不要什么都往一个地方塞。

Mustache 到底有啥特点？

真的没有逻辑

你在 Mustache 模板里找不到任何 if、else、for 这种东西。所有的判断、循环、计算，统统在模板外面搞定，然后把最终结果扔给模板去渲染。

刚开始可能觉得这样很蛋疼，但用久了你就会发现，这样做让代码清爽了很多。

双大括号就是招牌

{{ }} 就是 Mustache 的标志性语法，简单直接。你要展示个变量？{{name}}。要访问对象的属性？{{user.age}}。就是这么朴实无华。

支持嵌套访问

虽然简单，但该有的功能还是有的。比如你可以这样访问深层嵌套的数据：{{user.profile.contact.email}}，一路点下去就完事了。

来个实际例子

假设你有这样的数据：

{
  "name": "张三",
  "age": 25,
  "city": "北京",
  "job": "前端开发"
}

模板长这样：

1 2	嗨，我是 {{name}}，今年 {{age}} 岁。目前在 {{city}} 做 {{job}}，欢迎一起聊技术！

最后渲染出来就是：

1 2	嗨，我是张三，今年 25 岁。目前在北京做前端开发，欢迎一起聊技术！

是不是很直观？

稍微复杂点的例子

如果数据结构复杂一些：

{
  "developer": {
    "info": {
      "name": "李四",
      "level": "高级"
    },
    "skills": {
      "frontend": "Vue.js",
      "backend": "Node.js"
    }
  }
}

模板可以这么写：

1 2	开发者：{{developer.info.name}}（{{developer.info.level}}）技术栈：前端用 {{developer.skills.frontend}}，后端用 {{developer.skills.backend}}

为什么 Vue 和小程序都用它？

一看就懂：{{data}} 这种写法，不管是新手还是老鸟，一眼就能看出来这里要放数据
学习成本低：不需要记什么复杂的语法，会打字就会用
强制你写好代码：因为模板里不能写逻辑，你就被逼着把数据处理的逻辑写到该写的地方去
架构很清爽：视图是视图，逻辑是逻辑，各管各的，这样代码维护起来不会让人想哭

使用 interface 优雅地扩展第三方库类型

发表于 2025-03-07

在现代前端开发中，使用第三方库是常见的开发模式。虽然大多数场景下直接使用第三方库的默认功能就能满足大部分场景，但在某些业务场景中，我们需要对第三方库进行深度定制/扩展，这往往涉及到扩展第三方库的类型定义。

问题背景

传统包装方案的局限性

对于可以直接调用的函数，我们通常会选择包装函数的方式：

1
2
3

export const axiosRequest = (url: string, config: AxiosRequestConfig & { showLoading?: boolean }) => {
  return axios.request({url, ...config})
}

存在的核心问题

这种包装方式虽然能够解决直接调用的类型问题，但存在以下局限性：

类型覆盖范围有限：只能保证包装函数 axiosRequest 的参数类型正确
生态系统不一致：拦截器等使用 AxiosRequestConfig 的场景仍然是原始类型
开发体验受损：无法在整个 axios 生态中享受 TypeScript 的类型检查和自动补全

例如，在拦截器中仍然无法获得自定义属性的类型支持：

// 这里的 config.showLoading 没有类型提示
httpClient.interceptors.request.use((config: AxiosRequestConfig) => {
  if (config.showLoading) { // TypeScript 报错：属性不存在
    // 处理逻辑
  }
  return config;
});

TypeScript 模块扩展方案

核心语法：`declare module` + `interface`

TypeScript 提供了强大的模块扩展能力，通过 declare module 语法结合 interface 重新声明，可以扩展现有模块的类型定义：

import type { AxiosInstance } from 'axios'

declare module 'axios' {
  interface AxiosRequestConfig {
    showLoading?: boolean
  }
}

技术原理解析

这个解决方案基于 TypeScript 的两个关键特性：

1. 模块扩展机制（Module Augmentation）

declare module 语法允许我们扩展现有模块的类型定义。通过指定模块名称，我们可以在该模块的命名空间内添加或修改类型声明。

2. `interface` 合并机制（Declaration Merging）

TypeScript 允许同名的 interface 进行自动合并。当我们重新声明 AxiosRequestConfig 接口时，TypeScript 会将新属性与原有接口定义合并，而不是覆盖，这样整个应用中所有使用 AxiosRequestConfig 的地方都获得扩展后的类型定义。

实际应用示例

基础 API 调用

扩展后，可以直接在 axios 的所有 API 中使用新增属性：

// GET 请求
axios.get('/api/users', {
  showLoading: true
});

// POST 请求
axios.post('/api/users', userData, {
  showLoading: false
});

// 通用 request 方法
axios.request({
  url: '/api/data',
  method: 'POST',
  showLoading: true
});

请求拦截器应用

在请求拦截器中，扩展的类型定义同样生效：

httpClient.interceptors.request.use(
  (config: AxiosRequestConfig) => {
    // 现在可以安全地访问 showLoading 属性
    if (config.showLoading !== false) {
      // 显示加载指示器
      LoadingService.show();
    }
    
    return config;
  },
  (error: AxiosError) => {
    return Promise.reject(error);
  }
);

响应拦截器处理

响应拦截器中也能完整支持扩展的类型：

httpClient.interceptors.response.use(
  (response) => {
    // 根据请求配置决定是否隐藏加载状态
    if (response.config.showLoading !== false) {
      LoadingService.hide();
    }
    return response;
  },
  (error: AxiosError) => {
    // 错误情况下也要处理加载状态
    if (error.config?.showLoading !== false) {
      LoadingService.hide();
    }
    return Promise.reject(error);
  }
);

注意事项

1. 全局影响范围

模块扩展会影响整个项目中对该模块的使用，需要确保团队成员了解扩展的类型定义。

2. 版本兼容性管理

定期检查第三方库版本更新可能带来的类型冲突
建议将类型扩展文件单独管理，便于维护

3. 命名规范

为扩展属性建立清晰的命名规范，避免与未来版本的官方属性产生冲突，比如命名设置特殊标识。

pnpm shamefully-hoist=true

发表于 2024-12-07

在 JavaScript 包管理器的演进历程中，shamefully-hoist=true 是一个颇具争议的配置项。这个配置选项的存在，直接挑战了 pnpm 的核心设计理念，迫使其放弃严格、高效的依赖管理模式，转而采用一种更为传统但存在潜在风险的扁平化结构。

传统包管理器的扁平化策略及其弊端

扁平化机制的发展背景

为了理解 shamefully-hoist=true 的作用，我们必须首先回顾 npm（v3+）和 Yarn（v1）的工作机制。这些传统包管理器采用**扁平化（Flattening）**的 node_modules 结构，这一设计主要为了解决两个关键问题：

减少依赖重复：避免同一个包的多个版本被重复安装
解决路径长度限制：特别是在 Windows 系统上避免文件路径过长的问题

依赖提升机制

传统包管理器会将项目的所有直接依赖及其传递依赖都**提升（Hoisting）**到 node_modules 的顶层目录：

node_modules/
├── lodash/                 # 直接依赖
├── express/                # 直接依赖
├── debug/                  # express 的传递依赖被提升到顶层
├── accepts/                # express 的传递依赖被提升到顶层
└── mime-types/             # accepts 的传递依赖被提升到顶层

幽灵依赖问题的产生

这种扁平化模式虽然在空间利用上有所优化，但却引入了一个严重的架构问题：幽灵依赖（Ghost Dependencies）或幻影依赖（Phantom Dependencies）。

幽灵依赖是指项目代码可以直接访问和使用在 package.json 中未明确声明的依赖包。这种隐式的依赖关系带来了以下风险：

依赖脆弱性：当直接依赖更新后不再需要某个传递依赖时，项目可能因为缺少该依赖而崩溃
版本不确定性：幽灵依赖的版本完全取决于提升算法的结果，可能在不同环境下产生不一致的行为
维护困难：开发者难以追踪项目真正依赖的所有包，增加了维护复杂性

pnpm 的革新性解决方案

设计理念：严格性与高效性的统一

pnpm 为了从根本上解决幽灵依赖问题，采取了截然不同的依赖管理策略。其核心理念是通过符号链接（Symlinks）和非扁平化的 node_modules 结构，实现严格的依赖隔离。

全局共享存储机制

pnpm 的第一个创新是内容可寻址存储（Content-Addressable Storage）：

单一存储位置：所有依赖包的实际文件都只会在全局存储库（通常是 ~/.pnpm-store）中安装一次
哈希索引：每个包版本根据其内容的哈希值进行索引和存储
极致空间节省：相同版本的包在整个系统中只存在一份副本

严格的符号链接结构

pnpm 的第二个创新是其独特的 node_modules 组织方式：

node_modules/
├── .pnpm/                          # pnpm 的内部目录
│   ├── lodash@4.17.21/
│   │   └── node_modules/
│   │       └── lodash/             # 指向全局存储的符号链接
│   └── express@4.18.2/
│       └── node_modules/
│           ├── express/            # 指向全局存储的符号链接
│           └── debug/              # express 依赖的 debug
├── lodash -> .pnpm/lodash@4.17.21/node_modules/lodash
└── express -> .pnpm/express@4.18.2/node_modules/express

这种结构具有以下特点：

严格访问控制：项目代码只能访问 package.json 中明确声明的依赖
完整依赖树：每个包的传递依赖都被正确地嵌套在其私有的 node_modules 中
符合 Node.js 解析规则：完全遵循 Node.js 的模块解析算法

`shamefully-hoist=true` 的存在意义

配置项的命名哲学

shamefully-hoist=true 的字面含义为”可耻地提升”，这个命名本身就体现了 pnpm 开发团队对此行为的态度。它表明这种配置违背了 pnpm 的设计初衷，是一种不得已的妥协方案。

触发扁平化行为

当启用 shamefully-hoist=true 时，pnpm 会完全改变其依赖管理行为：

全量提升：所有依赖包（包括传递依赖）都会被提升到 node_modules 的根目录
扁平化结构：创建类似于传统 npm 和 Yarn 的目录结构
兼容性优先：优先保证与现有工具链的兼容性

必要性场景分析

尽管不被推荐，但 shamefully-hoist=true 在以下场景中确实是必要的：

1. 遗留系统兼容性

老旧构建工具：某些历史悠久的构建工具（如较早版本的 webpack、rollup 等）可能硬性依赖扁平化的 node_modules 结构
企业级遗留项目：大型企业的遗留代码库可能包含大量对幽灵依赖的直接引用

2. 工具链限制

Monorepo 工具：某些 Monorepo 管理工具（如早期版本的 Lerna）可能无法正确处理 pnpm 的符号链接结构
IDE 和编辑器：部分开发环境可能无法正确解析符号链接，导致代码补全和类型检查功能异常

3. 非标准开发模式

直接文件访问：某些开发流程可能需要直接访问 node_modules 中的文件，而非通过标准的模块导入
动态模块加载：使用动态路径进行模块加载的代码可能依赖扁平化结构

权衡与最佳实践

使用 `shamefully-hoist=true` 的代价

启用此配置会带来以下负面影响：

安全性降低：重新引入幽灵依赖问题
性能影响：失去 pnpm 在安装速度和磁盘空间上的优势
一致性风险：可能在不同环境下产生不一致的依赖解析结果

最佳实践建议

优先修复根本问题：尽可能通过修改代码或升级工具来适配 pnpm 的默认行为
渐进式迁移：将 shamefully-hoist=true 视为临时过渡方案
持续监控：定期评估是否可以移除此配置
团队共识：确保团队成员理解使用此配置的风险和权衡

结论

shamefully-hoist=true 是 pnpm 为了向后兼容性而提供的一个实用但非理想的配置选项。虽然其命名带有明显的不推荐意味，但在特定的项目迁移和兼容性场景下，它确实能够解决实际问题。

然而，我们应该将其视为一种过渡性妥协，而非长期解决方案。理想情况下，开发者应该努力适配 pnpm 的严格依赖管理机制，以充分享受其在性能、空间利用和依赖安全性方面的巨大优势。

在绝大多数情况下，坚持 pnpm 的默认行为不仅是技术上的最佳选择，也是对现代 JavaScript 生态系统健康发展的重要贡献。

JavaScript-事件机制：捕获和冒泡

发表于 2024-09-05

JavaScript 事件机制中，捕获（Capturing） 和 冒泡（Bubbling） 是两个核心概念，它们共同定义了事件在 DOM 树中的传播路径。理解这两种机制，不仅能帮助开发者编写更高效、更健壮的代码，还能深入理解 Web 标准化过程中的一段重要历史。

一、历史背景：浏览器标准之争

在 Web 发展的早期阶段，缺乏统一的事件处理标准，各主流浏览器厂商采用了不同的事件传播模型，形成了著名的”浏览器战争”。

`Netscape` 的事件捕获模型

Netscape 浏览器提出了 事件捕获（Event Capturing） 模型。该模型的核心理念是：事件应该从 DOM 树的最顶层（document 或 window）开始传播，逐级向下传递，如同”捕获”目标一样，直到到达真正的目标元素。

微软 IE 的事件冒泡模型

微软的 Internet Explorer 则采用了截然不同的 事件冒泡（Event Bubbling） 模型。该模型认为事件应该从被触发的目标元素开始，然后像水中的气泡一样逐级向上传播，直到到达 DOM 树的顶层。

W3C 标准的统一方案

两种相互冲突的事件流模型给开发者带来了巨大的兼容性问题，开发者不得不为不同浏览器维护两套代码实现。为了解决这一混乱局面，万维网联盟（W3C）制定了统一的 DOM 事件规范，巧妙地将两种模型整合成一个完整的事件流标准。

W3C 事件流模型包含三个连续阶段：

捕获阶段（Capturing Phase）：事件从 window 开始，经过 document，沿着 DOM 树向下传播至目标元素
目标阶段（Target Phase）：事件到达并处理目标元素本身
冒泡阶段（Bubbling Phase）：事件从目标元素开始，沿着 DOM 树向上冒泡，经过 document 最终到达 window

二、机制解析：各自解决的核心问题

事件捕获和冒泡机制的并存并非冗余设计，它们各自承担着不同的职责，为开发者提供了灵活而强大的事件处理能力。

2.1 冒泡机制：事件委托的基础

事件冒泡机制最重要的应用场景是实现 事件委托（Event Delegation） 模式。

应用场景示例

考虑一个包含大量列表项的动态列表：

// 传统方式：为每个列表项单独绑定事件（性能低下）
const items = document.querySelectorAll('li');
items.forEach(item => {
    item.addEventListener('click', handleItemClick);
});

// 事件委托方式：利用冒泡机制在父元素统一处理
const list = document.querySelector('ul');
list.addEventListener('click', function(event) {
    if (event.target.tagName === 'LI') {
        handleItemClick(event);
    }
});

优势分析

内存效率：减少事件监听器数量，降低内存消耗
动态兼容：新增的列表项自动具备事件处理能力，无需重新绑定
维护性：集中式事件管理，代码结构更清晰

2.2 捕获机制：事件拦截与全局控制

捕获阶段为开发者提供了在事件到达目标元素之前进行拦截处理的能力，特别适用于需要全局性控制的场景。

应用场景示例

实现模态框的外部点击关闭功能：

// 在捕获阶段拦截所有点击事件
document.addEventListener('click', function(event) {
    const modal = document.querySelector('.modal');
    const isClickInsideModal = modal.contains(event.target);
    
    if (!isClickInsideModal && modal.classList.contains('active')) {
        // 在事件到达目标前就处理关闭逻辑
        closeModal();
        event.stopPropagation(); // 阻止事件继续传播
    }
}, true); // 第三个参数 true 表示在捕获阶段处理

适用场景

全局事件拦截：在事件到达具体目标前进行统一处理
权限控制：在事件处理前进行权限验证
性能优化：提前阻止不必要的事件传播

三、现代 JavaScript 中的实现

在现代 JavaScript 中，addEventListener() 方法提供了完整的事件阶段控制能力。

3.1 API 语法

1	element.addEventListener(type, listener, options);

3.2 参数详解

type：事件类型（如 'click'、'keydown' 等）
listener：事件处理函数
options：配置对象或布尔值

options 对象属性

{
    capture: boolean,    // true: 捕获阶段，false: 冒泡阶段（默认）
    once: boolean,       // 是否只执行一次
    passive: boolean     // 是否为被动监听器
}

3.3 实践示例

// 冒泡阶段监听（默认）
element.addEventListener('click', handler);
element.addEventListener('click', handler, false);
element.addEventListener('click', handler, { capture: false });

// 捕获阶段监听
element.addEventListener('click', handler, true);
element.addEventListener('click', handler, { capture: true });

// 组合配置
element.addEventListener('click', handler, {
    capture: true,
    once: true,
    passive: true
});

3.4 事件对象的关键属性

function eventHandler(event) {
    console.log('当前目标:', event.currentTarget);    // 绑定监听器的元素
    console.log('事件目标:', event.target);           // 实际触发事件的元素
    console.log('事件阶段:', event.eventPhase);       // 1:捕获 2:目标 3:冒泡
    
    // 控制事件传播
    event.stopPropagation();        // 阻止事件继续传播
    event.stopImmediatePropagation(); // 阻止剩余监听器执行
    event.preventDefault();          // 阻止默认行为
}

总结

在实际开发中，建议根据具体的业务需求选择合适的事件传播阶段，充分利用事件委托等模式来提升代码质量和应用性能。

优先使用冒泡阶段：大多数场景下冒泡阶段已足够，且符合开发者的直觉理解
捕获阶段的特定用途：全局拦截、权限控制、性能优化等特殊需求
避免不必要的捕获监听：捕获阶段监听器会在每次事件传播时都被调用，影响性能

浏览器发送请求在什么情况下会携带 Cookie

发表于 2024-05-04

Cookie 是 Web 开发中用于状态管理的重要机制，但浏览器并不是在所有请求中都会携带 Cookie。

浏览器在发送请求时携带 Cookie 必须满足以下所有条件：

1. `Cookie` 必须是有效的

未过期

Cookie 的 Expires 或 Max-Age 属性必须还没有到期。

Expires: 指定具体的过期时间（GMT 格式）
Max-Age: 指定从现在开始的存活时间（秒数）
如果两个属性都设置，Max-Age 优先级更高

未被删除

Cookie 没有被用户、服务器或浏览器策略删除。

用户可以通过浏览器设置手动删除
服务器可以通过设置过期时间删除
浏览器会根据存储限制自动清理旧 Cookie

2. `Cookie` 的作用域必须匹配

域名（`Domain`）匹配

请求的域名必须与 Cookie 的 Domain 属性相匹配，或者是它的子域名。

如果 Domain 属性没有设置，默认为设置 Cookie 的域名（不包含子域名）
设置 Domain=.example.com 可以让 Cookie 在 example.com 和所有子域名生效
出于安全考虑，无法为其他域名设置 Cookie

路径（`Path`）匹配

请求的路径必须在 Cookie 的 Path 属性指定的路径下。

如果 Path 属性没有设置，默认为设置 Cookie 页面的路径
Path=/admin 意味着只有访问 /admin 及其子路径时才会发送该 Cookie
路径匹配遵循”最长前缀匹配”原则

3. `Cookie` 的安全属性必须满足

安全连接（Secure）

如果 Cookie 设置了 Secure 属性，浏览器只会在 HTTPS 协议下发送它。

这是防止中间人攻击的重要安全措施
对于敏感信息（如登录令牌），建议始终使用 Secure 属性

`HttpOnly` 属性

虽然 HttpOnly 不影响 Cookie 是否被发送，但它是重要的安全属性。

设置了 HttpOnly 的 Cookie 无法通过 JavaScript 访问
有效防止 XSS 攻击获取敏感 Cookie

同站规则（`SameSite`）

SameSite 属性控制跨站请求时的 Cookie 发送行为：

SameSite=Strict: 只在同站请求中发送 Cookie，提供最严格的保护
SameSite=Lax: 在同站请求中发送，并且在用户点击链接或 GET 表单等方式进行跨站导航时也会发送（默认值）
SameSite=None: 在同站和跨站请求中都发送，但必须同时设置 Secure 属性

绝大多数情况下，Cookie 的所有字段都是由服务器在 HTTP 响应的 Set-Cookie 头部设置。

1
2
3

HTTP/1.1 200 OK
Set-Cookie: sessionId=abc123xyz; Max-Age=3600; Path=/; HttpOnly; Secure; SameSite=Lax
Content-Type: text/html

Cookie 如何跨网站追踪你的行踪

发表于 2024-04-06

在现代互联网环境中，Cookie 作为一种重要的 Web 技术，不仅为用户提供了便利的会话管理和个性化体验，同时也成为了数字营销和用户行为分析的核心技术。虽然大多数用户了解 Cookie 能够记住登录状态和购物车信息，但很少有人深入理解**第三方 Cookie（Third-party Cookie）**是如何成为广告商和数据公司跨网站追踪用户浏览行为的技术基础。

本文将深入解析第三方 Cookie 的工作机制，揭示其在跨站点用户追踪中的核心作用，并探讨其对用户隐私的影响。

`Cookie` 的基础概念与分类

第一方 `Cookie`（First-party Cookie）

第一方 Cookie 是由用户当前访问的网站域名直接设置的 Cookie。其主要特征包括：

域名归属：Cookie 的 Domain 属性与当前访问网站的域名相匹配
访问权限：只能被设置它的域名读取和修改
主要用途：会话管理、用户认证、购物车状态保存、个性化设置等

示例场景：

1
2
3

# 用户访问 https://myshop.com 时
# 服务器响应头设置 Cookie
Set-Cookie: session_id=abc123; Domain=myshop.com; Path=/; HttpOnly; Secure

在这个例子中，myshop.com 设置的 session_id 只能被 myshop.com 域名下的页面访问，这就是典型的第一方 Cookie。

第三方 `Cookie`（Third-party Cookie）

第三方 Cookie 是由与当前访问网站不同的域名设置的 Cookie。其技术特点包括：

域名差异：Cookie 的 Domain 属性与当前页面域名不同
嵌入式触发：通常通过嵌入的第三方资源（广告、分析脚本、社交插件等）设置
跨站点持久性：能够在不同网站间保持标识符的一致性

技术实现机制：

# 用户在 myshop.com 页面上
# 页面包含来自 ad-company.com 的广告图片
<img src="https://ad-company.com/ad?size=banner" />

# 浏览器向 ad-company.com 发起请求
GET /ad?size=banner HTTP/1.1
Host: ad-company.com
Referer: https://myshop.com/product/shoes

# ad-company.com 服务器响应并设置第三方 Cookie
HTTP/1.1 200 OK
Set-Cookie: tracking_id=user_123abc; Domain=ad-company.com; Path=/; Expires=...
Content-Type: image/png

跨网站追踪的技术实现机制

1. 用户标识符的建立

第三方 Cookie 追踪的第一步是为用户建立一个唯一标识符（Unique Identifier）。这个过程通常发生在用户首次访问包含第三方资源的网站时：

// 第三方追踪脚本的典型实现
(function() {
    // 检查是否已存在追踪 Cookie
    let trackingId = getCookie('tracking_id');
    
    if (!trackingId) {
        // 生成新的唯一标识符
        trackingId = generateUniqueId(); // 例如：user_789xyz123
        setCookie('tracking_id', trackingId, {
            domain: 'ad-company.com',
            expires: new Date(Date.now() + 365 * 24 * 60 * 60 * 1000), // 1年
            sameSite: 'None',
            secure: true
        });
    }
    
    // 发送追踪信息到服务器
    sendTrackingData(trackingId, {
        referrer: document.referrer,
        url: window.location.href,
        timestamp: Date.now()
    });
})();

2. 跨站点信息收集

当用户访问不同网站时，第三方 Cookie 能够通过以下机制收集跨站点行为数据：

HTTP `Referer` 头信息传递

# 用户从 myshop.com 访问包含 ad-company.com 资源的页面
GET /track.gif?page=product HTTP/1.1
Host: ad-company.com
Referer: https://myshop.com/product/running-shoes
Cookie: tracking_id=user_123abc

# 随后用户访问 news-site.com
GET /track.gif?page=article HTTP/1.1
Host: ad-company.com
Referer: https://news-site.com/sports/marathon-training
Cookie: tracking_id=user_123abc

JavaScript 接口数据收集

// 第三方追踪脚本收集的详细信息
const trackingData = {
    userId: 'user_123abc',
    sessionId: generateSessionId(),
    pageData: {
        url: window.location.href,
        title: document.title,
        referrer: document.referrer,
        timestamp: Date.now()
    },
    deviceInfo: {
        userAgent: navigator.userAgent,
        screenResolution: `${screen.width}x${screen.height}`,
        language: navigator.language,
        timezone: Intl.DateTimeFormat().resolvedOptions().timeZone
    },
    behaviorData: {
        scrollDepth: calculateScrollDepth(),
        timeOnPage: calculateTimeOnPage(),
        clickEvents: getClickEvents()
    }
};

3. 用户画像构建

追踪公司通过收集的跨站点数据构建详细的用户画像（User Profile）：

{
  "userId": "user_123abc",
  "profile": {
    "demographics": {
      "estimatedAge": "25-34",
      "gender": "likely_female",
      "location": "San Francisco, CA"
    },
    "interests": [
      "running",
      "fitness",
      "technology",
      "online_shopping"
    ],
    "visitedSites": [
      {
        "domain": "myshop.com",
        "category": "e-commerce",
        "visits": 15,
        "lastVisit": "2024-01-15T10:30:00Z"
      },
      {
        "domain": "news-site.com",
        "category": "news",
        "visits": 8,
        "lastVisit": "2024-01-14T16:45:00Z"
      }
    ],
    "purchaseIntent": {
      "categories": ["athletic_wear", "running_shoes"],
      "priceRange": "$50-$150",
      "likelihood": 0.75
    }
  }
}

技术实现的关键环节

1. 同源策略的绕过

虽然浏览器的**同源策略（Same-Origin Policy）**限制了不同域名间的直接数据访问，但第三方 Cookie 通过以下方式合法绕过这些限制：

资源嵌入：通过 <img>、<script>、<iframe> 等标签嵌入第三方资源
SameSite 属性：设置 SameSite=None 允许跨站点发送 Cookie
Secure 标志：配合 HTTPS 确保 Cookie 的安全传输

2. `Cookie` 同步机制

大型追踪网络通常采用 **Cookie 同步（Cookie Syncing）**技术来扩大追踪覆盖范围：

// Cookie 同步的实现示例
function syncCookies() {
    const partners = [
        'https://partner1.com/sync',
        'https://partner2.com/sync',
        'https://partner3.com/sync'
    ];
    
    const myTrackingId = getCookie('tracking_id');
    
    partners.forEach(partnerUrl => {
        const syncImg = new Image();
        syncImg.src = `${partnerUrl}?id=${myTrackingId}&partner=ad-company`;
        // 这使得合作伙伴能够将他们的 ID 与我们的 ID 关联
    });
}

3. 指纹技术的补充

当 Cookie 被阻止或删除时，追踪公司会使用**设备指纹（Device Fingerprinting）**技术作为补充：

// 设备指纹生成示例
function generateDeviceFingerprint() {
    const fingerprint = {
        canvas: getCanvasFingerprint(),
        webgl: getWebGLFingerprint(),
        audio: getAudioFingerprint(),
        fonts: getInstalledFonts(),
        plugins: getPluginList(),
        timezone: Intl.DateTimeFormat().resolvedOptions().timeZone,
        language: navigator.languages.join(','),
        platform: navigator.platform,
        hardwareConcurrency: navigator.hardwareConcurrency
    };
    
    return btoa(JSON.stringify(fingerprint));
}

HTTP 状态码

发表于 2024-04-03

什么是 HTTP 状态码

HTTP 状态码是服务器对客户端请求的响应代码，用于表示请求的处理结果。每个状态码都是一个三位数字，第一位数字表示响应的类别。

状态码分类

HTTP 状态码按照第一位数字分为五个类别：

1xx（信息性响应）：请求已接收，继续处理
2xx（成功响应）：请求已成功被服务器接收、理解并处理
3xx（重定向）：需要后续操作才能完成这一请求
4xx（客户端错误）：请求包含错误语法或无法被执行
5xx（服务器错误）：服务器在处理请求的过程中发生了错误

常见状态码详解

1xx 信息性响应

100 Continue

含义：服务器已接收到请求头，客户端应继续发送请求体
使用场景：大文件上传时的预检查

101 Switching Protocols

含义：服务器已理解请求，将通过 Upgrade 头字段切换协议
使用场景：WebSocket 连接建立

2xx 成功响应

200 OK

含义：请求成功，服务器已成功处理请求
使用场景：GET、POST、PUT 等请求成功时的标准响应

201 Created

含义：请求成功并且服务器创建了新的资源
使用场景：POST 请求成功创建新资源后

204 No Content

含义：服务器成功处理请求，但不需要返回任何实体内容
使用场景：DELETE 请求成功执行后

206 Partial Content

含义：服务器已经成功处理了部分 GET 请求
使用场景：断点续传、视频流媒体传输

3xx 重定向

301 Moved Permanently

含义：请求的资源已永久移动到新位置
影响：搜索引擎会更新索引，浏览器会缓存重定向
使用场景：网站迁移、URL 结构调整

302 Found

含义：请求的资源临时移动到新位置
影响：搜索引擎不会更新索引
使用场景：临时维护页面跳转

304 Not Modified

含义：资源未修改，可以使用缓存版本
使用场景：条件 GET 请求，配合 ETag 或 Last-Modified 使用

307 Temporary Redirect

含义：临时重定向，要求客户端保持请求方法不变
与 302 区别：严格要求不改变 HTTP 方法

4xx 客户端错误

400 Bad Request

含义：请求语法错误，服务器无法理解
常见原因：参数格式错误、JSON 格式错误

401 Unauthorized

含义：请求需要身份验证
响应头：通常包含 WWW-Authenticate 头
使用场景：访问受保护资源时未提供凭证

403 Forbidden

含义：服务器理解请求但拒绝执行
与 401 区别：403 表示服务器知道客户端身份但仍拒绝访问

404 Not Found

含义：服务器无法找到请求的资源
使用场景：URL 路径错误、资源已删除

405 Method Not Allowed

含义：请求方法不被允许
响应头：必须包含 Allow 头，指明允许的方法

409 Conflict

含义：请求与服务器当前状态冲突
使用场景：数据版本冲突、重复创建资源

429 Too Many Requests

含义：客户端发送的请求过多
响应头：可包含 Retry-After 头
使用场景：API 限流保护

5xx 服务器错误

500 Internal Server Error

含义：服务器遇到意外错误，无法完成请求
常见原因：代码错误、数据库连接失败

502 Bad Gateway

含义：网关或代理服务器从上游服务器收到无效响应
使用场景：负载均衡器、CDN 与源服务器通信失败

503 Service Unavailable

含义：服务器暂时无法处理请求
响应头：可包含 Retry-After 头
使用场景：服务器维护、过载保护

504 Gateway Timeout

含义：网关或代理服务器等待上游响应超时
使用场景：代理服务器与后端服务器通信超时

在实际开发中的应用

RESTful API 设计

GET /users/123          → 200 OK (获取成功)
POST /users             → 201 Created (创建成功)
PUT /users/123          → 200 OK 或 204 No Content
DELETE /users/123       → 204 No Content
GET /users/999          → 404 Not Found
POST /users (数据错误)   → 400 Bad Request

缓存策略

利用状态码实现高效缓存：

1
2
3

HTTP/1.1 304 Not Modified
ETag: "33a64df551"
Cache-Control: max-age=3600

选择合适的状态码

语义化原则：选择最能准确描述响应状态的代码
一致性原则：在整个应用中保持状态码使用的一致性

JavaScript 的真相：一门被误解的语言

发表于 2024-03-24

很多人都说 JavaScript 是解释型语言，但这其实是个过时的说法。现代的 JavaScript 引擎早就不是简单的解释器了，它们使用了一套相当复杂且精妙的执行机制。作为一个开发者，了解这个过程不仅能帮你写出更好的代码，还能让你在面试时显得更专业（笑）。

JavaScript 到底是什么类型的语言？

在传统的认知中，我们常常简单地将 JavaScript 称为”解释型语言”。然而，这个定义已经过时了。现代 JavaScript 是一门动态语言，它的执行方式远比”解释”二字复杂得多，这都归功于其运行环境（如浏览器或 Node.js）所采用的即时编译（JIT）技术。

传统分类的局限性

按照传统的分类：

编译型语言：执行前一次性编译成机器码（如 C++）
解释型语言：逐行读取、逐行执行，不生成中间代码（如早期的 PHP）

但现代 JavaScript 哪种都不是，它用的是 **即时编译（JIT）**技术。

从”解释”到”编译”的演进历程

为了理解 JavaScript 的本质，咱们得回顾一下它在执行机制上的演进过程。

早期时代：纯粹的解释执行

在 Web 发展的早期阶段，JavaScript 引擎确实是纯粹的解释器。它们逐行读取你写的 JavaScript 代码，然后立即执行，不会生成任何中间的机器码。

这种方式的好处很明显：启动速度快，写完代码就能跑。但问题也同样明显：执行效率低得要命。如果同一段代码需要重复执行（比如循环里的代码），解释器就得一遍遍地重新解释，这就像你每次做菜都要重新看一遍菜谱一样，效率自然上不去。

现代时代：混合的即时编译（JIT）

为了解决这个性能瓶颈，现代 JavaScript 引擎（比如 Chrome 的 V8、Firefox 的 SpiderMonkey）引入了 JIT 技术。这是一种非常聪明的混合模式，结合了编译和解释两种方式的优点。

整个工作流程是这样的：

解释器先上场：首先，解释器快速地解释执行代码，让程序能够立即启动运行
监控器在暗中观察：在解释执行的同时，有一个监控器（Profiler）会默默地观察哪些代码被频繁调用，并将这些代码标记为**”热点代码”**（Hot Spots）
编译器介入优化：当某段代码被识别为热点后，JIT 编译器会介入，将这段代码编译成高度优化的机器码并缓存起来
直接执行机器码：下次再运行这段热点代码时，引擎会直接执行编译好的机器码，效率提升几个数量级

所以说，将 JavaScript 简单地称为”解释型语言”其实是不准确的。更严谨的说法应该是：JavaScript 是一门通过 JIT 编译器执行的动态语言。

从源码到执行：完整的生命周期

让我们跟着一段简单的代码，看看它在 JavaScript 引擎中的完整旅程：

function add(a, b) {
  return a + b;
}

let result = add(2, 3);

第一步：词法分析（Lexing）

引擎首先会把你的代码字符串切成一个个独立的词法单元（Tokens）：

1	['function', 'add', '(', 'a', ',', 'b', ')', '{', 'return', 'a', '+', 'b', '}', ...]

这就像把一句话拆成一个个单词，为后续的语法分析做准备。

第二步：语法分析（Parsing）

解析器（Parser）接收这些 Tokens，根据 JavaScript 的语法规则，构建出一棵抽象语法树（AST）：

- Program
  - FunctionDeclaration (name: "add")
    - params: ["a", "b"]
    - body: BlockStatement
      - ReturnStatement
        - argument: BinaryExpression
          - left: Identifier (name: "a")
          - right: Identifier (name: "b")
          - operator: "+"
  - VariableDeclaration (kind: "let")
    - declarations:
      - VariableDeclarator
        - id: Identifier (name: "result")
        - init: CallExpression
          - callee: Identifier (name: "add")
          - arguments: [Literal(2), Literal(3)]

AST 就像代码的一张结构图，它清楚地描述了代码的逻辑关系，但还不能直接执行。你可以把 AST 理解为代码的一张可执行蓝图。

第三步：字节码生成

在现代引擎（如 V8）中，解释器不会直接执行 AST，而是先将 AST 转换成更紧凑的字节码（Bytecode）。

为什么要多这一步？因为字节码比 AST 更节省内存，执行起来也更快。

第四步：解释执行（Ignition）

现在轮到解释器登场了。以 V8 为例，Ignition 解释器开始执行字节码：

函数声明：将 add 函数的信息存储到全局作用域
变量声明：需要给 result 赋值，进入函数调用
函数调用：创建新的作用域，将参数 2 和 3 绑定到 a 和 b
二元表达式：递归求值 a + b，得到结果 5
返回值：将结果 5 赋值给 result

解释器是如何工作的？

解释器的核心是一个巨大的 switch 语句（用 C++ 写的），大概长这样：

switch (bytecode.opcode) {
  case ADD:
    // 从栈中弹出两个值，相加，结果压入栈
    break;
  case CALL_FUNCTION:
    // 创建新的执行上下文，调用函数
    break;
  case LOAD_GLOBAL:
    // 从全局作用域加载变量
    break;
  // ... 更多指令
}

它通过递归遍历和操作数据结构，模拟了代码的执行过程。

第五步：性能监控

在 Ignition 执行字节码的同时，它会悄悄地收集性能数据：

哪些函数被调用了多少次？
变量的类型是否稳定？
循环执行了多少次？

当某段代码变成”热点”时，就该 TurboFan 出场了。

第六步：编译优化（TurboFan）

TurboFan 是 V8 的优化编译器，它会：

接收热点代码：从 Ignition 获取字节码和性能数据
大胆假设：基于收集的数据做优化假设（比如某个变量总是整数）
生成机器码：编译成高度优化的、特定硬件的机器码
替换执行：用机器码替换原来的字节码

第七步：去优化（Deoptimization）

如果 TurboFan 的假设被打破了（比如那个”总是整数”的变量突然变成了字符串），引擎会执行去优化，重新回到 Ignition 执行字节码。

现代 JavaScript 引擎的优化策略

现代 JavaScript 引擎为了进一步提升性能，还采用了很多高级优化技术：

内联缓存（Inline Caching）：缓存对象属性的访问路径，避免重复的属性查找
隐藏类（Hidden Classes）：为对象生成隐藏的类型信息，优化属性访问
去优化（Deoptimization）：当代码的执行模式发生变化时，回退到解释执行模式

这些优化技术让 JavaScript 的执行效率越来越接近静态编译语言。

常见误解澄清

解析器 vs 解释器

很多人容易混淆这两个概念：

解析器（Parser）：负责构建 AST，不执行代码
解释器（Interpreter）：负责执行 AST 或字节码

可以把解析器想象成读懂建筑图纸的建筑师，解释器则是真正搬砖的工人。

“解释执行”的真正含义

解释执行不是指逐行读取源码文本，而是指：

将源码转换成中间表示（AST 或字节码）
直接执行这个中间表示，不生成永久的机器码文件

这个过程是”边解析边执行”，而不是”先全部编译再执行”。

解释器的本质

解释器本身就是一个用 C/C++ 写的程序。当你运行 node script.js 时，你启动的 node 可执行文件就包含了用 C++ 实现的 V8 引擎。

为什么用 C/C++？因为需要：

极致的性能
底层的内存控制
跨平台的兼容性

实际的执行流程总结

现在我们可以完整地梳理一下 JavaScript 的执行流程：

源码 
  ↓ 词法分析
Tokens 
  ↓ 语法分析  
AST 
  ↓ 字节码生成
Bytecode 
  ↓ 解释执行 (Ignition)
快速运行 + 性能监控
  ↓ 发现热点代码
优化编译 (TurboFan)
  ↓ 生成机器码
高性能执行

这个流程既保证了 JavaScript 的灵活性（动态特性），又通过 JIT 技术实现了接近编译型语言的性能。

对开发者的启示

理解这个执行流程，对我们写代码有什么帮助？

避免频繁的类型变化：让 TurboFan 的优化假设更稳定
关注热点代码的性能：频繁执行的代码会被优化，一次性代码不会
理解 JavaScript 的”预热”现象：为什么同一段代码执行多次后会变快

BFC（块格式化上下文）详解：从历史到实践

发表于 2024-03-06

什么是BFC

BFC（Block Formatting Context），即块格式化上下文，是 CSS 视觉格式化模型 （Visual Formatting Model） 的一部分。它是页面中一个独立的渲染区域，该区域拥有一套渲染规则来约束内部元素的布局，且与这个区域外部无关。你可以把它想象成一个“封闭的容器”，容器内的所有元素，包括浮动、定位等，都只会在容器内部进行计算和排列。

BFC产生的背景问题

1. 浮动布局的混乱

在早期的 Web 开发中，float 属性被大量用于页面布局。然而，浮动元素会脱离文档流，导致：

父容器高度塌陷
文字环绕效果难以控制
复杂布局难以实现

2. Margin折叠的不可预测性

相邻块级元素的 margin 会发生折叠，这种行为有时是期望的，有时却会破坏设计：

垂直方向上的 margin 折叠
父子元素之间的 margin 折叠
空元素的 margin 折叠

3. 清除浮动的复杂性

开发者需要各种技巧来清除浮动：

/* 传统的清除浮动方法 */
.clearfix:after {
    content: "";
    display: table;
    clear: both;
}

4. 布局隔离的需求

在复杂页面中，开发者希望某些区域的布局不受外部影响，形成独立的布局环境。

BFC解决的核心问题

1. 包含浮动元素

问题：浮动的子元素会导致父容器高度塌陷

<!-- 问题示例 -->
<div class="container">
    <div class="float-child">浮动元素</div>
</div>

.container {
    border: 2px solid blue;
    /* 高度会塌陷为0 */
}

.float-child {
    float: left;
    width: 100px;
    height: 100px;
    background: red;
}

BFC解决方案：创建 BFC 的容器会包含其内部的浮动元素

.container {
    border: 2px solid blue;
    overflow: hidden; /* 创建BFC */
    /* 或者使用其他方法创建BFC */
}

2. 阻止margin折叠

问题：相邻块级元素的 margin 会发生折叠

1 2	<div class="box1">元素1</div> <div class="box2">元素2</div>

1
2
3

.box1 { margin-bottom: 20px; }
.box2 { margin-top: 30px; }
/* 实际间距只有30px，而不是50px */

BFC 解决方案：将元素放在不同的 BFC 中可以阻止 margin 折叠

<div class="box1">元素1</div>
<div class="bfc-wrapper">
    <div class="box2">元素2</div>
</div>

1
2
3

.bfc-wrapper {
    overflow: hidden; /* 创建新的BFC */
}

3. 排斥浮动元素

问题：普通文档流中的元素会被浮动元素覆盖

1 2	<div class="float">浮动元素</div> <div class="normal">普通元素，内容可能被浮动元素覆盖</div>

BFC 解决方案：BFC 区域不会与浮动元素重叠

1
2
3

.normal {
    overflow: hidden; /* 创建BFC，避免被浮动元素覆盖 */
}

创建BFC的方法

传统方法

根元素（html）：天然的 BFC
浮动元素：float 不为 none
绝对定位元素：position 为 absolute 或 fixed
overflow不为visible：overflow: hidden/auto/scroll
display属性：
- display: inline-block
- display: table-cell
- display: table-caption
- display: table

现代方法（推荐）

display: flow-root：专门为创建 BFC 设计

1
2
3

.bfc-container {
    display: flow-root; /* 最纯净的BFC创建方式 */
}

contain 属性：

1
2
3

.bfc-container {
    contain: layout; /* CSS Containment */
}

BFC的布局规则

核心规则

内部的块级元素会在垂直方向一个接一个地放置
块级元素垂直方向的距离由 margin 决定，相邻元素的 margin 会发生折叠
每个元素的左外边缘与包含块的左边缘相接触
BFC 的区域不会与浮动元素重叠
BFC 是页面上的独立容器，内外元素不会相互影响
计算 BFC 高度时，浮动子元素也参与计算

实际应用示例

1. 两栏布局

<div class="container">
    <div class="sidebar">侧边栏</div>
    <div class="main">主内容区</div>
</div>

.sidebar {
    float: left;
    width: 200px;
    background: #f0f0f0;
}

.main {
    overflow: hidden; /* 创建BFC，形成自适应布局 */
    background: #fff;
}

2. 清除浮动

<div class="container">
    <div class="float-item">浮动项目1</div>
    <div class="float-item">浮动项目2</div>
</div>

.container {
    display: flow-root; /* 现代清除浮动方法 */
    /* 替代传统的 overflow: hidden */
}

.float-item {
    float: left;
    width: 200px;
    height: 150px;
    margin-right: 20px;
    background: #ddd;
}

理解 JavaScript 的 Error 对象：超越 .stack 的全面解析

.message：错误信息的简明扼要

.name：错误类型的身份证

.stack：错误的”犯罪现场”重现

理解调用堆栈的工作原理

.stack 的输出格式

实际案例分析

.cause：错误的”前世今生”

Mustache 语法：那些双大括号的故事

这东西是从哪来的？

起源故事

设计思路很朴素

Mustache 到底有啥特点？

真的没有逻辑

双大括号就是招牌

支持嵌套访问

来个实际例子

稍微复杂点的例子

为什么 Vue 和小程序都用它？

问题背景

传统包装方案的局限性

存在的核心问题

TypeScript 模块扩展方案

核心语法：declare module + interface

技术原理解析

1. 模块扩展机制（Module Augmentation）

2. interface 合并机制（Declaration Merging）

实际应用示例

基础 API 调用

请求拦截器应用

响应拦截器处理

注意事项

1. 全局影响范围

2. 版本兼容性管理

3. 命名规范

传统包管理器的扁平化策略及其弊端

扁平化机制的发展背景

依赖提升机制

幽灵依赖问题的产生

pnpm 的革新性解决方案

设计理念：严格性与高效性的统一

全局共享存储机制

严格的符号链接结构

shamefully-hoist=true 的存在意义

配置项的命名哲学

触发扁平化行为

必要性场景分析

1. 遗留系统兼容性

2. 工具链限制

3. 非标准开发模式

权衡与最佳实践

使用 shamefully-hoist=true 的代价

推荐的替代方案

1. 精确的依赖声明

2. 选择性提升配置

3. 工具链升级

最佳实践建议

结论

一、历史背景：浏览器标准之争

Netscape 的事件捕获模型

微软 IE 的事件冒泡模型

W3C 标准的统一方案

二、机制解析：各自解决的核心问题

2.1 冒泡机制：事件委托的基础

应用场景示例

优势分析

2.2 捕获机制：事件拦截与全局控制

应用场景示例

适用场景

三、现代 JavaScript 中的实现

3.1 API 语法

3.2 参数详解

options 对象属性

3.3 实践示例

3.4 事件对象的关键属性

总结

Cookie 携带的必要条件

1. Cookie 必须是有效的

未过期

未被删除

理解 JavaScript 的 Error 对象：超越 `.stack` 的全面解析

`.message`：错误信息的简明扼要

`.name`：错误类型的身份证

`.stack`：错误的”犯罪现场”重现

`.stack` 的输出格式

`.cause`：错误的”前世今生”

核心语法：`declare module` + `interface`

2. `interface` 合并机制（Declaration Merging）

`shamefully-hoist=true` 的存在意义

使用 `shamefully-hoist=true` 的代价

`Netscape` 的事件捕获模型

1. `Cookie` 必须是有效的

2. `Cookie` 的作用域必须匹配

域名（`Domain`）匹配

路径（`Path`）匹配

3. `Cookie` 的安全属性必须满足

`HttpOnly` 属性

同站规则（`SameSite`）

`Cookie` 的基础概念与分类

第一方 `Cookie`（First-party Cookie）

第三方 `Cookie`（Third-party Cookie）

HTTP `Referer` 头信息传递

2. `Cookie` 同步机制