于是一个 摸鱼 的下午，我祭出了 mole 这个用 Rust 写的终端磁盘分析工具，打算彻底搞清楚到底是谁在偷我的硬盘。结果一扫描，一个意想不到的选手浮出水面：

Edge 浏览器，5 个 G。

好家伙，一个浏览器而已，用得着囤这么多东西吗？你是打算在我硬盘上安家落户吗？😅

真凶：Service Worker 下的 CacheStorage

顺着 mole 的结果往下 drill，我发现占用大头主要集中在下面这个目录：

~/Library/Application Support/Microsoft Edge/Default/

更具体的，是 Default/CacheStorage/ 和 Default/Service Worker/ 这两个目录。CacheStorage 里面有大量以 ID 命名的文件夹，每个里面都有 .db 和 .blob 文件，完全不知道对应的是哪个网站或扩展。

我平时 Edge 使用频率很高，标签页常年几十个开着。这种情况下，想肉眼看出哪个网站的 Service Worker 在疯狂缓存，简直是不可能的事情。

不过 Chromium 内核的浏览器有个好处 —— 它内置了几个"上帝视角"的调试页面：

通过这几个页面，理论上可以把每个存储块跟具体的网站或扩展对应起来。但问题是 —— 这些页面是给人看的，不是给机器读的。几百个 Origin 一个个手动对照，那不是要累死？🤦‍♂️

作为一个懒人程序员，我决定写个工具来自动化这个过程。

技术方案设计

我和 Gemini 讨论了一下，梳理出了一个相对完整的方案。核心思路是 采集→解析→关联→报告 四层解耦：

┌─────────────────────────────────┐
│          驱动层 (Bash)           │  ← 进程锁检查、环境清理
├─────────────────────────────────┤
│        采集层 (Node.js + Playwright) │  ← 模拟用户行为，绕过 edge:// 限制
├─────────────────────────────────┤
│          引擎层 (Rust)           │  ← 高性能解析、关联分析、异常识别
├─────────────────────────────────┤
│         表现层 (Rust/Bash)       │  ← 终端报表 & 清理建议
└─────────────────────────────────┘

采集层：绕过沙盒限制

普通的网页 API 只能看到自己域下的数据，但 edge://quota-internals 是浏览器的"特权页面"，可以扫描所有域。关键在于：

• 必须使用非无头模式（headless: false），否则特权页面渲染不完整
• 必须挂载真实 Profile 路径（launchPersistentContext），否则看到的是空数据
• 采集两个关键页面的 HTML 快照：
  • edge://quota-internals → 存储占用数据
  • edge://serviceworker-internals → SW 注册状态
• 额外采集 edge://extensions → Extension ID ↔ 名称映射表

解析层：HTML 转结构化数据

采集到的 HTML 页面结构复杂，直接分析不现实。需要解析成结构化的 JSON 数据：

• 统一单位（全部转为 Bytes，显示时动态换算 MiB/GiB）
• URL 规范化（拆分协议、域名、端口）
• 以 Origin / Storage Key 为主键组织数据

关联层：交叉比对与异常检测

这是整个工具的核心。单纯的存储数据只能告诉你"谁占了空间"，但结合 Service Worker 的状态才能知道"为什么占"。我设计了几种检测规则：

报告层：清理指引

针对检测出来的问题，生成对应的清理建议。每条建议包含 Storage.clearDataForOrigin() 的 CDP 命令供参考（但不自动执行，确保安全）。

两个小时出活

技术方案定下来后，我把整个方案丢给了 Codex。大概两个小时后，一个能跑的 MVP 就出来了。

这里得坦白一下技术选型上的一个小插曲。我当时在 Rust 和 Node.js 之间，倾向选了 Rust 做引擎层。老实说这个场景的数据量根本用不到 Rust 的高性能，几百 KB 的 HTML 用 cheerio 绰绰有余。选 Rust 纯粹是个人偏好，外加想练练手。不过 scraper crate 和 comfy-table crate 确实好用，后者画出来的终端表格比手撸 ASCII 美多了。

手动调了几轮之后，工具跑起来是这样的效果：

Parsed: 4 quota records, 2 service workers, 1 extensions
Total usage: 712.00 MiB

Top Storage Consumers
┌─────────────────────────────────┬────────────┬──────────────┬───────────┐
│ Origin                          ┆ Usage      ┆ CacheStorage ┆ Kind      │
╞═════════════════════════════════╪════════════╪══════════════╪═══════════╡
│ https://example.com             ┆ 640.00 MiB ┆ 600.00 MiB   ┆ Website   │
├╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌┼╌╌╌╌╌╌╌╌╌╌╌╌┼╌╌╌╌╌╌╌╌╌╌╌╌╌╌┼╌╌╌╌╌╌╌╌╌╌╌┤
│ chrome-extension://missing999   ┆ 18.00 MiB  ┆ 18.00 MiB    ┆ Extension │
└─────────────────────────────────┴────────────┴──────────────┴───────────┘

Orphaned Storage Candidates
┌───────────────────────────────┬───────────┬──────────────┬───────────┐
│ Origin                        ┆ Usage     ┆ CacheStorage ┆ Kind      │
╞═══════════════════════════════╪═══════════╪══════════════╪═══════════╡
│ https://orphan.test           ┆ 12.00 MiB ┆ 1.00 MiB     ┆ Website   │
├╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌┼╌╌╌╌╌╌╌╌╌╌╌╌┼╌╌╌╌╌╌╌╌╌╌╌╌╌╌┼╌╌╌╌╌╌╌╌╌╌╌┤
│ chrome-extension://missing999 ┆ 18.00 MiB ┆ 18.00 MiB    ┆ Extension │
└───────────────────────────────┴───────────┴──────────────┴───────────┘

Cache Bloat Risk Candidates
┌─────────────────────┬────────────┬──────────────┬─────────┐
│ Origin              ┆ Usage      ┆ CacheStorage ┆ Kind    │
╞═════════════════════╪════════════╪══════════════╪═════════╡
│ https://example.com ┆ 640.00 MiB ┆ 600.00 MiB   ┆ Website │
└─────────────────────┴────────────┴──────────────┴─────────┘

Cleanup Guidance
- Inspect and clear site data for https://orphan.test from Edge settings.
- Inspect and clear site data for chrome-extension://missing999 from Edge settings.
- Inspect and clear site data for https://example.com from Edge settings.

MVP 验证通过，测试数据能正确检测出孤儿存储、扩展残留和缓存膨胀。接下来就是真刀真枪上场了。

飞书你干得好啊

我把脚本指向了我的真实 Edge Profile 目录，按下回车，几秒后结果就出来了。

Edge 一共吃掉了 5 个多 G。

其中，3.9G 来自飞书网页版。

我本来还怀疑是哪个浏览器扩展出了 bug，有内存泄漏问题或者保存了过多的日志，结果没想到是飞书干的好事。

其实我一开始使用的是飞书桌面客户端，但是也经常发现它会囤积更新数据，占用的储存有时能达到 10个G 以上，所以我切换到了网页版，没想到它一个网页端竟然也能给我存近 4G 的数据……

我想飞书的 Service Worker 大概是这种逻辑：

// 纯属脑补，不代表真实代码
self.addEventListener('fetch', event => {
  // 管他三七二十一，先缓存了再说
  event.respondWith(cacheThenNetwork(event.request))
  // 清理策略？那是什么，能吃吗？
})

也不是不能理解。飞书作为协作办公平台，文件、图片、聊天记录、文档协作数据量本来就大。用 CacheStorage API 做离线缓存确实能提升体验 —— 但这个膨胀幅度属实有点离谱了。三个月前的对话附件和头像，真的有必要一直留在本地吗？😅

总结

这次折腾，从发现问题到最后定位真凶，大概花了一个下午 + 一个晚上。回头看看，整个过程挺有意思的：

1. 问题发现：mole 扫盘 → Edge 5GB 异常占用
2. 线索追踪：手动查看 edge:// 内部页面 → 锁定 CacheStorage 和 Service Worker
3. 方案设计：四层解耦架构，数据采集 + 交叉比对 + 异常检测
4. 极速实现：Codex 生成 MVP，手动调优
5. 终极结果：抓到真凶 —— 飞书网页版 3.9G

写工具的过程本身也值回票价了。说实话，如果不写这个工具，我可能永远想不到要去 edge://quota-internals 看一眼，大概只会粗暴地清理全站数据完事。而有了工具之后，不仅精准定位到冤大头，还顺带发现了一些已卸载扩展的残留文件。

后续如果有时间，我打算把这个工具再打磨一下 —— 加个跨浏览器支持（Chrome/Brave 也就改几个路径和 URL），再搞个 HTML 可视化报告。不过现在嘛，先把飞书的缓存清了再说 🏃‍♂️💨

工具我也已经开源到 GitHub 了，感兴趣的可以去玩一下，不过目前还非常毛坯，需要再打磨一段时间，欢迎大家提出 issue，我 应该 会及时响应。

如果你也好奇自己的 Edge 到底被什么网站悄悄吃掉了硬盘，不妨打开 edge://quota-internals 看一眼。说不定也会有"惊喜" 🙃

我一直不太清楚 import.meta.url 到底是怎么来的，总觉得它是个黑魔法。直到某天我翻开了 ECMAScript 规范，才发现 —— 原来人家是 ESM 的正规军，正儿八经的语言特性 👮。

今天就从头捋一捋：import.meta 从哪来、各环境有啥区别、实战中怎么用。

import.meta：规范只给了一个空壳子 🐚

翻开 ECMAScript 语言规范，你会发现整个语言里只有两个元属性（Meta Property）：

• new.target — 判断构造函数有没有被 new 调用
• import.meta — 我们的主角

语法上长这样：

MetaProperty ::=  import . meta

几个硬性规定，得背下来：

• import 在这里不是关键字，而是 MetaProperty 的起始标记（语法糖呗）
• 只能在模块代码中使用，在传统 Script 里用？直接给你 SyntaxError 💥
• 关键是：规范本身不定义它有哪些属性，这事儿全交给宿主环境决定

简单说：语言标准就搭了个骨架，肉长什么样，由运行时说了算。

设计哲学：Host Hooks，各家装各家的修 🏠

ECMA-262 定义了一个抽象操作 HostGetImportMetaProperties：

HostGetImportMetaProperties(importMeta, moduleRecord) 是宿主环境实现的抽象操作。宿主通过这个 Hook 往 import.meta 对象上注入属性。

这就好比房东给了你一间毛坯房，装修成啥样全看你自己：

ECMAScript 规范:
  └── import.meta 是一个空对象

浏览器 (HTML Spec):
  └── 注入 url, resolve

Node.js:
  └── 注入 url, resolve, dirname, filename

Deno:
  └── 注入 url, main, resolve

Bun:
  └── 注入 url, resolve, dir, file, path, env

所以下次有人再说"import.meta 是哪个框架的私有财产"，你可以微笑着告诉他：这是 ECMAScript 标准的 API，只不过各家往里塞的东西不一样 😎

各家塞了些啥？我们来逐个看看

浏览器

根据 WHATWG HTML Spec，浏览器只给了两个属性，非常克制：

// 当前模块的绝对 URL
console.log(import.meta.url);
// → 'https://example.com/js/app.js'

// 基于当前模块解析相对路径
const resolved = import.meta.resolve('./helper.js');
// → 'https://example.com/js/helper.js'

• url：当前模块的完整绝对 URL（类型 string）
• resolve：一个函数，把相对路径解析成基于当前模块的绝对 URL。Chrome/Edge 105+、Firefox 106+、Safari 16.4+ 开始支持

Node.js

Node.js 在浏览器基础上，加了一堆 CJS 时代的老朋友：

// Node.js ESM 模式

console.log(import.meta.url);
// → 'file:///Users/alice/project/src/index.mjs'

console.log(import.meta.dirname);
// → '/Users/alice/project/src'

console.log(import.meta.filename);
// → '/Users/alice/project/src/index.mjs'

• dirname：等价于 CJS 的 __dirname（Node.js 21.2+）
• filename：等价于 CJS 的 __filename（Node.js 21.2+）
• resolve：行为类似浏览器版，但走的是 Node.js 的模块解析算法（会在 node_modules 里翻）

如果还在用 21.2 以下的 Node.js，也别慌，自己手搓一手：

js

import { fileURLToPath } from 'url';
import { dirname } from 'path';
const __filename = fileURLToPath(import.meta.url);
const __dirname = dirname(__filename);

好家伙，又回到了手写 CJS 兼容层的年代

Deno

import.meta.url;    // → 'file:///...' | 'https://...'
import.meta.main;   // → true 如果当前模块是入口模块
import.meta.resolve('./x.ts');

main 是 Deno 的特色属性，类似 Python 的 if __name__ == '__main__'，用来判断当前模块是不是入口文件，挺实用的。

Bun

import.meta.url;     // → 'file:///...'
import.meta.dir;     // → 目录路径
import.meta.file;    // → 当前文件名
import.meta.path;    // → 完整文件路径
import.meta.env;     // → Bun.env 的访问器

Bun 最"霸道"，直接塞了四个路径相关属性再加一个 env，不愧是"我全都要"的运行时。

为什么 ESM 不直接使用 __dirname

这个问题我当年也困惑过，CJS 时代多爽啊，直接 __dirname 就拿当前目录了。到了 ESM，还得绕个弯：

原因其实挺简单：

1. 全局变量污染：__dirname 在 CJS 里是通过函数包装注入的，本质上不算真正的全局变量，但这套在浏览器里就行不通了
2. 浏览器兼容性：__dirname 在浏览器中没有意义，而 import.meta.url 用统一的 URL 格式覆盖所有环境，从 file:// 到 https:// 全通吃
3. 可扩展性：import.meta 作为可扩展对象，宿主随便往里加东西，比不断新增全局变量优雅得多

跨环境通用约定

import.meta.url 必须是绝对 URL

不管模块是从本地文件系统加载、HTTP 远程加载、还是 data URI，import.meta.url 始终是绝对形式。这就保证了基于它的路径解析永远不会迷路 🗺️。

new URL(relative, import.meta.url) 是最稳的模式

由于 import.meta.url 是绝对 URL，而 URL 构造函数在所有现代运行时上都有，这个模式就成了获取同目录资源的通用、可靠、标准方式：

// 引用同目录下的配置文件——跨环境通用，稳如老狗 🐶
const configPath = new URL('./config.json', import.meta.url);

浏览器里得到 http://...，Node.js 里得到 file:///...，都能直接传给对应的 I/O API。

import.meta.resolve() 的标准化趋势

import.meta.resolve() 最初是浏览器专用，现在已经成了所有主流 ESM 宿主环境的标准配置。语义是相对于当前模块解析模块说明符，返回绝对 URL。

不过各家的返回类型有差异：

• 浏览器：返回字符串
• Node.js：返回 URL 对象（可用 .href 拿字符串）
• 规范允许返回任何对象，只要 toString() 能返回有效 URL

自定义属性的命名约定

由于 import.meta 是可变对象，宿主可以动态加属性。社区有个默契：自定义属性最好用大写或特殊前缀，避免以后冲突。比如 Vite 的 import.meta.env、import.meta.hot 就是典型。

构建工具中的实际应用

前端构建工具（Vite、Webpack、Rollup）在开发阶段保留 import.meta 的语义，但在生产构建时会把相关模式静态替换成最终路径。

Vite 中的常见用法

// 1. 引用同目录静态资源
const imgUrl = new URL('./logo.png', import.meta.url).href;
// 开发: http://localhost:5173/src/logo.png
// 构建: /assets/logo.a1b2c3d4.png

// 2. 创建 Web Worker
const worker = new Worker(new URL('./worker.ts', import.meta.url), {
  type: 'module',
});

Vite 构建时会静态分析 new URL(..., import.meta.url) 这种模式，替换成生产环境的最终资源路径并自动加哈希。但这里有个坑：路径参数必须是字面量字符串，不能是变量，否则 Vite 就没法静态解析了 —— 我第一次踩到这坑的时候，控制台直接报了警告 🤦。

// ❌ 这样不行
const name = './logo.png';
new URL(name, import.meta.url);

// ✅ 必须这样
new URL('./logo.png', import.meta.url);

构建工具的通用约束

• 把 import.meta.url 替换成绝对资源路径字符串
• 把 new URL(relative, import.meta.url) 整体替换成构建后的资源 URL
• 无法静态分析的动态用法会直接警告

这套约定保证了代码在不同部署环境（ESM、CJS、IIFE）下都能正常跑。果然，各家框架偷偷约好了一起玩这套

总结

一条主线贯穿全文：

import.meta 是 ECMAScript 规范定义的元属性，由宿主环境决定具体属性内容；import.meta.url 是所有宿主环境都支持的、表示当前模块绝对 URL 的共同约定。

理解这一点后，不管是写浏览器端代码、Node.js 工具链，还是配置 Vite 构建，都能对 import.meta.url 的来龙去脉心中有数。

下次面试官问起来，你可以淡定地甩一句："这是 ECMAScript 的元属性，由 HostGetImportMetaProperties Hook 实现，各家注入的属性不同……" 然后看他目瞪口呆的样子 😄

参考

• ECMAScript Language Specification — Meta Properties
• WHATWG HTML Spec — HostGetImportMetaProperties
• Node.js — import.meta
• Vite — Static Asset Handling

答应大家下次要分享前端技术在移动端、跨端领域的应用，所以这次给大家带来 RN 和 Expo 的技术分享。

相信大家刚刚开始看 React Native 和 Expo 的时候，和我一样一直有一个问题：

为什么我写的是 React 组件，最后却能直接在手机上显示出来？

这个问题看起来不复杂，但真要往下追，就会牵扯到很多东西。React、React Native、Expo、Metro、iOS、Android，这些概念如果放在一起看，很容易让人混掉。

所以今天我主要想讲清楚的是：React Native 到底是怎么把前端代码渲染到手机上的，Expo 又在这个过程中负责什么。

React Native 的是干啥滴

首先，什么是 React Native 的渲染？

React Native 的本职工作，是把 React 代码变成移动端的原生视图。它不是在手机上跑一个网页，也不是把 HTML 页面包起来再显示出来，而是把 JSX 描述的结构，转成 iOS 和 Android 能直接处理的原生组件。

也就是说，开发者写出来的并不是最终画面本身，而是一份 UI 描述。React Native 负责把这份描述翻译成平台原生控件，最后再由 iOS 和 Android 把界面画到屏幕上。

这一点和 Web 里的 React 很不一样。Web React 最终面对的是 DOM，而 React Native 面对的是原生视图。两者都使用 React 的写法，但落到的目标完全不同。

React Native 里的 UI 不是 DOM

那么其次，React Native 和 Web React 的区别到底在哪里？

最直接的区别，就是它们最终渲染的目标不同。Web 上的 React 需要把组件渲染到 DOM 里，React Native 需要把组件渲染到原生控件里。

例如一个输入框，在 iOS 上会对应到 UITextField 一类的原生控件，在 Android 上会对应到对应平台的输入组件。开发者写的是同一套 React 组件，但真正执行渲染的是不同平台自己的 UI 系统。

这也是 React Native 和 Web 最大的差异之一。React Native 并没有把移动端做成一个网页，它只是让开发者用 React 的方式去描述原生界面。

渲染流程

那么接下来就是 React Native 的渲染流程。

React Native 现在把这个过程拆成三个阶段：Render、Commit、Mount。

如果只看这三个词，会觉得它们都很抽象。但如果把它放到一次真实的状态更新里看，事情就清楚很多了。

比如页面上有一个按钮，点击以后计数加一。这个动作发生之后，React 先会知道“状态变了”，然后开始重新计算这个组件树应该长成什么样。这个时候还没有真正去改屏幕上的内容，先改的是内部结构。

React Native 做的，就是把这次变化从 JavaScript 侧一路传到原生侧。它不是一下子把整块界面重画一遍，而是先把新的结构算出来，再把需要更新的部分提交出去，最后挂到原生视图上。

function Counter() {
  const [count, setCount] = useState(0)

  return (
    <View>
      <Text>{count}</Text>
      <Button title="add" onPress={() => setCount(count + 1)} />
    </View>
  )
}

当 count 变化以后，React 会重新计算这段 JSX 对应的 React Element Tree。
React Native 再把这个新树和上一次的树比较，找出需要更新的地方。最后它把这些变化翻译成原生层能执行的最小变更。

这个过程里，真正重要的不是“重新画一遍”，而是“只更新发生变化的那部分”。

Render

首先是 Render。

这一步发生在 JavaScript 侧。React 先根据组件和状态变化，生成一棵 React Element Tree。在新架构里，这棵树还会对应到 C++ 层的 Shadow Tree。

这个阶段做的是结构计算。页面里有哪些组件，它们之间怎么嵌套，属性是什么，状态更新以后应该生成什么样的新树，这些事情都在这个阶段处理。

如果页面里有多个组件，React 并不会因为某一个地方更新了，就傻乎乎地把整个页面重新拼一遍。它会先根据新的状态，算出新的结构，然后和上一次的结构做比较。这样一来，哪些地方变了，哪些地方没变，就都能被识别出来。

所以 Render 阶段更像是在整理一份新的 UI 草稿。它还没真正碰到屏幕，但已经把接下来要显示什么内容算好了。

这里还可以顺手看一下树的样子。比如下面这个结构：

<View>
  <Text>Hello</Text>
</View>

React 侧会先得到对应的元素树，C++ 侧再生成 Shadow Tree。Shadow Tree 里保存的是组件层级、样式信息和后续布局所需的数据。它不是最终的屏幕树，但它是后面布局和挂载的基础。

Commit

然后是 Commit。

当新的树准备好之后，React Native 会把这棵树提交给后续阶段处理，并触发布局计算。这个阶段还没有真正把内容画到屏幕上，但已经把下一次要挂载的内容准备好了。

这里的重点不是“有没有画出来”，而是“这份更新是不是已经准备好交给原生层了”。Commit 发生以后，React Native 会知道这次更新可以进入下一步了，接下来就是把布局结果和视图变化落到原生对象上。

如果把 Render 当成“写草稿”，那 Commit 就是“把草稿交给排版和印刷部门处理”。这一步不负责最后展示，但它决定了接下来的内容能不能顺利落到屏幕上。

Commit 阶段主要做两件事：布局计算和 tree promotion。

布局计算会把每个 Shadow Node 的尺寸和位置算出来。React Native 这里使用的是 Yoga。Yoga 处理的是一棵 layout tree，开发者在样式里写的 flex、width、height、padding、margin 等信息，都会被送进这套布局系统里。

例如：

<View style={{ flex: 1 }}>
  <View style={{ height: 100 }} />
  <View style={{ flex: 1 }} />
</View>

这段代码里，外层容器先拿到整块可用空间，内部两个子节点再按照各自的约束分配位置和大小。这个过程不是浏览器的 CSS 布局引擎在做，而是 Yoga 在做。

布局结果算出来以后，新的 Shadow Tree 会被提升为 next tree，等待 Mount 阶段被真正挂载。

Mount

最后是 Mount。

这一步会把已经计算好的结果真正挂到原生视图上。到了这里，iOS 或 Android 才会把界面显示到屏幕上。

Mount 阶段做的事情，已经很接近“把页面真正摆出来”了。原生视图被创建、更新、插入、删除，最后形成用户在手机上看到的那一帧界面。前面所有的计算，到了这里才真正变成了肉眼可见的内容。

也就是说，从开发者写代码，到用户看到界面，中间并不是直接“渲染一下”就结束了，而是经历了结构生成、提交、布局、挂载这一整套过程。

这套过程看起来繁琐，但它做的事情其实很明确：先把 UI 的结构算清楚，再把结构交给布局系统，最后把结果落到平台自己的原生视图上。

Mount 阶段还会做 tree diffing。React Native 会把“上一次已经挂载的树”和“这一次准备挂载的新树”做比较，然后计算出一组原子级别的 mutation，例如 createView、updateView、removeView 之类的操作。

这个 diff 过程是在 C++ 里完成的。它的目标很直接：不要把整棵树推倒重来，只把真正变化的部分转成原生操作。

previous tree  ->  diff  ->  mutation list  ->  host views

如果一个节点只是改了背景色，React Native 不会把整页重新创建一遍，它只会生成对应的更新操作。
如果一个节点根本没有变化，diff 之后就不会产生多余的原生指令。

View Flattening 也是 Mount 阶段里很重要的优化。React 的组件树经常会比最终需要显示的原生视图树更深，其中有不少节点只是为了组织布局，并不真正负责显示内容。View Flattening 会把这类节点折叠掉，减少不必要的原生视图创建。

这也是为什么 React Native 的渲染链路里，结构树、布局树和最终的 host view tree 并不是一回事。它们的层级不同，职责也不同。

到这里，React Native 这一侧的流程已经比较完整了，但这些结果还只是“准备好”，真正落到屏幕上，还要看原生平台怎么接住这些更新。

这些更新在原生侧是怎么生效的？

如果只停留在 React 树这一侧，很多细节还是不够完整。真正把东西画到屏幕上的，还是原生平台自己的视图系统。

在 React Native 里，最基础的几个组件都对应着平台自己的原生控件。

• View 会对应到 iOS 的 UIView，在 Android 上通常对应 View 或 ViewGroup
• Text 由平台的原生文本渲染系统处理
• TextInput 会接到平台原生输入控件
• Image 会走平台自己的图片解码、缓存和绘制链路

所以当你写下面这种代码的时候：

<View style={{ padding: 12, backgroundColor: '#fff' }}>
  <Text>Hello</Text>
  <TextInput placeholder="type here" />
</View>

React Native 并不是把这段 JSX 变成某个中间页面对象，而是把它拆成一组原生视图操作：

• 创建一个容器视图
• 给容器设置 padding 和背景色
• 创建文本节点并交给原生文本渲染
• 创建输入框并连接键盘、焦点和输入事件

这就是 React Native 最核心的一点：JS 层写的是声明式 UI，真正执行的是原生视图系统。

原生视图管理

在原生侧，每个平台都有自己的视图管理方式。

Android 上，常见的是通过 ViewManager 或 SimpleViewManager 来创建和管理原生视图。这个管理器负责把 React 传来的 props 更新到原生控件上，也负责把原生事件再发回 JavaScript。

iOS 上则会通过 UIView、UIViewController、属性 setter、事件回调这些方式完成同样的工作。React Native 最终要做的事情，就是把 JavaScript 侧的属性更新，映射成平台侧的对象状态变化。

例如一个自定义图片组件，原生侧一般会做这些事：

1. 创建一个原生图片视图
2. 接收 source、resizeMode、tintColor 之类的属性
3. 在属性变化时更新原生控件
4. 在点击、加载完成、失败等节点上向 JS 发事件

这样一来，JS 侧的一个 <Image /> 组件，就真正和平台图片视图接上了。

Android 侧的代码通常会长得像这样：

class MyBoxViewManager : SimpleViewManager<View>() {
  override fun getName() = "MyBox"

  override fun createViewInstance(context: ThemedReactContext): View {
    return View(context)
  }

  @ReactProp(name = "color")
  fun setColor(view: View, color: Int) {
    view.setBackgroundColor(color)
  }
}

这个例子很简单，但结构已经很完整了：创建视图、接收属性、更新原生对象。
React 侧传来的 props，就是这样一点一点落到原生控件上的。

iOS 侧也类似，通常会创建一个 UIView 子类，然后通过属性更新方法把 JS 侧的值写进去，再把需要的事件回传给 JS。

事件是怎么回来的

原生侧不只是接收更新，还会主动把事件发回来。

比如点击、滑动、滚动、输入变化、布局完成，这些事情很多都先发生在原生侧，然后再回到 JavaScript 侧处理。常见的事件包括：

• onPress
• onScroll
• onChangeText
• onLayout

其中 onLayout 很值得提一下。它不是简单的“组件加载完成”，而是原生布局结果已经算出来以后回传给 JS。很多依赖尺寸的逻辑，比如弹层定位、动态高度列表、测量元素位置，都会用到这个事件。

如果需要主动测量一个视图，React Native 也提供了 ref 相关能力。开发者拿到一个原生组件引用以后，可以读取它的边界信息，或者在老接口里调用 measure。这类能力通常会用在手势定位、弹窗锚点、滚动吸顶这些场景里。

原生模块

除了视图，React Native 还有原生模块。

原生模块解决的是另一类问题：有些功能本来就应该交给平台原生 API 去做，比如相机、通知、定位、文件系统、加密、数据库、传感器这些东西。

如果写纯 JS，这些能力要么做不到，要么性能不够好，要么对系统集成不完整。原生模块允许 JavaScript 直接调用原生代码，让这些能力以模块的方式暴露出来。

例如一个相机模块，JS 侧可能只是调用 openCamera()，真正执行的是 iOS 的 AVFoundation 或 Android 的相机 API。React Native 只负责把调用路由到正确的平台代码上。

Expo 也提供了自己的原生模块体系。Expo Modules API 允许你用 Swift 和 Kotlin 写原生能力，然后把它暴露给 JavaScript。这样做的好处是两端写法比较统一，而且和新架构兼容得更好。

例如一个简单的原生视图模块，在 Expo 侧可以直接声明一个原生组件，并定义属性和方法。概念上和 React Native 的 native component 很接近，只是写法更现代一些。

import ExpoModulesCore

public class CounterModule: Module {
  public func definition() -> ModuleDefinition {
    Name("Counter")

    Function("increment") { (value: Int) in
      return value + 1
    }
  }
}

class CounterModule : Module() {
  override fun definition() = ModuleDefinition {
    Name("Counter")

    Function("increment") { value: Int ->
      value + 1
    }
  }
}

这种模块很适合拿来做简单的原生能力验证。
如果你以后要把更复杂的原生能力接进来，比如传感器、图片处理、加密算法、系统设置页入口，这种方式都是基础。

讲到这里，原生侧的视图、事件和模块基本都串起来了。再往下看，就能明白为什么 React Native 不能把所有事都塞到一个线程里做。

为什么要拆线程

React Native 之所以要把这些过程拆开，一个很重要的原因，就是移动端不能把所有事情都塞到一个线程里做。

React Native 的线程模型里，最关键的是两个线程：

• UI thread，负责真正操作原生视图
• JavaScript thread，负责执行 React 逻辑和更新计算

这样拆开以后，JS 侧的计算不会直接阻塞原生界面，原生视图的更新也不会随便被 JS 打断。对于移动端来说，这一点很重要，因为用户对界面的响应速度要求很高。

如果所有渲染和交互都放在一个线程里，代码稍微复杂一点，界面就很容易卡住。React Native 现在的线程模型，本质上就是为了避免这个问题。

这里还有一个很重要的限制：原生视图只能在 UI thread 上修改。React Native 不能随意跳过这个规则，它必须遵守平台本身的线程约束。

线程拆开以后，问题就从“怎么画”变成了“怎么在不同层之间传递变化”。这也就是旧架构和新架构要解决的事情。

旧架构和新架构

然后再看 React Native 的旧架构和新架构。

早期的 React Native 最常提到的是 Bridge。这个阶段里，JavaScript 和原生之间的通信方式更像是消息传递。JS 侧先把操作序列化，再通过桥接发给原生，原生收到以后再执行。

这种方式在最开始能工作，也足够清晰，但它有几个很明显的问题：

• 序列化和反序列化会消耗性能
• JS 和原生之间的通信不够直接
• 某些同步能力做起来比较别扭
• 调度空间有限

所以 React Native 后来开始重构底层架构。新架构里比较核心的几个东西是 Fabric、JSI、TurboModules 和新的事件循环。

这些改动带来的变化很直接。原来的桥接方式更偏向异步消息传递，新架构则更强调 JS、C++ 和原生之间的直接协作。这样做之后，渲染链路更短，更新调度更灵活，也更容易支持现代 React 的能力。

这也是为什么现在再看 React Native 的渲染原理，不能只盯着 Bridge 看。Bridge 只是它曾经的一种实现方式，不是现在全部的样子。

讲完底层渲染和通信方式以后，Expo 的位置也就更清楚了。它不是渲染引擎，但它决定了你怎么把这些原生能力接进项目里。

Expo 在这里负责什么

说到 Expo，很多人第一反应会觉得它是不是也参与了渲染。

其实不是。Expo 不负责把 UI 画到屏幕上，这件事还是 React Native 自己做。Expo 主要负责的是开发流程和工程管理。

它管的事情包括：

• 项目怎么初始化
• 原生工程怎么生成
• 原生模块怎么自动链接
• 开发时怎么快速预览
• 真机和模拟器怎么运行

Expo Go

先说 Expo Go。

Expo Go 可以看成一个现成的原生容器。开发者把 JavaScript bundle 连上去，就能很快看到项目效果。它很适合快速验证，但它的原生能力是固定的，不能随便加入新的原生库。

所以 Expo Go 更适合做早期开发和验证。它把启动成本压得很低，但也限制了你能改动的范围。

Development Build

如果项目需要更完整的原生能力，就需要用 development build。

这时候得到的不是公共容器，而是属于自己的 Expo 客户端。它可以包含自定义的原生配置、原生模块和更完整的开发能力。

这个阶段很重要，因为一旦项目开始依赖更多原生能力，Expo Go 就不够用了，development build 才是更接近真实产品的开发方式。

Prebuild

Expo 的 prebuild 会根据配置生成 android/ 和 ios/ 目录。

这说明 Expo 并不是在绕开原生工程，而是在把原生工程的生成过程自动化。它降低的是维护成本，不是替代 React Native 的渲染系统。

如果把 React Native 看成渲染引擎，那 Expo 更像是围绕这个引擎的一整套开发工具。

也正因为这样，Expo 的价值不在于改写渲染过程，而在于把原生工程的复杂度提前处理掉。

从代码到屏幕

前面把 Render、Commit、Mount、原生侧和线程模型都拆开看过一遍以后，再把它们合起来，链路就很清楚了。

如果把整个链路串起来，大概可以写成这样：

JSX
  -> React Element Tree
  -> Shadow Tree
  -> Layout Calculation
  -> Mount to Native Views
  -> Screen

更直接一点说就是：

开发者先写出界面结构，React 负责生成组件树，React Native 负责把这棵树交给布局系统和原生平台，最后由 iOS 或 Android 把结果真正显示出来。

所以 React Native 的目标不是做一个跨平台网页框架，而是让开发者用 React 的方式去驱动移动端原生 UI。

把前面的内容收回来，其实整个链路就是这件事：前端写结构，React 算树，原生平台负责把结果画出来。

这也正好把前面的所有概念扣在了一起。React Native 负责的是渲染，Expo 负责的是把这套渲染流程放进更好用的开发环境里。

React Native 和 Expo 的关系

最后再说一下 React Native 和 Expo 的关系。

这两个东西本来就不在同一层。

React Native 解决的是 UI 怎么渲染到原生平台上，Expo 解决的是开发者怎么更轻松地把项目跑起来、构建起来、维护起来。

把它们放在一起看，最容易混淆的地方其实也就在这里：一个管界面怎么落到屏幕上，一个管项目怎么落到设备上。

它们不是竞争关系，也不是替代关系，而是上下游关系：

• React Native 决定渲染机制
• Expo 决定开发体验

所以你用 Expo 开发 React Native 应用的时候，底层依然还是 React Native 的渲染逻辑在工作，只是 Expo 帮你把很多原生工程的细节收掉了。

把这两个东西放在一起看，就不会再把它们当成同一层的概念了。

总结

如果把前面的内容按顺序排一下，大概就是这样：

• React 先生成 UI 结构
• React Native 把结构交给布局、diff 和原生挂载
• 原生平台负责把最终结果显示出来
• Expo 负责把整个开发和构建流程管理好

如果把这件事压缩成一句话，我会这么说：

React Native 负责把 React 的声明式 UI 变成原生视图，Expo 负责把这条链路包装成更省心的开发流程。

理解了这一点之后，再去看 Expo Go、development build、prebuild、Fabric、JSI 这些名词，脑子里就不会乱了。它们不是一堆孤立的术语，而是同一条链路上的不同节点。

前面这一套如果能说明白，后面再看别的跨端框架或者原生能力接入，思路基本也就通了。

这里再给下次分享挖个坑吧，下次分享大家更想了解 React 渲染网页的原理呢？还是其他 移动端 / 跨端 技术呢？还是更想了解一些后端相关知识呢？

参考链接

• React Native Render, Commit, and Mount
• React Native Threading Model
• React Native Fabric
• React Native New Architecture is here
• Expo development builds introduction
• Expo use a development build
• Expo Continuous Native Generation
• Expo React Native's New Architecture

这篇分享主要让大家了解一下 js 中的 oop 与 fc，通过结合原理学习语法来提高大家的学习效率、加深大家对知识的理解。

面向对象编程（OOP）

首先，什么是 OOP？

Object-oriented programming (OOP) is a programming paradigm based on the object1 – a software entity that encapsulates data and function(s). An OOP computer program consists of objects that interact with one another.23 A programming language that provides OOP features is classified as an OOP language but as the set of features that contribute to OOP is contended, classifying a language as OOP and the degree to which it supports or is OOP, are debatable. As paradigms are not mutually exclusive, a language can be multi-paradigm; can be categorized as more than only OOP.
面向对象编程（OOP）是一种基于对象的编程范式——一个封装数据和函数的软件实体。一个面向对象的计算机程序由相互交互的对象组成。 2 3 提供面向对象特性的编程语言被归类为面向对象语言，但由于构成面向对象特性的特征集合存在争议，将一种语言归类为面向对象语言以及它支持或是否面向对象的程度是存在争议的。由于范式不是相互排斥的，一种语言可以是多范式；可以被归类为不仅仅是面向对象。 以上内容摘自 Wikipedia

面向对象把程序看成由 对象 Object 组成，每个对象就像现实中的事物，有：

• 属性 Attributes（数据）
• 方法 Method（行为、能做的事）

根据对象所具有的属性与方法的不同，可以将对象进行 分类，这样就引入了 OOP 中 类 Class 的概念。类描述了对象所具有的属性与方法，但不关心其值。

而根据分类方式的细致程度不同，可以将一个类里的对象进行更细致的分类，这就引入了 子类 & 父类 的概念。

非常经典且简单的例子： 我定义 动物 Animal 为一个类，那么就可以细分为 猫 Cat 和 狗 Dog 等等很多个子类。Animal 就是 Cat 和 Dog 的父类。而对象就是具体某只猫，比如这只：

而 Animal 这一类对象都具有的 属性 和 方法 又对应什么呢？也很简单，首先属性例如：名字、年龄……方法例如：进食、呼吸……

Animal 的子类 Cat 和 Dog 一定具有他们父类的所有属性与方法，毕竟没有什么生物不需要进食和呼吸……

但特殊的地方在于：Cat 和 Dog 作为子类，可以具有父类没有的属性和方法，比如猫可以具有其特殊的方法：哈气，狗也可以有其特殊的方法：口也💩。

其他更加深入的内容就不再多讲了，感兴趣的同学可以私下去深入学习，或者来找我探讨。总之，OOP 的核心思想是 用对象来模拟现实世界，通过对象之间的交互完成程序功能。

函数式编程 （FC）

那么其次，什么是函数式编程？

In computer science, functional programming is a programming paradigm where programs are constructed by applying and composing functions. It is a declarative programming paradigm in which function definitions are trees of expressions that map values to other values, rather than a sequence of imperative statements which update the running state of the program.
在计算机科学中，函数式编程是一种编程范式，其中程序通过应用和组合函数来构建。它是一种声明式编程范式，其中函数定义是映射值到其他值的表达式树，而不是更新程序运行状态的命令式语句序列。 以上内容摘自 Wikipedia

函数式编程（Functional Programming，FP）是一种把 “函数”作为核心 的编程思想，强调用表达式计算结果，而不是通过修改状态来完成任务。

你可以把它理解为： 用数学函数的方式写程序，让数据“流动”而不是被反复修改。

它有几个关键特点：

1. 不可变性（Immutable）：数据一旦创建就不修改，所有操作都会返回新的数据。更容易推理、减少 Bug。
2. 纯函数（Pure Function）：同样的输入一定得到同样输出。且不依赖外部变量、不修改外部状态。可测试性强、行为可预测。
3. 函数是一等公民（First-Class Citizens）：函数可以像变量一样传来传去，也能作为参数和返回值。
4. 高阶函数（Higher-Order Functions）：可以接收函数作为输入、或返回一个函数，例如 map, filter, reduce。

总之，函数式编程就是用纯函数 + 不可变数据来写程序，让逻辑更简洁，状态更可控。

面向对象与函数式编程这两种编程思想在 JavaScript 中被巧妙地融合，并在 js 的语法中体现，接下来我们就来看看 js 中的这两种思想。

js中的相关特性

我们需要先对js这种语言中的各种特性有所了解，才能利用范式这种工具更好的对我们开发的软件进行组合。 这一部分主要会参考ecma262。

js语言的设计

Brendan Eich开发了js。他在这篇文章提到了js设计过程中的一些问题。
Netscape需要在浏览器中内置一种脚本语言，根据领导要求，首先需要像java(Look like Java,因此很多语法和java类似),而作者本人偏向于scheme，因此最后在新的语言中选择了和Scheme一样的一等函数以及和Self一样的prototype作为主要组成。受java影响，有了原始类型和对象的区分，比如string和String。

以上设计加上后来的发展就成了现在的js。

js特性概述

在js中的数据结构分为两种，原始类型和对象，js的对象创建并不是基于class的，而是有很多方式，比如字面量或者构造函数，每个构造函数都有一个prototype属性用于实现基于原型（prototype-based）的继承。一个构造函数的prototype还有一个constructor引用指向构造函数本身，当实现继承时，这个属性可能会改，按照惯例需要修正，但不是必须的（关于constructor参考这里）。

说起构造函数，这里补充一点相关概念，函数是一种特殊的对象，含有internal method [[Call]],因此可以通过函数调用来执行相关代码，而构造函数又是一种特殊的函数，含有internal method [[Construct]],可以通过new或super调用创建对象。

js中的对象

原型链

每一个通过构造函数创建的对象都有一个指向构造函数prototype属性的隐式引用(可以用__proto__访问但不推荐)，而这个prototype本身可能也有一个非null的引用指向它的prototype,等等，这就被称为原型链。当访问对象的一个属性时，会首先从该对象本身查找，如果找不到就会沿着原型链依次查找，直到找到或者找到尽头发现没有，原型链上的属性可以被覆盖。

相较基于class继承的语言，通常来说，状态被实例拥有，方法被class拥有，继承的只有结构和行为(behavior)，而js这一切都是可以继承的。这里的行为是方法整体决定的，如果没有方法，一个class将只有结构。

原型链的尽头为null，要明确一个对象的原型链到底包括什么，这里可以大概分为以下

• 如果是个new Object()或字面量{},其原型链为

var obj={}
//原型链 obj=>Object.prototype=>null

• 如果是new调用了其他构造函数，包括自定义的或者内置的（比如Array，内置构造函数不一定需要new调用，比如也可以通过字面量或者不使用new，比如[]或Date()）,这里以Array为例

var arr =[]
//arr=>Array.prototype=>Object.prototype=>null
//如果是自定义构造函数也一样
var P=function(){}
var p=new P()
//p=>P.prototype=>Object.prototype=>null

• 如果在上一种情况下,延长原型链,其实就是怎么样实现继承

//1. 使用Object.create()
var q=Object.create(p)
// q=>p

//2. 直接修改构造函数的prototype
function Q(){}
Q.prototype=p
var q=new Q()
//q=>p
//3. 通过Object.setPrototypeOf(obj, prototype)设置__proto__属性,可以直接修改原型链，这个操作很浪费性能，少用
function P(){
    this.b=1
}
function Q(){
    this.a=2
}
var q=new Q()
Object.setPrototypeOf(q,P.prototype)
// q=>P.prototype
//4. 使用call和apply借用构造函数时，和原型无关
var P=function(v){
    this.a=v
}
function Q(v){
    P.call(this,v)
}
var q=new Q(2)
// q=>Q.prototype=>Object.prototype=>null

我们可以通过object instanceof constructor 判断一个构造函数的prototype是否在指定对象的原型链中

function Q(){
    this.a=2
}
var q=new Q()
console.log(q instanceof Q)
console.log(q instanceof Object)

可以通过Object.getPrototypeOf(object)获得对象的__proto__属性

Object

Object.prototype上有一些属性和方法被其他所有对象继承，在特定对象继承过程中可能会对某些字段重写。
另外Object上还有很多静态方法用于处理关于对象的各种操作，具体请参考mdn

js中的函数

在js中所有函数都是Function的实例，包括Object和Function本身,乃至各种内置构造函数（比如Array）,因此有

Function.__proto__===Function.prototype//true
Function.prototype.__proto__===Object.prototype//true,即Function instanceof Object
//原型链 Function=>Function.prototype=>Object.prototype,以下类似

Object.__proto__===Function.prototype//true，即Object instanceof Function
Array.__proto__===Function.prototype //true

function a(){}
a.__proto__===Function.prototype//true

可见，所有函数的原型链到达Object.prototype之前需要先经过Function.prototype,一个函数是一个对象，更是一个函数。

Function

Funciton.prototype上有一些方法值得我们关注

• func.apply(thisArg, [argsArray])
• function.call(thisArg, arg1, arg2, ...)
• function.bind(thisArg[, arg1[, arg2[, ...]]])

其中前两个在一个对象的上下文应用另一个对象的方法，第三个用于修改上下文，其余参数会在返回的函数调用时使用

js的函数式编程

在具体的了解函数式编程之前，这里先了解一些概念，参考Composing Software。

概念

Pure Function

一个纯函数是一个函数，符合以下特点

• 相同的输入总是返回相同输出
• 没有副作用

纯函数在函数式编程中很重要，但是实际的开发中，函数或多或少会有一些副作用，比如数据获取和操作dom。

Function Composition

函数复合是将两个或多个函数按照顺序生成一个函数或者执行操作。

Shared State

共享数据可以是变量、对象或内存空间。使用共享数据的一个问题是为了了解一个函数的副作用，需要知道每个共享数据的操作历史，比如对一个用户信息在不同终端的修改会发生冲突，因此在flux中要使用单向流。
另一个问题是对共享数据的操作顺序也会造成不同结果，比如四则运算。

Immutability

一个不可变对象是创建后就不能改变，但是js在语言层面只提供了原始类型的不可变性，对对象并不提供这种特性，即使使用Object.freeze()等方法也只能冻结某个层级的对象修改，要想使用不可变数据，可以使用第三方库，比如Immer。
不可变对象是函数式编程的核心概念，没有不可变性，程序中的数据流就会不可控，应该使用原数据生成新数据，而不应该修改原来的数据。

在实际的操作中，对于一个特定的数据，不可变性和不同享，至少要满足一个。

Side Effects

副作用指的是除了对输出结果操作以外其他的操作，比如打印日志或修改dom，副作用在函数式编程中应该避免，即将副作用和数据流处理分开。

Reusability Through Higher Order Functions

高阶函数是任何以函数作为参数或返回函数的函数，经常用于

• 使用回调函数、promise或monads对动作、副作用或异步数据流进行抽象或隔离。
• 为操作各种类型的变量创建工具函数
• 为了复用或函数组合而创建偏函数或柯里化
• 将一系列输入的函数串联返回一个函数组合

Containers, Functors, Lists, and Streams

这里包括上面提到的monads，可以参考Functors, Applicatives, And Monads In Pictures

一个functor数据结构可以用于映射数据，比如 [1,2,3].map(x => x *2),换句话说，它是一个容器，会为内部的数据应用一个函数，当看到这个词时应该想到mappable
在这里被映射的是一个数组，只要提供map api，其他数据结构应该也可以，一个按顺序处理的list可以看作是一个stream。

Declarative vs Imperative

函数式编程是一种声明式范式，声明式编程会将流控制过程抽象，而不是用一行行代码描述怎么做，对应的是命令式。 比如函数doubleMap命令式的写法

const doubleMap = numbers => {
const doubled = [];
for (let i = 0; i < numbers.length; i++) {
	doubled.push(numbers[i] * 2);
   }
 return doubled;
 };
 console.log(doubleMap([2, 3, 4])); // [4, 6, 8]

声明式的写法

const doubleMap = numbers => numbers.map(n => n * 2);

 console.log(doubleMap([2, 3, 4])); // [4, 6, 8]

总结

一个函数式编程应该有以下特征

• 纯函数，而不是共享数据和副作用
• 不可变，而不是可变数据
• 函数组合，而不是命令式流控制
• 泛型工具而不是对某些数据的特定方法
• 声明式，而不是命令式
• 表达式，而不是语句

在js中的函数式应用可以参考A GENTLE INTRODUCTION TO FUNCTIONAL JAVASCRIPT系列，最终目的就是将应用中的整个逻辑切分到不同的函数中，然后将函数组合，完成最终的任务。
在具体处理过程中注意函数式编程的各种特征。

常见的函数组合方式包括

• compose,又称为pipe

　const compose = (...functions) => flowIn => functions.reduceRight( ( acc,f ) => f(acc), flowIn )

• curry,这里实现一个具体的柯里化

const add = a => b => a + b;
add(1)(2)

js的面向对象编程

js的以原型为基础的继承不太适合实现面向对象的封装、继承和多态，而es6在语言层面实现了class语法，可以很方便的采用其他语言实践总结而来的设计模式和设计原则，这里建议采用ts,具体可参考ts实现的23种设计模式和设计原则

无论采用何种范式，最终都是要将各个模块组合成我们的软件。

参考链接

本篇博客中部分内容摘自以下博文：

• 说起编程范式我们应知道什么
• js中的面向对象编程和函数式编程

什么是 Storybook

Storybook 是一个开源工具，用于独立构建、测试和文档化 UI 组件。它为开发者提供了一个独立于主应用程序的环境，使组件开发更加高效和有条理。

主要特点

• 隔离环境：在应用程序上下文之外开发 UI 组件
• 组件驱动开发：专注于一次构建一个组件
• 可视化测试：直观地检查组件在不同状态下的外观
• 交互式文档：创建活跃的、可交互的组件文档
• 插件生态系统：通过众多插件扩展功能

使用场景

• 创建设计系统或组件库
• 开发复杂的 UI 界面
• 测试组件的边缘情况
• 协作开发（设计师和开发者）

项目集成

Storybook 的 cli 貌似不太好用，这边提供一个将 Storybook 与 Vite 项目集成的方案。

环境要求

• bun
• React ≥ 16.8
• Vite ≥ 4.0
• Storybook ≥ 8.0

创建项目

$ bun create vite
reused 0, downloaded 1, added 1, done
|
o  Project name:
|  storybook-demo
|
o  Select a framework:
|  React
|
o  Select a variant:
|  TypeScript + SWC
|
o  Scaffolding project in D:\Projects\storybook-demo...
|
—  Done. Now run:

  cd storybook-demo
  bun install
  bun run dev

$ bun install
...

项目结构：

$ tree
.
|-- README.md
|-- eslint.config.js
|-- index.html
|-- package.json
|-- public
|   `-- vite.svg
|-- src
|   |-- App.css
|   |-- App.tsx
|   |-- assets
|   |   `-- react.svg
|   |-- index.css
|   |-- main.tsx
|   `-- vite-env.d.ts
|-- tsconfig.app.json
|-- tsconfig.json
|-- tsconfig.node.json
`-- vite.config.ts

3 directories, 15 files

vite create 默认没有创建库项目的选项，下面我们将这个项目改造成库项目。

先删掉 src/ 下的 css、ts 和资源文件，创建一个空的 index.ts 文件，现在项目结构长这样：

$ tree
.
|-- README.md
|-- eslint.config.js
|-- index.html
|-- package.json
|-- src
|   |-- index.ts
|   `-- vite-env.d.ts
|-- tsconfig.app.json
|-- tsconfig.json
|-- tsconfig.node.json
`-- vite.config.ts

2 directories, 11 files

修改 vite.config.ts 文件，将项目类型改为库项目：

import { defineConfig } from 'vite'

import react from '@vitejs/plugin-react-swc'

// https://vite.dev/config/
export default defineConfig({
  plugins: [react()],
  // 新增以下配置
  build: {
    lib: {
      entry: 'src/index.ts',
      name: 'my-components',
      formats: ['es'],
    }
  }
})

记得安装一下 sass 依赖，我们接下来要使用 scss 编写样式：

$ bun add -D sass-embedded
Packages: +20
++++++++++++++++++++
Progress: resolved 483, reused 403, downloaded 7, added 20, done

devDependencies:
+ sass-embedded 1.86.3

Done in 7.2s

现在就是一个 React 库项目咯，可以开始集成 Storybook 了。

集成 Storybook

安装 Storybook：

// 安装 Storybook 时会调用 npm 安装一些包，如果 npm 环境有问题可以加上 --package-manager=bun
$ bun create storybook@latest
╭───────────────────────────────────────────────────────╮
│                                                       │
│   Adding Storybook version 8.6.12 to your project..   │
│                                                       │
╰───────────────────────────────────────────────────────╯
√ What do you want to use Storybook for? » Documentation: MDX, auto-generated component docs, Testing: Fast browser-based component tests, watch mode
 • Detecting project type. ✓
Installing dependencies...

Lockfile is up to date, resolution step is skipped
Already up to date
Done in 678ms
 • Adding Storybook support to your "React" app • Detected Vite project. Setting builder to Vite. ✓

  ✅ Getting the correct version of 0 packages
. ✓
Installing dependencies...

Lockfile is up to date, resolution step is skipped
Already up to date
Done in 750ms
> npx storybook@8.6.12 add @storybook/experimental-addon-test@8.6.12
Verifying @storybook/experimental-addon-test
Installing @storybook/experimental-addon-test@^8.6.12
Adding '@storybook/experimental-addon-test@8.6.12' to the "addons" field in .storybook\main.ts
Running postinstall script for @storybook/experimental-addon-test

╭ 👋 Howdy! ─────────────────────────────────────────────────────────────────╮
│                                                                            │
│   I\'m the installation helper for @storybook/experimental-addon-test       │
│                                                                            │
│   Hold on for a moment while I look at your project and get it set up...   │
│                                                                            │
╰────────────────────────────────────────────────────────────────────────────╯

› Configuring Playwright with Chromium (this might take some time):
  npx playwright install chromium --with-deps

╭ 🚨 Oh no! ──────────────────────────────────────────────────────────────╮
│                                                                         │
│   Found an existing Vitest setup file:                                  │
│   D:/Projects/storybook-demo/.storybook/vitest.setup.ts                 │
│                                                                         │
│   Please refer to the documentation to complete the setup manually:     │
│   https://storybook.js.org/docs/writing-tests/test-addon#manual-setup   │
│                                                                         │
╰─────────────────────────────────────────────────────────────────────────╯

╭──────────────────────────────────────────────────────────────────────────────╮
│                                                                              │
│   Storybook was successfully installed in your project! 🎉                   │
│   Additional features: Documentation, Testing                                │
│                                                                              │
│   To run Storybook manually, run bun run storybook. CTRL+C to stop.         │
│                                                                              │
│   Wanna know more about Storybook? Check out https://storybook.js.org/       │
│   Having trouble or want to chat? Join us at https://discord.gg/storybook/   │
│                                                                              │
╰──────────────────────────────────────────────────────────────────────────────╯

Running Storybook

> storybook-demo@0.0.0 storybook D:\Projects\storybook-demo
> storybook dev -p 6006 "--initial-path=/onboarding" "--quiet"

@storybook/core v8.6.12

info => Serving static files from D:\Projects\storybook-demo\node_modules\.cache\storybook\default\coverage at /coverage
info Using tsconfig paths for react-docgen
17:58:40 [vite] (client) hmr update /@id/__x00__virtual:/@storybook/builder-vite/vite-app.js

这里会自动打开 Storybook 的欢迎页面，按照指引操作即可。（注意让你命名新 stories 时不要和已有的 stories 重名）

完成上述操作以后的项目结构如下：

$ tree -F -I "node_modules"
.
|-- README.md
|-- eslint.config.js
|-- index.html
|-- package.json
|-- bun-lock.yaml
|-- src/
|   |-- index.ts
|   |-- stories/
|   |   |-- Button.stories.ts
|   |   |-- Button.tsx
|   |   |-- Configure.mdx
|   |   |-- Header.stories.ts
|   |   |-- Header.tsx
|   |   |-- Page.stories.ts
|   |   |-- Page.tsx
|   |   |-- assets/
|   |   |   |-- accessibility.png
|   |   |   |-- accessibility.svg
|   |   |   |-- addon-library.png
|   |   |   |-- assets.png
|   |   |   |-- avif-test-image.avif
|   |   |   |-- context.png
|   |   |   |-- discord.svg
|   |   |   |-- docs.png
|   |   |   |-- figma-plugin.png
|   |   |   |-- github.svg
|   |   |   |-- share.png
|   |   |   |-- styling.png
|   |   |   |-- testing.png
|   |   |   |-- theming.png
|   |   |   |-- tutorials.svg
|   |   |   `-- youtube.svg
|   |   |-- button.css
|   |   |-- header.css
|   |   `-- page.css
|   `-- vite-env.d.ts
|-- tsconfig.app.json
|-- tsconfig.json
|-- tsconfig.node.json
|-- vite.config.ts
`-- vitest.workspace.ts

3 directories, 38 files

我们先暂时忽略一下 src/stories/ 目录，在 src/components 中创建 Button 文件夹并添加如下几个文件：

$ tree ./src/components/Button/
./src/components/Button/
|-- Button.scss
|-- Button.stories.ts
|-- Button.test.ts
|-- Button.tsx
`-- index.ts

0 directories, 5 files

Button.tsx 文件可以直接复制 stories/Button.tsx 的内容，只要将首行的 import 语句导入的样式文件后缀名改成 scss 即可，Button.stories.ts 文件可以直接复制 stories/Button.stories.ts 的内容，Button.scss 文件也可以直接复制 stories/Button.css 的内容，因为 scss 是 css 的超集，可以无缝转换 ，Button.test.ts 文件暂时先不管，这里是组件测试的代码，笔者还没研究。

现在在 src\Button\index.ts 中导出组件：

import { Button } from './Button';

export default Button;
export type { ButtonProps } from './Button';

在 src/index.ts 中导出组件：

export { default as Button } from './components/Button';

现在可以把 src/stories 目录删掉啦，需要抄的代码已经抄完了，可以不用它了。删掉之前可以先看一看 src\stories\Configure.mdx 的内容，学习一下怎么使用 MDX 书写组件库文档。

完成后的项目结构：

$ tree -F -I "node_modules"
.
|-- README.md
|-- eslint.config.js
|-- index.html
|-- package.json
|-- bun-lock.yaml
|-- src/
|   |-- components/
|   |   `-- Button/
|   |       |-- Button.scss
|   |       |-- Button.stories.ts
|   |       |-- Button.test.ts
|   |       |-- Button.tsx
|   |       `-- index.ts
|   |-- index.ts
|   `-- vite-env.d.ts
|-- tsconfig.app.json
|-- tsconfig.json
|-- tsconfig.node.json
|-- vite.config.ts
`-- vitest.workspace.ts

3 directories, 17 files

现在就已经可以愉快的书写组件库啦😋，接下来我们来看看 Storybook 的使用。

Storybook 使用

在重构项目结构以后，打开 package.json，可以看到现在的脚本如下：

{
  ...,
  "scripts": {
    "dev": "vite",
    "build": "tsc -b && vite build",
    "lint": "eslint .",
    "preview": "vite preview",
    "storybook": "storybook dev -p 6006",
    "build-storybook": "storybook build"
  },
  ...
}

由于现在的项目是一个库项目，无法直接使用 vite 命令运行，所以我们可以稍作修改：

{
  ...,
  "scripts": {
    "dev": "storybook dev -p 6006",
    "lint": "eslint .",
    "build": "bun run build:js && bun run build:types && bun run build:css",
    "build:js": "vite build",
    "build:types": "tsc --emitDeclarationOnly",
    "build:storybook": "storybook build"
  },
  ...
}

现在运行 bun dev 就可以直接启动 Storybook 开发服务器啦，快去试试吧🎉

Lottie 是由 Airbnb 开源的一套跨平台动画解决方案。它极大地简化了设计师和开发者之间的协作流程 - 设计师可以在 After Effects (AE) 或 Figma 等设计软件中创建动画，导出为 JSON 格式后，开发者便可以在各个平台上实现一致的动画效果。

作为前端开发者，Lottie 的出现显著降低了实现复杂动画的门槛。无需手写复杂的 CSS 动画或 Canvas 绘制代码，通过简单的配置就能完美还原设计稿中的动画效果。

设计工作流

Figma 工作流

1. 安装 LottieFiles for Figma 插件
2. 使用 Figma 创建动画
3. 通过插件导出为 JSON 格式

After Effects 工作流

1. 安装 LottieFiles for After Effects 插件
2. 使用 AE 制作动画
3. 通过插件导出为 JSON 格式

Web 端实现方案对比

在前端开发中，主要有三种实现方案：

1. Lottie Web (官方 SDK)

• 优点：
  • 官方维护，更新及时
  • 性能优化，直接使用 Canvas/SVG 渲染
  • 提供完整的动画控制 API
• 缺点：
  • 需要手动处理与框架的集成
  • API 偏底层，使用相对复杂

2. React Lottie

• 优点：
  • 专为 React 设计的封装
  • API 简单易用
• 缺点：
  • 基于较早期的 bodymovin.js
  • 使用 Class Components，不完全适配现代 React
  • TypeScript 支持有限

3. Lottie React

• 优点：
  • 基于最新的 Lottie Web
  • 完整的 TypeScript 支持
  • 支持函数组件和 Hooks
  • 提供声明式和命令式两种使用方式
• 推荐使用场景：
  • 现代 React 项目
  • 需要 TypeScript 支持
  • 简单动画展示需求

实战应用

Lottie Web 使用示例

安装

# NPM
npm install lottie-web

# 或使用 CDN
<script src="https://cdnjs.cloudflare.com/ajax/libs/bodymovin/5.7.4/lottie.min.js"></script>

基础使用

<div id="lottie-container" style="width: 400px; height: 400px"></div>

<script>
  const animation = lottie.loadAnimation({
    container: document.getElementById('lottie-container'),
    renderer: 'svg',  // 可选: 'svg' | 'canvas' | 'html'
    loop: true,
    autoplay: true,
    path: 'animation.json'  // 动画文件路径
  });
</script>

React 集成示例

import { useEffect, useRef } from 'react';
import lottie, { AnimationItem } from 'lottie-web';
import animationData from './animation.json';

const LottieAnimation = () => {
  const containerRef = useRef<HTMLDivElement>(null);
  const animationRef = useRef<AnimationItem>();

  useEffect(() => {
    if (!containerRef.current) return;

    animationRef.current = lottie.loadAnimation({
      container: containerRef.current,
      renderer: 'svg',
      loop: true,
      autoplay: true,
      animationData,
    });

    return () => animationRef.current?.destroy();
  }, []);

  return <div ref={containerRef} style={{ width: 400, height: 400 }} />;
};

export default LottieAnimation;

Lottie React 使用示例

安装

npm install lottie-react
# 或
pnpm add lottie-react

组件式使用

import Lottie from 'lottie-react';
import animationData from './animation.json';

const Animation = () => (
  <Lottie 
    animationData={animationData}
    loop={true}
    autoplay={true}
    style={{ width: 400, height: 400 }}
  />
);

export default Animation;

Hook 式使用

import { useLottie } from 'lottie-react';
import animationData from './animation.json';

const Animation = () => {
  const { View, play, pause, stop } = useLottie({
    animationData,
    loop: true,
    autoplay: false,
  });

  return (
    <div>
      {View}
      <button onClick={() => play()}>播放</button>
      <button onClick={() => pause()}>暂停</button>
      <button onClick={() => stop()}>停止</button>
    </div>
  );
};

export default Animation;

高级功能

动画控制

import { useRef } from 'react';
import Lottie, { LottieRefCurrentProps } from 'lottie-react';
import animationData from './animation.json';

const ControlledAnimation = () => {
  const lottieRef = useRef<LottieRefCurrentProps>(null);

  const handleComplete = () => {
    console.log('动画播放完成');
  };

  return (
    <div>
      <Lottie
        lottieRef={lottieRef}
        animationData={animationData}
        loop={false}
        onComplete={handleComplete}
      />
      <button onClick={() => lottieRef.current?.setSpeed(2)}>
        2倍速播放
      </button>
      <button onClick={() => lottieRef.current?.goToAndPlay(30, true)}>
        跳转到第30帧并播放
      </button>
    </div>
  );
};

export default ControlledAnimation;

性能优化建议

1. 选择合适的渲染器

   • SVG: 适用于小型、交互性强的动画
   • Canvas: 适用于大型、复杂的动画

2. 优化动画资源

   • 压缩 JSON 文件
   • 移除未使用的关键帧
   • 适当降低动画帧率

3. 按需加载

   • 使用动态导入延迟加载动画资源
   • 考虑在适当时机销毁动画实例

4. 缓存策略

   • 对频繁使用的动画进行缓存
   • 考虑使用 Service Worker 缓存动画资源

最佳实践

1. 文件管理

   src/
   ├── assets/
   │   └── animations/     # 存放动画JSON文件
   ├── components/
   │   └── animations/     # 存放动画组件

2. 组件封装

   tsx

   // src/components/animations/AnimationWrapper.tsx
   import Lottie, { LottieProps } from 'lottie-react';
   
   interface Props extends Partial<LottieProps> {
     name: string;
     size?: number;
   }
   
   const AnimationWrapper = ({ name, size = 200, ...props }: Props) => (
     <Lottie
       animationData={require(`@/assets/animations/${name}.json`)}
       style={{ width: size, height: size }}
       {...props}
     />
   );
   
   export default AnimationWrapper;

3. 错误处理

   tsx

   const Animation = () => {
     const handleError = (err: Error) => {
       console.error('Lottie 动画加载失败:', err);
       // 显示后备UI
     };
   
     return (
       <ErrorBoundary fallback={<FallbackUI />}>
         <Lottie
           animationData={animationData}
           onError={handleError}
         />
       </ErrorBoundary>
     );
   };

Lottie 为 Web 开发带来了设计与开发的无缝衔接，大幅提升了动画开发效率。通过合理选择实现方案、遵循最佳实践，我们可以轻松地在 Web 应用中实现高质量的动画效果。

前段时间在推动「华师匣子」完全重构后的 3.0 版本的上线，应用上线当然离不开一个好看的门头，于是着手配置匣子的 启动画面（Splash Screen） 与 应用图标（App Icon）。起初以为只需准备一张图交给 Expo 配置即可，但真正深入研究时，才发现 iOS 和 Android 在图标与启动页方面的设计理念与规范差异不小。

一、平台差异与设计理念对比

在设计 Splash Screen 与 App Icon 之前，了解 Google 与 Apple 的设计哲学非常重要，它们的出发点不同，最终呈现方式也有所区别：

二、App Icon 设计指南

iOS 平台

根据 Apple 官方 HIG：

• 必须为正方形图标（1024×1024 px）。
• 不要添加圆角，系统会自动处理。
• 图标应具有识别度，避免文字或复杂元素。
• 背景必须不透明（纯白或品牌色），不要留空或透明区域。

Android 平台

参考 Android Adaptive Icon 设计规范：

• 图标分为前景图和背景色或图。
• 系统应用不同遮罩形状显示图标（圆形、泪滴、方形等）。
• 前景图像应居中，避免边缘贴边（保持安全区）。

推荐工具：

• 📠 官方图标制作工具：轻松创建用于 Android 的图标
• 🎨 Figma 图标设计模板：已适配 iOS 与 Android 尺寸
• 🛠️ expo-optimize：用于图像压缩优化

三、Splash Screen 设计建议

Splash Screen 是用户点击图标后的第一屏，其作用是承接启动过程、展现品牌感。

通用设计建议：

• 使用品牌图标或标志性元素，简洁为主。
• 图像居中显示，背景色与品牌主色调一致。
• 避免文字或加载动画，保持统一视觉体验。

iOS 注意事项

Apple 不允许控制 Splash 停留时间，不允许加入动画。开发者需通过配置 LaunchScreen.storyboard 实现固定启动页。

Android 支持动画启动（12+），但建议尽量保持风格一致，不使用复杂动效。

四、Expo 中的配置方式

Expo 提供了集中化的配置方式，统一管理图标和启动页资源。只需编辑 app.json 或 app.config.js。

App Icon 配置示例

{
  "expo": {
    "icon": "./assets/icon.png"
  }
}

推荐尺寸：1024×1024 px
不添加圆角、不透明背景

对于 Android 自定义 Adaptive Icon：

{
  "expo": {
    "android": {
      "adaptiveIcon": {
        "foregroundImage": "./assets/adaptive-icon.png",
        "backgroundColor": "#FFFFFF"
      }
    }
  }
}

Splash Screen 配置示例

{
  "expo": {
    "splash": {
      "image": "./assets/splash.png",
      "resizeMode": "contain",
      "backgroundColor": "#ffffff"
    }
  }
}

字段说明：

• image: 建议透明 PNG 格式的 logo。
• resizeMode:
  • contain: 居中缩放，不裁剪。
  • cover: 全屏填充，可能裁剪边缘。
• backgroundColor: 建议与主 UI 保持一致。

五、调试建议

• 使用 npx expo start 快速预览配置效果。
• 使用 expo run:android / expo run:ios 构建真机测试。
• 若 iOS 上启动页不显示，可参考 Apple 的 TN3118 技术文档。

六、尺寸汇总表

七、总结

设计图标和启动页看似细节，但却直接影响用户的第一印象。如果你正在使用 Expo 开发 App，建议在早期就将这些资源准备好，确保在 Android 与 iOS 上都有一致且合规的体验。

参考链接

• 苹果官方指南
• 安卓官方指南
• UI 百科
• 少数派
• 尺寸参考

在前端开发中，组件封装指的是将 UI 的一部分（例如一个按钮、一个表单、一个对话框等）及其相关的逻辑（例如数据获取、事件处理、状态管理等）组合成一个独立的、可复用的单元，这个单元就称为组件。

组件封装的目标是提高代码的可复用性、可维护性和可测试性。通过将 UI 和逻辑封装到组件中，我们可以：

• 提高代码复用性: 将常用的 UI 元素封装成组件，可以在不同的页面或项目中重复使用，避免重复编写相同的代码。
• 提高代码可维护性: 当需要修改 UI 或逻辑时，只需要修改组件的代码，而不需要修改多个地方的代码。
• 提高代码可测试性: 组件可以独立进行测试，更容易发现和修复 bug。
• 提升开发效率: 使用组件可以加快开发速度，因为开发者可以直接使用现成的组件，而不需要从头开始编写代码。
• 增强代码组织结构: 将代码拆分成更小、更易于管理的单元，使代码更具可读性和可理解性。

组件封装的核心思想:

• 封装性: 组件内部的实现细节对外隐藏，只暴露必要的接口供外部使用。
• 可复用性: 组件可以在不同的场景下重复使用。
• 可组合性: 组件可以像积木一样组合成更复杂的 UI。

基础的组件封装

以 React 中最常用的 函数式组件 为例，一个最简单的组件封装如下：

const Greet = (name: string) => {
  return <div>Hello {name} </div>
}

// using the functional component
<Greet name="Alice"/>
<Greet name="Bob"/>

通过更改传入组件的 props 值，我们就可以复用这个封装好的组件。当然，有时组件不仅仅用于数据渲染，也用于与用户交互：

interface ButtonProps {
  onClick?: () => void
  disabled?: boolean
  children: React.ReactNode
}

const Button: React.FC<ButtonProps> = ({ onClick, disabled, children }) => {
  return (
    <button onClick={onClick} disabled={disabled}>
      {children}
    </button>
  )
}

组件也可以拥有自己的 state，以实现响应式的数据渲染与操作：

const Counter = () => {
  const [count, setCount] = useState(0)

  return (
    <div>
      <p>你点击了按钮 {count} 次</p>
      <button onClick={() => setCount((prevCount) => prevCount + 1)}>
        点击我
      </button>
    </div>
  )
}

看到这里，恭喜你已经入门了 React 的组件封装。但实际开发中，组件承担的功能往往更加复杂，想要真正优雅地封装出好的组件水是很深的。

更进一步

在实际的业务中，前端的数据大部分要从后端获取，而这个过程中常常涉及异步操作。在一个组件中进行异步操作，一般需要依靠 useEffect 钩子：

const AsyncComponentPromise = () => {
  const [data, setData] = useState(null)
  const [error, setError] = useState(null)
  const [loading, setLoading] = useState(true)

  useEffect(() => {
    fetch("/api/data")
      .then((response) => {
        if (!response.ok) {
          throw new Error(`HTTP error! status: ${response.status}`)
        }
        return response.json()
      })
      .then((jsonData) => setData(jsonData))
      .catch((error) => setError(error))
      .finally(() => setLoading(false))
  }, [])

  if (loading) {
    return <div>Loading...</div>
  }

  if (error) {
    return <div>Error：{error.message}</div>
  }

  if (data) {
    return (
      <div>
        <h1>Loaded</h1>
        <ul>
          {data.map((item) => (
            <li key={item.id}>{item.name}</li>
          ))}
        </ul>
      </div>
    )
  }

  return <div>No Data</div>
}

我们为什么需要 useEffect 钩子来进行异步操作呢？答案很简单，React 作为一个 UI 框架，其核心在于渲染出页面，所以整个函数式组件的函数体，实际上是构建、渲染这个组件的流程，一旦我们在渲染流程中直接进行异步操作，就会导致这个流程需要等待异步操作结束，即阻塞了组件的渲染。

而 useEffect 钩子为了解决这个问题，其接收的函数将会在组件渲染完成后执行，这样就避免了异步操作对组件渲染的阻塞。

实际上应该放在 useEffect 钩子中执行的不仅仅是异步操作，还有例如修改特殊变量、进行 I/O 操作、抛出异常等代码，这些有一个统称叫做 副作用，这里不展开讲解。

另一个非常有用的钩子叫做 useContext，它是 React 中 状态提升 操作的高级解决方案，可以将状态跨越多层组件透传，一个典型的例子是用它实现侧边栏这种布局状态的控制：

import { createContext, useContext, useState } from "react"

const SidebarContext = createContext()

const SidebarProvider = ({ children }) => {
  // 在 Provider 中保存状态，并提供给内部组件访问
  const [isSidebarOpen, setIsSidebarOpen] = useState(false)

  const toggleSidebar = () => {
    setIsSidebarOpen(!isSidebarOpen)
  }

  return (
    <SidebarContext.Provider value={{ isSidebarOpen, toggleSidebar }}>
      {children}
    </SidebarContext.Provider>
  )
}

const useSidebar = () => {
  const context = useContext(SidebarContext)
  if (context === undefined) {
    throw new Error("useSidebar must be used within a SidebarProvider")
  }
  return context
}

const Sidebar = () => {
  // 获取状态
  const { isSidebarOpen, toggleSidebar } = useSidebar()

  return (
    <aside
      className={`bg-gray-800 text-white w-64 ${
        isSidebarOpen ? "block" : "hidden"
      }`}
    >
      {/* Sidebar content */}
      <button onClick={toggleSidebar}>关闭侧边栏</button>
    </aside>
  )
}

export { SidebarProvider, Sidebar, useSidebar }

在使用组件时，要先创建 Sidebar 上下文，再调用 Sidebar 组件：

const App = () => {
  const { toggleSidebar } = useSidebar()
  return (
    <SidebarProvider>
      <div className="flex">
        <Sidebar />
        <main className="p-4">
          {/* Main content */}
          <button onClick={toggleSidebar}>打开侧边栏</button>
        </main>
      </div>
    </SidebarProvider>
  )
}

组件样式

前端开发另一个重要的部分就是样式的实现了，虽然用来编写样式的 Extension 有很多，但要利用好他们其实也需要一些技巧。例如刚接触前端开发的人最常犯的错误就是 css 选择器运用不熟练，导致出现非常多不同类名但拥有重复的代码。

下面我们来看看几大组件库的样式实现方式。

Ant Design

AntD 采用的是 Design Token 模式，通过预定义的原子化 Token 来自定义样式：

import { Button, ConfigProvider, Space } from "antd"
import React from "react"

const App: React.FC = () => (
  <ConfigProvider
    theme={{
      token: {
        // Seed Token，影响范围大
        colorPrimary: "#00b96b",
        borderRadius: 2,

        // 派生变量，影响范围小
        colorBgContainer: "#f6ffed",
      },
    }}
  >
    <Space>
      <Button type="primary">Primary</Button>
      <Button>Default</Button>
    </Space>
  </ConfigProvider>
)

export default App

这种模式许多优点：

• 一致性: 设计令牌确保在整个应用程序中使用相同的颜色、字体、间距等样式。 更改一个令牌的值会自动更新所有使用该令牌的地方，从而减少了维护工作量并避免了不一致性。
• 可维护性: 集中管理设计令牌使得修改样式变得更容易。 开发者只需要修改令牌的值，而不需要在整个代码库中搜索和替换样式。
• 可扩展性: 设计令牌使得设计系统更容易扩展。 可以轻松添加新的令牌，而不会影响现有代码。
• 可重用性: 设计令牌可以跨多个项目和平台重用，从而提高了效率。
• 协作性: 设计令牌为设计师和开发者提供了一种通用的语言，方便他们协作。 设计师可以定义令牌，开发者可以使用这些令牌来构建 UI 组件。
• 主题定制: 通过修改设计令牌，可以轻松地创建不同的主题，例如深色模式或品牌主题。

但同时也有许多缺陷：

• 学习成本: 需要学习如何使用设计令牌系统，这对于团队成员来说可能需要一些时间和精力。
• 初始设置成本: 设置设计令牌系统需要一些前期工作，例如定义令牌、创建工具等。
• 复杂性: 对于小型项目，设计令牌系统可能显得过于复杂，得不偿失。 管理大量的令牌也可能变得复杂。
• 工具依赖: 通常需要使用一些工具来管理和使用设计令牌，例如 Style Dictionary 或类似的工具。 这增加了项目的依赖性。
• 潜在的命名冲突: 如果令牌命名不当，可能会导致命名冲突。 需要制定一个清晰的命名约定来避免这种情况。
• 调试难度: 追踪样式问题可能变得更困难，因为需要追踪令牌的层层映射关系。

shadcn/ui

shadcn/ui 与 AntD 差别十分明显，其采用 Headless UI 理念构建：

Headless UI 是一种新型的 UI 组件开发模式，它只关心行为逻辑，不涉及 UI 的具体实现，从而允许开发者自由定制 UI，这种设计思想符合开闭原则。

目前比较出众的是 Radix、headlessui，主要都是解决 Behavior Libraries 层面的问题。旨在提供一套开放、无控制、无样式的基础组件，方便开发者进行进一步的个性化封装。我的探索之旅中，我读过、试过这两者，最终决定更深入地使用 Radix，主要是因为 shadcn/ui 这个优秀项目也是建立在 Radix 的基础上！以下是 Radix 的几大核心理念：

• 可访问性（Accessible）：如果你需要考虑应用的可访问性（残疾人士友好），Radix 的设计遵循 WAI-ARIA 规范，这是 W3C 编写的规范，定义了一组可用于其他元素的 HTML 特性，用于提供额外的语义化以及改善无障碍体验。
• 无样式（Unstyled）：正如其名，Radix 提供的组件不包含任何预设风格，完全自由地配合任何样式方案，这也直击了自定义样式的痛点。
• 开放性（Opened）：Radix 的开放性极佳，每一个组件都是独立的单元，可自由组合、灵活配置，满足你的各种需求。

shadcn/ui 是 Vercel 的工程师推出的一款组件合集，建立在 Tailwind CSS 和 Radix UI 之上，目前包括了48个独立组件。根据官方说明，这款产品被定义为「组件合集」而非传统的「组件库」，其独到之处在于：不通过 npm 安装，而是直接将组件源代码复制粘贴到项目中，这样极大地方便了用户根据自己的需求去修改和扩展代码。

与传统组件库相比，shadcn/ui 遵循以下设计原则：

• 避免不必要的依赖：不把整个库作为依赖项添加，有助于减少项目体积，从而提升应用的加载速度。
• 组件代码的直接编辑：由于使用复制和粘贴的方式加入项目，提供了直接访问每个组件源代码的能力，开发者可以直接访问和控制每个组件的行为、样式和 DOM 结构，这种灵活性让 shadcn/ui 在众多 UI 解决方案中脱颖而出。
• 细粒度的控制：每一个组件都是独立的单元，可以单独使用和定制，这种模块化的设计不仅简化了个别组件的定制过程，也便于整体 UI 系统的扩展和维护。
• 多层次的样式自定义：首先，shadcn/ui 提供了图形界面的主题编辑器，允许开发者在不直接修改 CSS 的情况下，通过编辑器定制一系列样式（如颜色、字体、边距等）；其次，开发者还可以在组件源代码层面进行个性化调整，或在使用组件时直接在标签上添加 className；最后，通过 RenderProps 方式进一步扩展 UI，开发者可以拿到当前上下文的状态，天然适合对 UI 的自定义扩展。这种多维度的自定义能力极大增强了 UI 的灵活性和适应性。

例如，使用 shadcn/ui 中的 Tabs 组件时，可以通过以下命令简单地添加到项目中：

<Tabs defaultValue="account" className="w-full">
  <TabsList>
    <TabsTrigger value="account">Account</TabsTrigger>
    <TabsTrigger value="password">Password</TabsTrigger>
  </TabsList>
  <TabsContent value="account">在这里修改你的账号设置</TabsContent>
  <TabsContent value="password">在这里修改你的密码</TabsContent>
</Tabs>

执行 npx shadcn-ui@latest add tabs 后，Tabs 组件会被安装到 ./components/ui/tabs.tsx，此时开发者可以直接编辑源代码以定制 Tabs 组件。Tabs 组件自身被设计为多个可单独定制的子组件（如 Tabs, TabsContent, TabsList, TabsTrigger），这为定制和风格化提供了极大的便利。

shadcn/ui 的设计理念是将交互逻辑的复杂性留给组件维护者，而将 UI 的定制性最大化地交给使用者，实现了业务需求的高度定制化。这种做法符合软件设计原则「关注点分离」（Separation of concerns，SoC），不过也带来了一些挑战：

• 对开发者的要求较高：需要良好的抽象设计能力来处理无UI层的组件。
• 较高的使用成本&升级成本：完全自定义的 UI 层可能带来更大的开发成本，未来的更新升级也比较麻烦，需要仔细评估成本和收益。

作为一个练习时长两年半的前端练习生，个人认为前端目前资料最零散的部分，就是前端项目的工程化。在目前前端基础技术相对固定且成熟的情况下，项目工程化所需的各种知识就更加能够体现出一名前端程序员的项目经验。

工程规范

从 Git 讲起

版本控制系统在软件工程领域中无疑是十分重要的一个部分，而 Git 则是其中最优秀的一个解决方案。不管是在大型项目还是小玩具中，Git 的使用都可以提高开发与协作的效率。

版本控制

版本控制是 Git 的本职工作，其在大型项目中无论是性能还是效果上都表现极佳。通过追踪分支或文件的 commit 历史，可以很方便地回滚版本、处理 bug。

为了方便版本控制，大多数专业团队会要求开发者遵循提交规范，这里以 Angular Commit （中文版）规范为例。以这种规范的格式来撰写 Commit Message，可以大大提高版本控制过程中定位更改的效率，也可以让你的小伙伴一眼看懂你的 Commit 到底干了些啥。

协作开发

Git 独特的分支系统设计给多人协作项目提供了非常好的开发管理方式，每个开发者可以在不同的 branch 上进行开发，各自的工作内容不会互相影响，在完成各个模块的开发后也可以非常方便地 merge 到主分支中。

在一个工程化的项目中，开发一个新功能的简要过程如下：

通过新建分支的形式，将开发新 Feature 的起点固定在某一个版本，可以在功能开发周期内保证基础代码的不变，避免开发过程中经常更新上游代码导致的一些临时 bug 和开发思路中断。

而 Pull Request 则可以为后续 Code Review 提供平台，保证代码质量。

持续集成和部署

一个成熟的前端工程化项目一定具备持续集成和部署的能力，通过版本控制系统与 CI/CD 系统之间的协作，可以自动化完成一系列重复的工作，提高开发效率。

持续集成（CI）

持续集成（CI）是指将多个开发者的代码变更频繁地集成到一个共享的代码仓库中。这个过程通常涉及以下几个步骤：

• 代码提交：开发者将代码更改提交到版本控制系统（如Git）。
• 自动构建：每次提交后，系统会自动构建代码并运行测试，以确保新代码没有引入错误。
• 早期发现问题：通过频繁的集成，团队能够及早发现和解决代码冲突和缺陷，从而避免在后期阶段出现更大的问题。

持续交付与持续部署（CD）

持续交付和持续部署（CD）是CI的延伸，二者有细微差别：

• 持续交付：指的是在完成自动化测试后，代码可以随时部署到生产环境，但实际的部署过程可能仍需要人工干预。这种方式确保了软件始终处于可发布状态，能够快速响应市场需求和用户反馈。
• 持续部署：则是将所有通过测试的代码自动部署到生产环境中，不需要人工干预。这意味着每次代码变更都能迅速推送给最终用户，从而加快了反馈循环和迭代速度。

CI/CD的优势

• 提高效率：通过自动化构建、测试和部署，减少了手动操作，提高了开发团队的工作效率。
• 降低风险：小规模、频繁的更新使得问题更易于识别和修复，从而降低了大规模发布带来的风险。
• 快速反馈：频繁的发布周期让开发团队能够快速获得用户反馈，从而及时调整和优化产品。

工具与实践

在CI/CD的实施过程中，有许多工具可以帮助团队实现自动化流程，例如：

• 持续集成工具：Jenkins、Travis CI、CircleCI等。
• 持续交付/部署工具：Ansible、Puppet、AWS CodeDeploy等。
• 监控工具：Nagios、Zabbix等，用于实时监控应用性能和健康状态。

此外，最常用也最简单的工具其实是 GitHub Actions，这里不过多赘述，以后也许会另写文章。

赏心悦目的代码风格

前端语言的代码风格相较于其他语言比较灵活，每个人都可能有自己的习惯，例如缩进的 Tab 与空格、是否添加尾逗号、单双引号的使用、行末分号的添加……这些不同的代码风格如果不加以统一，会导致代码看起来十分混乱，也不方便后续的维护。这里介绍两个前端最常用的格式化工具：ESLint & Prettier。

ESLint

ESLint 是一个 JS/TS 代码质量检查工具，侧重于检查语法错误以及代码中可能出现的错误。例如 未被导出的成员、 未被使用的导入……

Prettier

Prettier 是一个代码格式化工具，提供了对于多种语言代码的格式化支持，如 .css、.sass、.scss、.jsx、.tsx、.vue 等语言的文件。

两个工具侧重点不同，因此在前端项目中常常同时配置这两个工具来更加全面地规范代码风格。

构建工具

前端项目的基础是 HTML、CSS 与 JavaScript，但仅通过这些语言来开发不够高效，也因此我们需要学习如 Vue、React 这样的前端框架，但这些框架都有着自己特殊的代码形式，而构建工具就是将基于这些框架的代码打包编译成 HTML、CSS 和 JavaScript 的程序。

梦开始的 Webpack

Webpack 是目前运用最广泛的前端项目打包工具，其主要工作是解析 js 代码间的依赖关系、将所有依赖的文件打包到最终的产物 js 文件中、将一些不统一的 ES 语法转换统一。

看起来很抽象，那么 Webpack 到底做了些什么事呢？

在一个完整的项目 当中，一般会有各种不同类型的资源文件，比如 .js、.jsx、.css、.sass 等文件，而 Webpack 所做的就是将这些资源文件进行依赖分析，并整合成一个整体，再分块输出成许多 chunk 便于加载。

这个过程核心完成了 内容转换 + 资源合并 两种功能，实现上包含三个阶段：

1. 初始化阶段：
   1. 初始化参数：从配置文件、 配置对象、Shell 参数中读取，与默认配置结合得出最终的参数
   2. 创建编译器对象：用上一步得到的参数创建 Compiler 对象
   3. 初始化编译环境：包括注入内置插件、注册各种模块工厂、初始化 RuleSet 集合、加载配置的插件等
   4. 开始编译：执行 compiler 对象的 run 方法
   5. 确定入口：根据配置中的 entry 找出所有的入口文件，调用 compilition.addEntry 将入口文件转换为 dependence 对象
2. 构建阶段：
   1. 编译模块(make)：根据 entry 对应的 dependence 创建 module 对象，调用 loader 将模块转译为标准 JS 内容，调用 JS 解释器将内容转换为 AST 对象，从中找出该模块依赖的模块，再 递归 本步骤直到所有入口依赖的文件都经过了本步骤的处理
   2. 完成模块编译：上一步递归处理所有能触达到的模块后，得到了每个模块被翻译后的内容以及它们之间的 依赖关系图
3. 生成阶段：
   1. 输出资源(seal)：根据入口和模块之间的依赖关系，组装成一个个包含多个模块的 Chunk，再把每个 Chunk 转换成一个单独的文件加入到输出列表，这步是可以修改输出内容的最后机会
   2. 写入文件系统(emitAssets)：在确定好输出内容后，根据配置确定输出的路径和文件名，把文件内容写入到文件系统

单次构建过程自上而下按顺序执行，下面会展开聊聊细节，在此之前，对上述提及的各类技术名词不太熟悉的同学，可以先看看简介：

• Entry：编译入口，webpack 编译的起点
• Compiler：编译管理器，webpack 启动后会创建 compiler 对象，该对象一直存活知道结束退出
• Compilation：单次编辑过程的管理器，比如 watch = true 时，运行过程中只有一个 compiler 但每次文件变更触发重新编译时，都会创建一个新的 compilation 对象
• Dependence：依赖对象，webpack 基于该类型记录模块间依赖关系
• Module：webpack 内部所有资源都会以“module”对象形式存在，所有关于资源的操作、转译、合并都是以 “module” 为基本单位进行的
• Chunk：编译完成准备输出时，webpack 会将 module 按特定的规则组织成一个一个的 chunk，这些 chunk 某种程度上跟最终输出一一对应
• Loader：资源内容转换器，其实就是实现从内容 A 转换 B 的转换器
• Plugin：webpack构建过程中，会在特定的时机广播对应的事件，插件监听这些事件，在特定时间点介入编译过程

下一代的构建工具！

Vite 被誉为下一代构建工具，以打包速度快、热更新速度快深受开发者喜爱。Vite 所做的事和 Webpack 相同，但在构建过程中的优化比 Webpack 更优秀，HMR 速度和 build 速度都比 Webpack 快很多。

另一方面，与 Webpack 相比，Vite 本身提供的功能十分简单，仅仅只是一个打包工具，因此其基础配置比 Webpack 简洁很多，而其它功能则通过各种官方/社区的插件作为补充。

区块链技术是一种去中心化的分布式账本技术，最初由中本聪在2008年提出，作为比特币的底层技术。它结合了分布式存储、点对点传输、共识机制和密码学等多种技术，确保数据的安全性和透明性。

区块链的系统架构图大致如下：

• 应用层：即区块链技术的实际应用案例，由于区块链本身是一个分布式账单，被大量用于金融领域。
• 接口层：即区块链技术的编程实现，在此基础上可以开发各领域特定的区块链应用。
• 服务层：区块链技术的逻辑实现，分为许多模块。
• 调度层：主要实现区块链的分布式结构，调度各种资源。
• 资源层：区块链的算力即数据提供方。

基本原理

其核心特点包括：

• 去中心化：没有中央控制机构，所有参与者共同维护账本。
• 不可篡改：一旦数据被写入区块链，就无法修改或删除。
• 透明性：所有交易记录对所有参与者可见，增强信任。
• 安全性：使用密码学保护数据传输和存储。

技术细节

• 交易生成：用户发起交易，并通过公钥和私钥进行验证。
• 交易打包：有效的交易被打包成一个区块。
• 共识机制：网络中的节点通过共识算法（如工作量证明或权益证明）验证交易的有效性。
• 区块添加：确认后的区块被添加到现有链上，形成不可更改的记录。

比特币是一种去中心化的数字货币，依赖于加密技术和社区账本来确保交易的安全性，从而消除了对银行的需求。

亮点

• 💻 比特币是一种完全数字化的货币，没有政府或银行的介入。
• 🔑 加密技术通过数字签名确保交易的安全。
• 📜 社区账本追踪用户之间的交易。
• ⛏️ 新的比特币是通过一个涉及工作量证明的过程——挖矿创造出来的。
• 🔄 交易验证使用最长的区块链作为可信源。
• 💰 维护网络的矿工可以获得奖励和交易费用。
• 🌐 对潜在投资者来说，了解比特币的基础知识至关重要。 核心概念
• 🔍 去中心化：比特币在没有中央机构的情况下运作，允许用户直接进行交易，促进无信任交互。这种设计赋予个人权力并增强了隐私。
• 🔒 数字签名：交易中使用公钥和私钥防止伪造，并确保只有合法所有者可以授权支付，大大提高了安全性。
• 📊 工作量证明：共识机制依赖计算努力来验证交易，这使得修改交易历史既昂贵又耗时，从而保护了免受欺诈。
• 🏗️ 区块链结构：交易被分组成块，并按时间顺序链接，创建了一个不可更改的记录，这对于保持货币的完整性至关重要。
• 💵 有限供应：比特币的供应上限为2100万枚，这种稀缺性可能随着时间的推移对比特币的价值产生贡献，与可以无限印制的传统法定货币形成对比。
• ⚖️ 交易费用：矿工因处理交易而获得费用，这一激励系统可能导致高峰时段成本更高，与传统支付系统具有更高的吞吐量不同。
• 📚 财务素养：了解加密货币的技术基础对于做出明智的投资决策至关重要，特别是在一个以波动性和投机性为特征的市场中。

从一个分布式账本开始

分布式系统是一种将任务分配给多个独立的计算节点（计算机、服务器等）进行处理的系统架构。这种系统通过网络连接多个节点，共同完成计算任务，从而提高处理能力、可靠性和可扩展性。

举个简单的例子，假设有一个复杂的数学问题，如果一台计算机需要很长时间才能解决，那么将这个问题分成多个部分，每部分分配给不同的计算节点去处理，最终汇总结果，这样就能更快地解决问题。

而区块链的原型，就是一个分布式的账本。这个账本记录了每个参与者的交易信息，根据每笔交易记录可以计算出每个人的余额。而这个账本是可复制的、可编辑的，每个参与者都可以保存一份这个账本的副本，每个人也都有权向其中加入新的交易记录。到了月底，将大家的账本拿出来清算每人的应付与结余。

为了同步所有人手上的账本，每个人在新增交易记录时都应该向其他人广播消息，以确保所有人手上的账本内容一致。而在广播消息时，为了确保交易真实有效，双方应该在交易上签名确保真实。

分布式账本可信吗

如果每个人都可以随意向自己的账本中增加交易记录的话，那么到了月底时应该以谁的账本为准呢？如果有人没有接收到某笔交易的广播，或者有人恶意伪造他人签名，这时应该相信哪个版本的账本呢？

这时就需要引入数字加密了。与传统签名不同，数字签名会随着签署的内容而变化，这决定了每个签名的都是独一无二的。数字签名的原理很简单，每个人拥有一对 公钥 secret key 和 私钥 private key。在签名时，将私钥与签署内容一起进行加密计算，由于这个私钥只有本人拥有，因此不会被伪造。而其他人验证真伪时，只需要将此人的公钥与加密后的内容一起使用对应的解密算法进行计算，即可得出真伪。

$Sign(Message,sk)=Signature$

$Verify(Message,Signature,pk)=true/false$

通过签名算法得出的签名通常有 256 位的长度，而要通过控制这个签名的数据来找到能计算得出 true 的 Signature 只能通过枚举法，而 256 位的枚举法计算量是个无法企及的天文数字。

如果仅仅对 Message 进行加密，我们虽然无法篡改 Message，但我们可以将一条真实的交易记录复制多份，因此，在签名时通常会带上每笔交易的编号。

应用场景

• 金融：用于加密货币（如比特币、以太坊）及去中心化金融（DeFi）服务。
• 供应链管理：提高透明度和可追溯性，确保产品来源和质量。
• 医疗健康：安全存储患者记录，提高数据共享效率。
• 房地产：简化资产转让过程，通过智能合约自动执行交易。

未来展望

随着技术的发展，区块链有望在更多行业中发挥重要作用。尽管面临可扩展性和法规等挑战，但其去中心化、安全透明的特性使其成为改变传统商业模式的重要工具。未来，区块链可能会与人工智能、物联网等新兴技术结合，推动更广泛的创新和应用。

早早听闻 GitHub 的学生福利十分丰厚，我一直都很想申请一份玩玩，于是乎在前面的四个月中，我曾试过用录取通知书、学生证去申请，但都被机申以各种理由拒了。这个月终于能在学信网上查到学籍信息了，于是我用学信网的在线学籍认证成功申请到了 GitHub 学生包，这里记录一下踩坑过程。

准备材料

要准备的东西很简单，但都是必须的。

.edu 邮箱

这一步因学校而异，反正你要有一个由你本人控制的 .edu 邮箱，.edu 或者 .edu.cn 都可以。

学信网学籍认证报告

首先，注册登录学信网并完成实名认证。然后点击导航栏的 学信档案，再点击右侧 在线验证报告，点击链接进入。这里会要求你登录学信档案，用学信网账号登录就可以。

此时你应该来到了这个界面

一般在校大学生选择第一个报告就好，点击查看，如果你没有申请过报告，会提示你申请。

在线验证报告申请完毕以后，将 pdf 下载下来，然后找一个可以翻译文档的工具将它翻译成英文版，并转换成 png/jpg 格式。

填写信息

个人信息

首先打开你 GitHub 的 profile，这里有几个字段需要稍微修改一下以符合申请标准。

• Name：填你验证报告上姓名的拼音
• Bio：加一句类似 Student of xxxx 的介绍
• Company：填你学校的英文全称或者缩写
• Location：选择你学校所在的地区

付款信息

打开你 GitHub 账号的 Settings 页面，点击 Billing and plans，再点击 Paymant information，点击编辑。

• First name/Last name：如上，填入姓名拼音
• Address：直接填写大学名称或校区地址
• City/Country：同上
• State/Province：有些大学在申请时可能会检查此字段，最好也如实填写

绑定邮箱

还是在 Settings 页面，点击 Email，将你的 .edu 邮箱添加到账号，并查收验证邮件完成验证。

这一步非常重要，一定要完成 .edu 邮箱的验证，否则可能导致申请被拒。

提交申请

验证过 .edu 邮箱以后，回到 Dashboard 页，应该能看到 GitHub 邀请你加入 Education 计划的卡片了，可以直接点击申请。

这里建议关掉所有代理软件并且使用校园网访问，保证 IP 地址和定位是在校内。

在申请页，如实填写所有字段，最好全部使用英文及官方译名，在上传凭证时上传刚才准备好的英文版验证报告，Proof Type 选择 Others。

这里可能会要你提供对于证明的描述，用英文写一句 Official proof of CHSI 就可以了。

点击提交申请，理论上可以直接通过，如果被 Reject 了 GitHub 会显示原因并给出相应的提示，按照提示修改以后重新提交就可以了。

在申请通过的三天内，经过人工复核，GitHub 会向你的 .edu 邮箱发送邮件提醒你你的学生权益已经成功激活，现在你就可以愉快白嫖各种学生福利啦。我在正好第三天结束时才收到邮件

一直不太清楚 JavaScript 中 var 与 let 的区别，于是今天好好了解了一下，主要有以下三大区别。

作用域

首先是作用域上的区别，var 的作用域是函数级别（function level）的，而 let 的作用域是块级别（block level）的。

如下面的例子：

function foo() { // function level start
	if (true) { // block level start
		var c = 1
		let d = 1
	} // block level end
	// this works well
	console.log(c)
	// ReferenceError: d is not defined
	console.log(d)
} // function level end

可以看到，由 let 定义的变量只有在同一块级作用域内才能访问到，而由 var 定义的变量则在同一函数级作用域中可以访问到。

重声明

var 声明的变量是可以被重新声明的，而且作用域与被重声明前相同。需要注意的是，在开发过程中要谨慎使用这一特性，它可能导致一些无法预测的错误。而 let 声明的变量是不允许重声明的，尝试重声明一个 let 变量会引发语法错误，提示你不应该重声明一个 let 变量。

// declaration
var a = 1
let b = 1

// redeclaration
var a = 2 // acceptable
let b = 2 // error

变量提升

使用 var 声明的变量会被提升到其直属函数级作用域中，这意味着你可以在声明并初始化一个变量前引用它，但其值为 undefined。而 let 变量则不会被提升到函数级作用域中，你只能在声明它以后进行引用。

// Using var
console.log(a)
// Output: undefined (due to hoisting)
var a = 5; console.log(a)
// Output: 5

// Using let
console.log(b)
// Output: ReferenceError: Cannot access 'b' before initialization
let b = 10
console.log(b)
// Output: 10

这里顺便引入 Temporal Dead Zone 的概念。TDZ 指的是一个从块级作用域的头端开始，到一个变量被初始化结束的区域。在 JavaScript 中，由 let 和 const 声明的变量是有 TDZ 的，而由 var 声明的变量由于经过了提升，则不具有 TDZ。

function foo() {
	console.log(myVar)
	// ReferenceError: Cannot access 'myVar' before initialization
	let myVar = "Hello, World!" // same as const
	console.log(myVar) // Outputs: Hello, World!
}

function bar() {
	console.log(myVar) // Outputs: undefined
	var myVar = "Hello, World!"
	console.log(myVar) // Outputs: Hello, World! 
}

前端开发过程中，每个人都有自己的代码风格，但项目中应该将代码风格统一，所以我习惯用 ESLint + Prettier 来格式化代码。

介绍

ESLint 是一个 JavaScript 代码检测工具，用以进行一系列代码质量检测。

Prettier 是一个前端代码格式化工具，用以进行代码格式化操作。

但 ESLint 的格式化支持的文件类型较少，所以我喜欢配合 Prettier 来进行格式化。

配置 ESLint

安装 ESLint

# yarn yes!
yarn add eslint

# npm
npm i -D eslint

初始化 ESLint

eslint --init

此处根据你的项目具体情况回答几个问题，ESLint 就会自己乖乖生成配置文件了。

配置脚本

// package.json
{
...
  "scripts": {
    "lint": "eslint --fix ./**"
  }
...
}

再执行 yarn lint 就可以进行错误检测和格式化啦~

配置 Prettier

由于 ESLint 和 Prettier 的格式化功能有冲突，所以我们需要使用 ESLint 插件来关闭 ESLint 的格式化功能，防止 Prettier 和 ESLint 冲突。

安装 Prettier 及 ESLint 插件

yarn add prettier eslint-plugin-prettier eslint-config-prettier

修改 ESLint 配置文件

// .eslintrc.json
...
  "extends": [
    "plugin:prettier/recommended"
  ]
...

配置 Prettier

在项目根目录新建 .prettierrc 文件

{
  "printWidth": 80, // 自动换行长度
  "tabWidth": 2, // 制表符大小
  "useTabs": true, // Tab 缩进
  "singleQuote": true, // 单引号
  "semi": false, // 行末分号
  "trailingComma": "none", // 尾逗号
  "bracketSpacing": true // 大括号环绕空格 eg.{ foo }
}

配置脚本

// package.json
...
  "scripts": {
    "format": "prettier --write ."
  }
...

配置 VSCode

上面的配置都是进行运行时检测，为了我们的写码体验，可以安装一些 VSCode 插件来实时检测。

安装 VSCode ESLint 插件

名称: ESLint   
ID: dbaeumer.vscode-eslint   
说明: Integrates ESLint JavaScript into VS Code.   
版本: 2.2.6   
发布者: Microsoft   
[VS Marketplace 链接](https://marketplace.visualstudio.com/items?itemName=dbaeumer.vscode-eslint)    
这个插件将会自动用项目根目录下的 `.eslintrc.*` 配置文件来格式化代码

安装 VSCode Prettier 插件

名称: Prettier - Code formatter   
ID: esbenp.prettier-vscode   
说明: Code formatter using prettier   
版本: 9.8.0   
发布者: Prettier   
[VS Marketplace 链接](https://marketplace.visualstudio.com/items?itemName=esbenp.prettier-vscode)

安装 VSCode Prettier ESLint 插件

名称: Prettier ESLint
ID: rvest.vs-code-prettier-eslint
说明: A Visual Studio Extension to format JavaScript and Typescript code using prettier-eslint package
版本: 5.0.4
发布者: Rebecca Vest
[VS Marketplace 链接](https://marketplace.visualstudio.com/items?itemName=rvest.vs-code-prettier-eslint)

修改 VSCode 设置

{
  "editor.defaultFormatter": "rvest.vs-code-prettier-eslint", //  默认使用 prettier 作为格式化工具
  "editor.formatOnSave": true // 保存代码时格式化
}

配置完成🎉

接下来就可以愉快写码啦~

双拼最近越来越火了，我也在尝试学习，但是 Windows 自带的微软拼音输入法却没有自带小鹤双拼码表，如果自己一个键一个键的添加不仅麻烦还容易出错，所以我找到了这种修改注册表的添加方式。

手动添加

打开 Windows Powershell，执行以下命令：

New-ItemProperty HKCU:\Software\Microsoft\InputMethod\Settings\CHS\ -name "UserDefinedDoublePinyinScheme0" -value "小鹤双拼*2*^*iuvdjhcwfg^xmlnpbksqszxkrltvyovt" -propertyType string # 添加小鹤码表

gpupdate /force /wait:0 # 刷新注册表

自动添加

可以在本站 此处 下载 .ps1 脚本，运行即可。

使用

添加完毕后即可在 Windows 设置/时间和语言/语言和区域/微软拼音输入法/常规 中选择 小鹤双拼 使用。