【GitHub】图片上传工具PicGo 深度技术解析

当一个工具从个人项目成长为 24K+ Star 的开源生态，它的架构故事比功能列表更有价值。

一、引言：为什么 PicGo 值得深入分析

如果你写过技术博客、维护过 Markdown 文档，大概率用过或听过 PicGo —— 一个由开发者 Molunerfinn 从 2017 年开始打造的图片上传工具。截止 2026 年 7 月 v3.0.0 发布，PicGo 已经走过了近七年的迭代路程，从最初的 JavaScript + Electron-vue 小工具，演变成了 TypeScript + React 19 + Monorepo 的现代化桌面应用。

PicGo 之所以值得技术人深入分析，不仅因为它好用，更因为它的架构决策记录了一个开源项目从"够用"到"可持续"的完整蜕变路径：

• 插件化架构如何在保持核心极简的同时构建 60+ 图床生态
• 一个 Electron 桌面应用如何在 v3 大版本中完成 Vue → React 的框架迁移
• PicGo-Core 如何实现 GUI 与 CLI 的共享引擎
• 云服务商业化探索如何倒逼架构安全升级

二、整体架构：三层分离的"上传引擎"

2.1 架构全景图

PicGo 的架构可以概括为三层：

┌─────────────────────────────────────────────┐ │ GUI 层 │ │ (React 19 + shadcn/ui + Tailwind CSS v4) │ │ Zustand + TanStack Query + TanStack Router │ ├─────────────────────────────────────────────┤ │ Bridge 层 │ │ (Electron preload + IPC + HTTP Server) │ ├─────────────────────────────────────────────┤ │ Core 层 │ │ (PicGo-Core v3.0.0 - 纯 Node.js 引擎) │ │ 插件系统 + Transformer + Uploader + Hooks │ └─────────────────────────────────────────────┤

关键设计理念：Core 层不知道 GUI 存在。

PicGo-Core 是一个纯 Node.js 包，可以通过 CLI 或 API 调用，完全不依赖 Electron。GUI 层通过 IPC 调用 Core 的 API，Core 通过事件总线 (bus) 向 GUI 发送通知。这种分离让同一个上传引擎既能驱动桌面应用，又能嵌入 VS Code 插件 (vs-picgo)、CI/CD 脚本，甚至 AI Agent (PicGo Skills)。

2.2 v3 的 Monorepo 结构

v3 采用了 pnpm workspace 管理 Monorepo，项目目录结构如下：

src/ ├── main/ # Electron 主进程 │ ├── apis/ # 业务 API (上传器、窗口管理、快捷键、系统) │ ├── events/ # IPC + bus 事件监听 │ ├── i18n/ # 国际化资源 │ ├── lifeCycle/ # 应用生命周期管理 (bootstrap) │ ├── migrate/ # 版本迁移逻辑 │ ├── server/ # HTTP API Server (供外部工具调用) │ └── utils/ # 工具函数 ├── preload/ # Electron preload bridge (安全隔离) ├── renderer/ # 渲染进程 (React 19) │ ├── adapters/ # 适配层 │ ├── components/ # UI 组件 (shadcn/ui) │ ├── hooks/ # React Hooks │ ├── i18n/ # 国际化 │ ├── queries/ # TanStack Query hooks │ ├── routes/ # TanStack Router 路由 │ ├── store/ # Zustand 状态管理 │ ├── types/ # TypeScript 类型定义 │ ├── utils/ # 工具函数 │ ├── App.tsx # 应用入口 │ ├── main.tsx # 渲染进程入口 │ └── router.ts # 路由配置 ├── universal/ # 主进程与渲染进程共享代码 ├── background.ts # Electron 入口点 └── __tests__/ # Vitest 测试

v3 的 Monorepo 并不是把所有东西塞进一个 repo，而是让picgo(Core) 和picgo-gui(桌面应用) 在同一个 workspace 里协同开发，解决了之前 Core 升级后 GUI 需要等待 npm 发布才能同步的痛点。

三、核心引擎：PicGo-Core 的插件化流水线

3.1 上传流水线架构

PicGo-Core 的本质是一个上传工作流引擎，它的核心是一个五阶段流水线：

输入 (Input) │ ▼ [beforeTransformPlugins] ← 所有插件全部执行 │ ▼ [Transformer] ← 只执行选中的那一个 │ ▼ [beforeUploadPlugins] ← 所有插件全部执行 │ ▼ [Uploader] ← 只执行选中的那一个 │ ▼ [afterUploadPlugins] ← 所有插件全部执行 │ ▼ 输出 (Output) → imgUrl / url

这个设计精妙之处在于区分了"模块"和"钩子"两种扩展点：

Transformer 负责"把输入变成可上传的格式"（如路径转 buffer），Uploader 负责"把格式化后的内容发到图床"。这两者是单选的 —— 你只能用一种转换策略、一个图床。而三个钩子是多选的 —— 所有注册了的预处理/后处理插件都会跑一遍。

3.2ctx对象：流水线的上下文传递

每个阶段都通过ctx对象传递状态：

interfacePicGoCtx{input:string[]// 原始输入 (文件路径等)output:PicGoOutput[]// 处理后的输出数组config:Record<string,any>// 配置helper:{transformer:LifecyclePlugins// Transformer 注册表uploader:LifecyclePlugins// Uploader 注册表beforeTransformPlugins:LifecyclePlugins beforeUploadPlugins:LifecyclePlugins afterUploadPlugins:LifecyclePlugins}emit(event:string,data:any):void// 事件发射request(options):Promise<any>// HTTP 请求 (自动代理)cmd:{program,register}// CLI 命令注册i18n:{addLocale,translate}// 国际化}

ctx既是数据容器又是服务定位器。每个插件通过ctx.helper.xxx.register(id, { handle })注册自己，通过ctx.output读写数据。这种设计让插件之间可以松耦合地协作 —— 一个beforeUploadPlugin可以修改ctx.output中的fileName，后面的 Uploader 直接用新名字上传。

3.3 插件注册机制

所有五个扩展点都是LifecyclePlugins的实例，统一提供register()方法：

// 最小插件示例module.exports=ctx=>{constregister=()=>{ctx.helper.uploader.register('my-bed',{handle:ctx=>{// 上传逻辑，完成后为每个 output 添加 imgUrlctx.output.forEach(item=>{item.imgUrl='https://my-bed.com/'+item.fileName})returnctx}})}return{register,uploader:'my-bed'// 声明此插件提供的 Uploader id}}

插件的返回值是关键—— 它告诉 PicGo 加载器这个插件注册了哪些模块。一个插件可以同时注册 Transformer + Uploader + Hooks，但同一类型只能有一个实现。

3.4 内置 Transformer 与 Uploader

PicGo-Core 内置了两个 Transformer（path和base64）和七个 Uploader（七牛、腾讯云 COS、又拍云、阿里云 OSS、GitHub、SM.MS、Imgur）。但从 v2.2.0 开始，PicGo 官方不再添加新的第三方图床，所有新图床通过插件提供。这是一个重要的架构决策 —— 核心保持极简，生态通过插件膨胀。

这个决策的代价是用户需要自己安装插件，收益是核心包体积可控、维护成本降低、第三方图床的 bug 不影响核心稳定性。对于个人开源项目，这是最合理的取舍。

四、Electron 主进程：从 LifeCycle 到窗口管理

4.1 LifeCycle 类：启动编排器

主进程的入口是background.ts，它只做两件事：

import{initStaticPath}from'~/main/utils/env'import{bootstrap}from'~/main/lifeCycle'initStaticPath()bootstrap.launchApp()

真正的启动逻辑在LifeCycle类中，它把 Electron 应用生命周期拆成四个阶段：

classLifeCycle{asynclaunchApp(){constgotTheLock=app.requestSingleInstanceLock()if(!gotTheLock){app.quit()// 单实例锁，防止多开}else{awaitthis.beforeReady()// 注册协议、修复 PATH、初始化 i18n、监听 IPCthis.onReady()// 创建窗口、注册快捷键、启动 HTTP Serverthis.onRunning()// 处理 second-instance、activate、开机自启this.onQuit()// 清理全局快捷键、关闭 Server、退出}}}

这个编排器的设计体现了 Electron 应用的几个关键考量：

1. 单实例锁 (app.requestSingleInstanceLock)—— PicGo 是常驻后台的工具，多实例会导致剪贴板监听冲突和端口占用。second-instance事件处理器会把新实例的命令行参数转发给主实例（比如从命令行上传图片）。

2. beforeReady里的 PATH 修复—— macOS 和 Linux 上，Electron 应用从 Dock/Launcher 启动时$PATH不包含用户 shell 的自定义路径（如 Homebrew 安装的node）。fixPath()从 shell 环境恢复$PATH，确保插件安装和 Node.js 调用正常。

3. 协议注册 (picgo://)——protocol.registerSchemesAsPrivileged注册自定义协议，让网页和其他应用能通过picgo://upload触发上传。

4.2 窗口管理器

PicGo 管理三种窗口：

// 窗口创建策略windowManager.create(IWindowList.TRAY_WINDOW)constsettingWindow=windowManager.create(IWindowList.SETTING_WINDOW)// macOS 上不创建 mini 窗口（用托盘替代）if(!isMacOS){constminiWindow=windowManager.create(IWindowList.MINI_WINDOW)}

windowManager是一个窗口注册表 + 工厂模式。每种窗口类型有对应的创建配置（尺寸、是否显示等），通过IWindowListenum 管理窗口标识。macOS 的activate事件会重建窗口（因为 Dock 点击可能关闭了窗口但没退出应用）。

4.3 IPC 通信架构

v3 的 IPC 通信遵循 Electron 安全最佳实践：

Renderer (React) │ │ window.api.xxx() ← preload bridge 暴露的 API │ ▼ Preload Bridge │ │ ipcRenderer.invoke() ← contextIsolation: true │ ▼ Main Process │ │ ipcMain.handle() ← ipcList.listen() 注册所有 handler │ ▼ PicGo-Core / Native APIs

v3 之前，渲染进程直接使用remote模块访问主进程对象，这在contextIsolation: true下不安全。v3 把所有 Electron API 访问迁移到了 preload bridge，渲染进程只能通过window.api.xxx()调用，preload 层通过ipcRenderer.invoke()转发到主进程。

这是 v3 的一个重大 Breaking Change —— 依赖 Vue 特定 GUI 内部实现的插件需要适配新的 IPC 接口。

五、HTTP Server：让任何工具都能调用 PicGo

5.1 为什么需要一个 HTTP Server

PicGo 从 v2.2.0 开始内置了 HTTP Server，监听36677端口。这不是为了做一个 Web 应用，而是为了让其他工具能通过 HTTP 调用 PicGo 的上传能力：

# 通过 HTTP 上传图片curl-XPOST http://localhost:36677/upload\-F"file=@/path/to/image.png"

典型集成场景：

• Obsidian / Typora 等编辑器通过 HTTP API 上传
• VS Code 插件 vs-picgo 通过 HTTP API 调用
• Shell 脚本在 CI/CD 中自动上传图片
• AI Agent (PicGo Skills) 通过 HTTP 上传

Server 实现在src/main/server/目录，使用multer处理文件上传，在LifeCycle.onReady()中server.startup()启动，在onQuit()中server.shutdown()关闭。

5.2 端口冲突处理

作为常驻后台的工具，端口冲突是常见问题。PicGo 的 Server 实现包含了端口检测和优雅降级 —— 如果36677被占用，会尝试其他端口或记录错误日志。

六、v3 重构：Vue → React 的框架迁移

6.1 为什么从 Vue 迁移到 React

这是 v3 最重大的架构决策。PR #1414 的代码变更量：+39,427 行 / -9,580 行，45 个 commits，4 个月工作周期。

迁移的驱动力来自几个方面：

1. React 生态的组件库优势—— shadcn/ui 提供了一套可定制、可拷贝的组件系统，比 Element Plus 更适合 PicGo 这种需要大量自定义表单的工具类应用
2. TanStack 系列库的契合—— TanStack Router (文件路由) + TanStack Query (异步状态) + Zustand (同步状态) 的组合，比 Vue Router + Pinia 更适合 PicGo 的数据流模式（大量异步上传操作 + 云端 API 调用）
3. 类型安全—— React 19 + TypeScript 的类型推导比 Vue 3 + TypeScript 更成熟（特别是vue-tsc的模板类型检查一直是个痛点）
4. 性能—— React 19 的并发渲染对大量图片列表的瀑布流场景更友好

但迁移的代价也很高：

• 所有 Vue 组件重写
• Element Plus → shadcn/ui 的 UI 体系重建
• Vue Router → TanStack Router 的路由重构
• Pinia → Zustand + TanStack Query 的状态管理迁移
• 部分依赖 Vue 特定内部 API 的插件需要适配

6.2 渲染进程的新技术栈

v3 的渲染进程技术栈堪称"2026 年前端最佳实践的集合"：

这个选型组合有几个值得注意的决策点：

1. shadcn/ui 而非 Element Plus—— shadcn/ui 的核心哲学是"Copy-Paste Components"，组件代码直接拷贝到项目里而不是通过 npm 引入。这意味着 PicGo 可以完全控制每个 UI 组件的行为和样式，不需要为了改一个表单验证规则去等 Element Plus 发新版。

2. TanStack Query + Zustand 双轨状态管理—— TanStack Query 管理所有来自 IPC/HTTP 的异步数据（上传结果、插件列表、云端配置），Zustand 管理纯 UI 状态（当前主题、mini 窗口是否打开）。这种分离避免了 Zustand 里塞一堆 loading/error 状态的常见反模式。

3. TanStack Router 文件路由——src/renderer/routes/目录下的文件自动生成路由树 (routeTree.gen.ts)，每个路由文件自带 loader、error boundary 和 suspense boundary。这让 PicGo 的设置页面可以按分类独立加载，不需要一次加载所有设置的代码。

6.3 Dashboard 重构：组件原子化的实践

v3 的 Dashboard 重构是一个值得学习的案例。原始的picgo-dashboard.tsx膨胀到 506 行后难以维护，重构后拆成多个独立模块：

主文件从 506 行降到 238 行，每个文件只负责一个关注点。

特别值得注意的是useDesktopHistoryVisible的实现 —— 用matchMedia监听媒体查询而非手动监听resize事件。这避免了频繁的 resize 事件触发和window.innerWidth读取，利用浏览器自身的媒体查询引擎做高效匹配。

七、PicGo Cloud：从工具到服务的架构升级

7.1 三大子系统

v3 引入了 PicGo Cloud，包含三个子系统：

PicGo Cloud ├── 图床服务 (PicGo Cloud Bed) ← 替代 SM.MS 成为默认图床 ├── 云相册 (Cloud Album) ← 本地历史导入云端 + 自动同步 └── 配置同步 (Config Sync) ← 跨设备配置同步 + 加密

默认图床从 SM.MS 变为 PicGo Cloud是一个重要的商业决策 —— 免费额度 200 文件 + 500MB，注册即可用，降低了新用户的上手门槛。而付费计划提供云相册自动同步等高级功能。

7.2 配置同步的状态管理演进

配置同步的架构演进是 v3 最有趣的微观重构案例：

初始实现：使用 ZustandcloudStore存储所有状态 —— 同步数据 + UI 状态 + loading/error

最终实现：拆分为两层：

Zustand cloudStore (纯 UI 状态) ├── syncEnabled: boolean ├── syncDirection: 'push' | 'pull' | 'both' └── showConflictDialog: boolean TanStack Query (异步数据) ├── useCloudConfigSyncStateQuery │ ├── data: 同步状态 │ ├── isLoading │ └── error └── useCloudQuotaQuery │ ├── data: 配额信息 │ └── refetchOnSyncSuccess

setQueryData和invalidateQueries的使用让同步操作后自动刷新配额信息，不需要手动管理 loading 状态。这是 TanStack Query 的经典用法 —— 把"请求 → 加载 → 成功/失败 → 刷新"这个流程从手动状态管理变成声明式查询。

7.3 三种加密模式

配置同步支持三种加密模式，覆盖了从"懒人模式"到"极客模式"的需求：

Auto 模式的实现细节—— 本地用 AES-256 加密配置后上传，服务端只存密文。下载时本地解密。冲突解决弹窗在密文基础上做 diff 比较是不可能的，所以 E2E 模式下冲突解决需要本地先解密再比较。

7.4 CloudImage 容错设计

云相册的图片展示有一个精巧的容错设计：

<CloudImage src={imgUrl} alt={fileName}> {/* 始终渲染 <img> 标签 */} {/* 生命周期阻止或 onError 时切换到本地 SVG 占位图 */} {/* 两种 SVG: account-frozen (冻结警告) + preview-unavailable (通用失败) */} </CloudImage>

这意味着：

• 正常状态：加载云端图片
• 账号冻结 (grace/frozen/pending_cleanup)：显示冻结警告 SVG
• 图片加载失败：显示"预览不可用" SVG

结合云服务生命周期 (Lifecycle)，这个设计覆盖了所有异常场景 —— 用户欠费、服务宕机、图片 CDN 异常、本地网络中断，每种情况都有对应的视觉反馈而不是空白或报错。

八、插件生态：60+ 图床背后的架构支撑

8.1 插件的完整生命周期

一个 PicGo 插件从安装到运行经历以下阶段：

npm install picgo-plugin-xxx │ ▼ pluginLoader 扫描 node_modules/picgo-plugin-* │ ▼ require(plugin) → 调用 ctx => { register, ... } │ ▼ ctx.helper.xxx.register(id, { handle, config? }) │ ▼ GUI 渲染 config() 返回的配置表单 │ ▼ 上传流水线中按需调用 handle(ctx)

插件的config()方法是一个精妙的双端适配设计：

// 插件定义配置constconfig=ctx=>{return[{name:'token',type:'input',default:'',required:true,message:'请输入 API Token'},{name:'region',type:'list',default:'us-east-1',choices:['us-east-1','eu-west-1','ap-southeast-1']}]}

CLI 端：这个数组传给inquirer.js，渲染成命令行交互提示。
GUI 端：这个数组传给SchemaFormFields组件，渲染成可视化表单（shadcn/ui 的 Input、Select、Textarea）。

同一份配置定义，两个运行环境，零适配代码。这是 PicGo 插件生态能快速增长的关键 —— 图床开发者只需要写一次配置定义，就能同时支持 CLI 和 GUI 用户。

8.2 v3 的插件配置增强

v3 新增了两个重要的配置能力：

1.dependsOn级联下拉

{name:'bucket',type:'list',dependsOn:'region',// bucket 的选项取决于 region 的值choices:(region)=>getBucketsByRegion(region)}

这让像 AWS S3 这种"先选区域再选 Bucket"的多级配置变得可行，之前需要用自定义插件 UI 来实现。

2.editor字段类型

{name:'customTemplate',type:'editor',// 多行文本域default:'',}

在 GUI 中渲染为可调整大小的<Textarea>(shadcn/ui)，在 CLI 中渲染为多行输入。三个共享SchemaFormFields的地方（插件配置、插件转换器、图床上传器配置）自动获得支持。

3. 插件废弃标记

v3 为插件系统增加了deprecated状态标记，帮助维护者标记不再推荐的插件，引导用户迁移到更好的替代方案。这对一个 60+ 插件的生态来说是必要的维护工具。

九、构建工具链的演进

9.1 从 electron-vue 到 electron-vite

PicGo 的构建工具链经历了两次重大迁移：

electron-vue → electron-vite 的迁移 (PR #1361)解决了几个痛点：

• electron-vue 基于 webpack，HMR 速度慢，构建时间长
• electron-vue 不支持 TypeScript 的 native 处理
• electron-vue 的维护者已经停止更新

electron-vite由 alex8088 开发，专为 Electron 应用设计，基于 Vite 的极速 HMR 和原生 TypeScript 支持。迁移后 PicGo 的开发体验大幅提升 —— 冷启动从 20+ 秒降到 2 秒内。

9.2 代码质量保障体系

v3 的代码质量体系包含多个层级：

dpdm的循环依赖检测特别值得一提—— 它在 CI 中作为 lint 的一部分运行，一旦发现循环依赖就报错退出。对于一个 Monorepo 项目，循环依赖是架构腐化的第一信号，这个检测把架构约束变成了自动化流程。

十、踩坑点与设计教训

10.1 Electron 的 PATH 问题

这是 Electron 应用在 macOS/Linux 上最经典的坑。从 Finder/Dock 启动的应用不会继承用户 shell 的$PATH，导致node、npm等命令找不到。PicGo 在beforeReady中调用fixPath()从 shell 配置文件恢复$PATH。

教训：任何需要调用 Node.js 子进程（比如安装插件）的 Electron 应用都必须处理这个问题。

10.2 剪贴板 API 的沙箱兼容

v3 PR 中修复了一个关键 bug：clipboard.writeText在 Electron 22+ 的沙箱预加载中返回undefined。解决方案是改为通过 IPC RPC 调用COPY_TEXT路由：

// preload bridgecontextBridge.exposeInMainWorld('api',{copyText:(text:string)=>ipcRenderer.invoke('COPY_TEXT',text)})// main process handleripcMain.handle('COPY_TEXT',(_,text)=>{clipboard.writeText(text)})

教训：Electron 的contextIsolation: true+ sandbox 模式下，很多之前直接可用的 Node.js API 都需要通过 IPC 转发。迁移到 preload bridge 不是"可选的现代化"，而是"必须的安全修复"。

10.3 云服务状态与 UI 的耦合

v3 开发过程中遇到的一个 bug：免费用户每次渲染都会被强制切换到LOCAL相册视图。根因是 UI 组件在每次 mount 时都检查用户是否付费，而不是只在 paid → free 转换时触发。

修复策略：只在付费状态变化时触发切换，而不是每次渲染时检查。这是一个典型的"响应式过度执行"问题 —— React 的 re-render 机制会放大不必要的副作用。

10.4 版本迁移的向后兼容

PicGo 的migrate/目录包含两个迁移函数：

• updateShortKeyFromVersion212()—— v2.1.2 的快捷键配置格式变更
• migrateAlbumFromVersion230()—— v2.3.0 的相册数据结构变更

这些迁移在beforeReady中执行，确保用户升级后数据不丢失。教训是：任何涉及持久化数据的格式变更，都必须在应用启动时做迁移，而不是让用户手动处理。

十一、效果对比：v2 vs v3

十二、架构启示录

PicGo 的七年演进记录了几个对任何开源桌面工具都有参考价值的架构启示：

1. 核心极简，生态膨胀

PicGo-Core 只内置了 2 个 Transformer + 7 个 Uploader，却支撑了 60+ 图床插件。核心负责流水线引擎，插件负责业务实现。这个分离让核心的维护成本极低（不需要为每个图床的 API 变更发版），而生态的膨胀速度由社区驱动。

2. 双端适配的配置系统

一份config()定义同时服务于 CLI 和 GUI，是 PicGo 插件生态快速增长的核心杠杆。减少适配成本 = 增加生态密度。

3. 框架迁移是战略决策而非技术偏好

从 Vue 到 React 的迁移不是"哪个框架更好"的技术争论，而是"哪个生态更适合 PicGo 的下一个阶段"的战略决策。shadcn/ui 的可定制性、TanStack 系列的异步状态管理、React 19 的并发渲染 —— 这些技术选型服务于 PicGo Cloud 的引入、云相册瀑布流的性能、配置表单的灵活性。

4. 安全倒逼架构升级

contextIsolation: true+ preload bridge 的迁移不是为了"更现代"，而是 Electron 安全最佳实践的强制要求。当平台的安全策略升级时，应用架构必须跟进，否则就会被市场淘汰（Chrome 对remote模块的逐步废弃就是信号）。

5. 云服务需要容错设计

CloudImage 的三级降级（正常图片 → 冻结 SVG → 失败 SVG）和云服务生命周期的阶段感知 (grace/frozen/pending_cleanup)，展示了工具类应用加入云服务后必须考虑的异常场景远多于纯本地应用。

十三、总结

PicGo 不是一个"复杂"的项目 —— 它的核心引擎 (PicGo-Core) 只有几千行代码，流水线架构清晰明了。但它的架构决策密度极高：插件系统的模块/钩子分离、双端配置适配、Core/GUI 的三层解耦、Vue → React 的框架迁移、IPC 安全升级、云服务的容错设计……

这些决策的每一个都不是孤立的技术选择，而是服务于同一个目标：让一个个人开源项目在 7 年内从"够用"进化到"可持续"，同时保持核心的极简和生态的繁荣。

如果你正在做一个 Electron 工具类应用，PicGo 的架构是一本活教材 —— 不需要照搬它的技术选型，但值得理解它每个决策背后的取舍逻辑。

项目链接：

• GitHub: https://github.com/Molunerfinn/PicGo
• PicGo-Core 文档: https://docs.picgo.app/core/
• 插件合集: https://github.com/PicGo/Awesome-PicGo
• VS Code 插件: https://github.com/PicGo/vs-picgo

本文基于 PicGo v3.0.0 (2026-07-01) 的源码和文档撰写，所有代码引用来自 GitHub dev 分支。