基于Electron与Org-mode构建跨平台工作记忆托盘应用-洪萨配资

1. 项目概述：打造你的“工作记忆”托盘

如果你和我一样，是个重度 Org-mode 用户，那你一定体会过那种“信息过载”的甜蜜烦恼。Org 文件里塞满了项目规划、会议记录、待办事项和一闪而过的灵感，它们构成了一个强大的“外部大脑”。但问题也随之而来：当我想快速回到当前最紧要的那几件事时，我需要在几十个文件、成千上万个标题中翻找。那个标记了:pinned:标签的标题，就像大海捞针。我需要一个能让我“聚焦”的工具，一个能把我从信息的海洋里打捞上来，只让我看到当下最重要航标的灯塔。

这就是EspressoBar诞生的初衷。它不是一个全新的笔记或任务管理系统，而是一个极其专注的“工作记忆”托盘应用。你可以把它想象成电脑桌面上的便利贴，或者咖啡机旁的浓缩咖啡杯——小而精悍，随时可取，只承载你此刻最需要关注的内容。它的核心逻辑简单到极致：自动扫描你指定的 Org 目录，把所有带有:pinned:标签的标题抓取出来，然后以一个常驻系统托盘（Windows/Mac 菜单栏/Linux 状态栏）应用的形式，持久地展示在你屏幕的角落。无论你切换了多少个应用，重启了多少次电脑，甚至关掉了 Emacs，你的“焦点区域”始终在那里，触手可及。

这个项目的技术栈选择也很有意思：Electron + React + Tailwind CSS。用前端技术来做一个服务于“上古神器”Emacs 的桌面工具，这种组合本身就带着一种极客的幽默感。它证明了，好的工具可以跨越技术的代沟，解决真实而具体的痛点。接下来，我会带你深入拆解 EspressoBar 的设计思路、实现细节，并分享我在搭建类似工具时踩过的坑和积累的经验。无论你是想直接使用它，还是借鉴其思路构建自己的生产力工具，相信都能有所收获。

2. 核心设计哲学与架构解析

2.1 为什么是“工作记忆”，而不是另一个任务管理器？

在接触 EspressoBar 或类似概念之前，我们需要先厘清一个关键区别：长期存储vs工作记忆。

你的 Org 系统是长期存储：它像一座图书馆或一个数据库，结构严谨，分类清晰，旨在存储你所有的知识、项目和任务。Org-roam 构建的知识网络、按项目分类的.org文件，都属于这个范畴。它的优势是全面、可追溯、体系化。
EspressoBar 瞄准的是工作记忆：这个概念来自认知心理学，指个体进行信息加工和操作时，所能持有的临时信息集合。它容量有限（通常认为是7±2个组块），但存取速度极快。对应到工作中，就是“我今天/本周必须要搞定哪三五件事？”。

很多生产力工具的失败，在于试图用一个工具同时解决“存储”和“提取”的问题，导致界面复杂，干扰信息过多。EspressoBar 的聪明之处在于它做了减法。它不管理任务，不创建内容，它只做一件事：把你已经在 Org 中标记为“重要此刻”的内容，用一种零摩擦的方式，持续呈现在你面前。这种“分离但连接”的设计（Separated but Connected），是它体验流畅的关键。你依然在强大的 Org 生态中管理一切，但通过一个极轻的视图来获取当前焦点。

2.2 技术选型背后的逻辑

为什么用 Electron 来服务 Emacs？这看似矛盾，实则精妙。

跨平台一致性：Emacs 本身是跨平台的，但它的 GUI 和系统集成能力在不同系统上差异很大。Electron 能轻松实现一个在 Windows、macOS、Linux 上外观、行为完全一致的系统托盘应用，这是用 Elisp 写原生插件难以比拟的。
现代 UI 与开发体验：使用 React 和 Tailwind CSS，可以快速构建出美观、响应式的用户界面。对于需要频繁交互的设置页面、列表展示，现代前端框架的开发效率和效果都远胜于传统工具包。
专注核心价值：EspressoBar 的核心价值是“呈现”与“快速跳转”，而不是文本编辑。用 Electron 实现 UI 和系统集成，用emacsclient作为桥梁跳回 Emacs 编辑，让两者各司其职，是最务实的选择。这就像用专业的播放器听音乐，用专业的编辑器写代码。
降低使用门槛：并非每个 Org-mode 用户都是 Elisp 高手。一个可以npm install并双击运行的可执行文件，其上手难度远低于配置一个 Emacs 插件。这有助于工具推广。

注意：Electron 应用常被诟病内存占用大。但对于 EspressoBar 这类极其轻量的后台托盘应用，其内存开销（通常 < 100MB）在现代化硬件上几乎可忽略不计，与其带来的专注度提升相比，性价比极高。

2.3 安全至上的 Electron 架构

EspressoBar 的架构清晰地反映了现代 Electron 应用的安全最佳实践，值得学习：

主进程（Main Process）：这是 Node.js 环境，拥有系统 API 访问权限。它负责所有“危险”操作：文件系统扫描（读取你的 Org 目录）、调用外部二进制文件（emacsclient）、创建和管理系统托盘图标。它作为后端服务运行。
预加载脚本（Preload Script）：这是连接主进程和渲染进程的安全桥梁。它通过contextBridge向渲染进程暴露有限的、白名单化的 API（例如window.electronAPI.scanDirectory），而不是直接开启nodeIntegration（这会导致渲染进程拥有 Node 权限，极其危险）。
渲染进程（Renderer Process）：这是一个被沙箱化的 Chromium 渲染环境，运行你的 React 应用。它无法直接访问文件系统或requireNode 模块，只能通过预加载脚本暴露的 API 与主进程通信。这确保了即使渲染进程被恶意代码控制，损害也被限制在有限范围内。
服务层（Services）：在主进程中，功能被模块化为不同的服务（如OrgFileService,EmacsClientService,CacheService）。这提高了代码的可测试性和可维护性。

这种架构将风险最高的操作隔离在主进程，并通过严格的 IPC（进程间通信）进行控制，是构建可信赖桌面应用的基础。

3. 核心功能实现与实操细节

3.1 Pin 机制：如何从 Org 文件中提取焦点

“Pin”（钉住）是 EspressoBar 的核心交互。它的实现依赖于 Org-mode 强大的标签（Tags）系统。

实操步骤：在你的 Org 文件中添加 Pin

在任何你希望置顶的标题行末尾，加上:pinned:标签。

* TODO 完成季度业务报告初稿 :pinned: ** 收集市场部数据 ** 撰写执行摘要 * 会议记录：与研发部讨论新架构 :work:meeting: * NEXT 预约牙医检查 :personal:pinned:

你可以和其他标签（如:work:、:personal:）共存。EspressoBar 只认:pinned:。

标题的层级与内容：EspressoBar 会抓取该标题的整个子树吗？不会。为了保持列表的简洁和“工作记忆”的特性，它默认只抓取该标题本身的文本。子标题和内容需要你点击“在 Emacs 中打开”后，回到原文件查看。这是一种设计上的取舍，强制你将“焦点”提炼到单个标题行。

EspressoBar 的扫描引擎如何工作？

配置扫描目录：首次启动后，你需要在设置中添加你的 Org 文件所在目录（例如~/org或~/Documents/notes）。支持添加多个目录。
递归文件遍历：主进程中的OrgFileService会递归遍历指定目录下的所有.org文件。这里使用了 Node.js 的fs模块，并针对大量文件做了优化，采用异步流式读取，避免阻塞。
解析与缓存：
- 对于每个.org文件，它不会启动一个完整的 Org 解析器（那太重了），而是采用正则表达式匹配这一轻量级方式。它寻找以*开头的行，并检查行尾是否包含:pinned:标签。
- 匹配成功后，它会提取：文件绝对路径、标题文本、标签列表、所在的精确行号。行号至关重要，它是后续精准跳转的依据。
- 所有提取到的 Pin 信息会被缓存在本地（使用electron-store存为 JSON）。除非文件修改时间戳（mtime）发生变化，否则下次启动会直接读取缓存，极大提升加载速度。
后台静默更新：应用会启动一个静默的setInterval定时器（例如每 30 秒），在后台重新扫描目录，对比文件变化，并更新缓存和 UI。这个过程用户无感知，确保了托盘中的列表总是最新的。

3.2 系统托盘集成：跨平台的“常驻入口”

系统托盘是 EspressoBar 作为“工作记忆”物理载体的关键。Electron 的Tray模块抽象了不同平台的差异。

实现要点：

创建托盘图标：应用启动后，主进程会创建一个Tray实例，并加载一个图标（通常是 PNG 格式，需准备不同尺寸以适应 macOS、Windows 的高分辨率屏幕）。
上下文菜单：右键点击托盘图标时弹出的菜单。EspressoBar 的菜单很简单，通常包含：“显示/隐藏主窗口”、“打开设置”、“退出”。这是通过Menu.buildFromTemplateAPI 构建的。
点击行为：在 macOS 上，通常点击托盘图标是显示上下文菜单；而在 Windows/Linux 上，点击图标通常用于显示/隐藏应用的主窗口。EspressoBar 可能需要处理这些平台差异，提供一致体验。一种常见做法是：左键点击显示主窗口，右键点击显示上下文菜单，这需要通过tray.on('click', ...)和tray.on('right-click', ...)分别处理。
主窗口策略：EspressoBar 的主窗口（即点击托盘图标后弹出的那个列表窗口）应该被设置为无边框、始终置顶、且跳过任务栏（skipTaskbar: true）。这样它看起来就像是一个从托盘“生长”出来的弹出层，而不是一个独立的桌面窗口，更符合其“辅助工具”的定位。

3.3 Emacs 集成：无缝跳转的桥梁

“Open in Emacs” 是连接 EspressoBar（视图）和 Org-mode（编辑）的灵魂按钮。其核心是正确调用emacsclient。

深入原理：emacsclient的工作机制

emacsclient是 Emacs 服务器/客户端架构中的客户端。当你在 Emacs 中执行(server-start)后，Emacs 会启动一个后台服务器进程，并监听一个 socket（Unix 域套接字或网络端口）。emacsclient则通过这个 socket 向服务器发送命令，例如“打开某个文件”。

EspressoBar 的实现步骤：

定位emacsclient二进制文件：这是跨平台的第一道坎。主进程的EmacsClientService会尝试多种策略：
- 检查环境变量PATH：这是最常见的方式。
- 平台特定路径：在 macOS 上，可能会检查/Applications/Emacs.app/Contents/MacOS/bin/emacsclient；在 Windows 上，检查通过 Chocolatey 或安装程序安装的固定路径。
- 用户配置：允许用户在设置中手动指定emacsclient的完整路径，作为兜底方案。
构建命令行参数：找到二进制文件后，构建调用命令。关键参数是：
- --no-wait或-n：告诉emacsclient立即返回，不要等待你编辑完文件。这样 EspressoBar 不会阻塞。
- +LINE:1：这是跳转到精确位置的黑魔法。+LINE:是 Emacs 的通用参数，告诉它打开文件后跳转到指定行。1是行号，即之前扫描时记录的那个标题所在行。
- "/path/to/your/file.org"：文件的绝对路径。最终命令类似：emacsclient -n +LINE:42 /home/user/org/project.org
执行与错误处理：使用 Node.js 的child_process.spawn或exec来执行上述命令。必须妥善处理可能出现的错误：
- Emacs 服务器未运行：捕获错误，提示用户“请确保已在 Emacs 中运行(server-start)或已将(server-start)加入配置”。
- 文件已被删除或移动：提示“找不到指定的 Org 文件”。
- emacsclient未找到：提示用户安装 Emacs 或检查 PATH。
优雅降级（Fallback）：这是 EspressoBar 一个贴心的设计。如果emacsclient调用失败，它会将一段 Elisp 代码复制到你的剪贴板。这段代码形如(find-file "/path/to/file.org") (goto-line 42)。你可以手动切换到 Emacs，粘贴并执行它，同样能达到跳转的目的。这提供了最后一道保障。

实操心得：在开发类似集成工具时，永远不要假设用户环境是完美的。对路径查找、命令执行、错误状态进行层层防御性处理，并提供清晰的、可操作的错误信息和备选方案，是提升工具可靠性的关键。

4. 开发、构建与发布全流程

4.1 从零搭建开发环境

假设你想基于 EspressoBar 的代码进行二次开发或学习，以下是步骤：

# 1. 克隆仓库 git clone https://github.com/fullofcaffeine/EspressoBar.git cd EspressoBar # 2. 安装依赖 (确保你已安装 Node.js 18+ 和 npm) npm install # 3. 启动开发模式 npm start

运行npm start后，会同时启动两个进程：

Electron 主进程：加载主窗口。
Vite 开发服务器：为渲染进程（React 应用）提供热重载（HMR）。你在src/renderer/下修改前端代码，浏览器会即时更新，无需重启整个 Electron 应用。

项目结构速览：

EspressoBar/ ├── src/ │ ├── main/ # Electron 主进程代码 │ │ ├── services/ # 后台服务 (Org扫描, Emacs集成等) │ │ ├── main.js # 主进程入口，创建窗口和托盘 │ │ └── preload.js # 预加载脚本，定义安全暴露的API │ └── renderer/ # 渲染进程 (React 应用) │ ├── App.jsx │ ├── components/ │ └── ... ├── resources/ # 图标等静态资源 ├── tests/ # 测试文件 ├── vite.config.js # Vite 构建配置 ├── electron-builder.json # Electron 打包配置 └── package.json

4.2 使用 Vite 与 Electron 构建生产版本

EspressoBar 使用 Vite 作为构建工具，这比传统的 Webpack 配置更简洁快速。

构建渲染进程：npm run build命令会触发 Vite，将src/renderer/下的 React 代码打包、压缩、优化，输出到dist/目录。
适配 Electron：在vite.config.js中，需要将构建目标 (build.target) 设置为chromeXX（匹配 Electron 的 Chromium 版本），并正确配置入口文件和输出目录，确保主进程能加载到渲染进程的产物。
使用 electron-builder 打包：electron-builder是一个强大的打包工具。它的配置主要在electron-builder.json中：
- appId: 应用唯一标识符（如com.yourname.espressobar）。
- productName: 用户看到的应用程序名称。
- directories.output: 打包产物的输出目录（如release）。
- files: 指定需要打包进最终应用的文件（通常包括dist/,src/main/,package.json, 以及必要的资源文件）。
- 多平台配置：可以配置为一次性打包所有平台（mac,win,linux）的安装包，包括自动代码签名（macOS/Windows）和创建安装程序（DMG, NSIS, AppImage 等）。

一个典型的打包命令是：

# 在 package.json 中配置 "scripts": { "build": "vite build", "dist": "npm run build && electron-builder --mac --win --linux" }

运行npm run dist后，你会在release/目录下找到EspressoBar-1.0.0.dmg(macOS)、EspressoBar Setup 1.0.0.exe(Windows) 等安装文件。

4.3 基于 Conventional Commits 的自动化发布流程

这是 EspressoBar 项目中最具工程化价值的一环。它使用semantic-release实现了完全自动化的版本管理和发布。

这套流程是如何工作的？

约定式提交：所有开发者在提交代码时，必须遵循 Conventional Commits 规范。即提交信息格式为：
```
<type>[optional scope]: <description>
```
例如：
- fix: 修复Windows下托盘图标不显示的问题
- feat: 新增支持通过拖拽文件夹添加扫描目录
- feat!: 重构设置存储方式，旧配置需手动迁移(注意!，表示破坏性变更)
- docs: 更新README中的快速开始指南
CI/CD 流水线（以 GitHub Actions 为例）：当代码被推送到main分支或合并 Pull Request 时，自动触发 GitHub Actions 工作流。
- 步骤一：测试与构建：运行npm run test:e2e，确保所有端到端测试通过。然后运行npm run build和打包命令，生成各平台的可执行文件。
- 步骤二：语义化版本分析：semantic-release工具会分析自上次发布以来，所有符合约定格式的提交信息。
  - 如果只有fix:类型的提交，则发布一个补丁版本（1.0.0->1.0.1）。
  - 如果出现了feat:类型的提交，则发布一个次版本（1.0.0->1.1.0）。
  - 如果出现了feat!:或提交信息中包含BREAKING CHANGE:说明，则发布一个主版本（1.0.0->2.0.0）。
- 步骤三：生成变更日志：semantic-release会根据提交信息，自动生成格式优美的CHANGELOG.md文件。
- 步骤四：发布版本：自动更新package.json中的version字段，并在 GitHub 上创建一个新的 Release 标签（如v1.1.0），将生成的变更日志和构建好的各平台安装包作为附件上传。

这套流程带来的好处：

完全自动化：开发者只需关注代码和提交信息，版本号、CHANGELOG、打包发布全部由 CI 完成。
版本语义清晰：用户通过版本号就能大致判断更新内容的重要性。
变更可追溯：自动生成的 CHANGELOG 是项目宝贵的文档。

踩坑提醒：初次搭建此流程时，最容易出错的是GitHub Token 权限。用于自动创建 Release 和推送版本号回仓库的 Token（通常是GITHUB_TOKEN或自定义的GH_TOKEN）需要具备足够的写入权限（contents: write）。务必在仓库的 Secrets 中正确配置。

5. 深度定制与扩展思路

EspressoBar 作为一个开源项目，其架构为扩展提供了良好基础。以下是一些你可以尝试的定制方向：

5.1 扩展 Pin 的筛选逻辑

目前的逻辑是“所有带:pinned:标签的标题”。你可以修改OrgFileService中的扫描逻辑，实现更复杂的规则：

基于状态的筛选：只显示TODO或NEXT状态的 Pin，忽略DONE的。

// 在解析标题行时，增加状态判断 const headlineRegex = /^\*+\s+(TODO|NEXT|DONE)?\s*(.*?)(?:\s+:([\w:@]+):)?$/; if (tags.includes('pinned') && state !== 'DONE') { // 纳入显示列表 }

基于其他标签的筛选：在设置中增加一个“过滤标签”输入框，例如只显示同时带有:pinned:和:work:的标题。
基于日程的筛选：集成简单的日期解析，只显示今天或本周到期的 Pin（需要解析标题中的SCHEDULED:或DEADLINE:属性，这需要更复杂的 Org 解析器）。

5.2 增强托盘交互

快捷键唤醒：为显示/隐藏主窗口注册全局系统快捷键（如Cmd+Shift+E或Ctrl+Shift+E）。这需要用到 Electron 的globalShortcut模块，并注意在应用失焦时注销快捷键。
通知提醒：对于有截止日期的 Pin，可以在 deadline 临近时，通过系统通知（NotificationAPI）进行提醒。这需要后台定时任务检查日期。
更丰富的上下文菜单：除了“打开”，可以增加“标记为完成”（这会回写 Org 文件，将状态改为 DONE）、“推迟一天”、“复制标题”等操作。这些操作都需要通过主进程调用文件读写或emacsclient执行 Elisp 脚本来实现。

5.3 支持其他笔记应用

EspressoBar 的理念并不局限于 Org-mode。你可以将其改造成一个通用的“焦点托盘”。

适配 Markdown：扫描.md文件，寻找特定的标记，比如注释，或者# [PIN]这样的标题。
适配 Obsidian / Logseq：这些应用的数据存储在本地 Markdown 文件中，但可能有特定的元数据格式（如 Frontmatter）。你可以修改扫描服务，解析 YAML Frontmatter 中的pinned: true字段。
抽象数据源层：设计一个DataSource接口，然后实现OrgDataSource、MarkdownDataSource、ObsidianDataSource等。在设置中让用户选择数据源类型和路径。这样，EspressoBar 就从一个 Org 专属工具，变成了一个连接多种知识库的“统一焦点视图”。

5.4 界面与体验优化

分组与排序：目前的列表是扁平的。可以增加按文件、按标签、按状态分组显示的功能。排序也可以支持按标题、按修改时间、按自定义优先级等。
搜索过滤：在主窗口增加一个搜索框，实时过滤 Pin 的标题内容。
主题支持：跟随系统明暗模式切换，或允许用户自定义主题颜色。

6. 常见问题与故障排查实录

在实际部署和使用类似工具时，你可能会遇到以下问题。这里记录了我的排查思路和解决方案。

6.1 Emacs 集成相关

问题：点击“Open in Emacs”没有任何反应，或者弹出错误。

排查步骤 1：检查 Emacs 服务器是否运行。
- 在 Emacs 中，按下M-x（Alt+x），输入server-start并回车。如果提示“Server started”，则服务已运行。
- 更一劳永逸的方法是将(server-start)或(require 'server)和(server-start)加入到你的 Emacs 初始化文件（~/.emacs.d/init.el或~/.config/emacs/init.el）中。
排查步骤 2：检查emacsclient命令是否能在终端运行。
- 打开系统终端（如 Terminal, CMD, PowerShell）。
- 输入emacsclient --version。如果显示版本信息，说明命令可用且已在 PATH 中。
- 如果提示“command not found”，你需要找到emacsclient的安装路径，并将其添加到系统的 PATH 环境变量中，或者直接在 EspressoBar 的设置中指定其完整路径。
排查步骤 3：测试基本跳转功能。
- 在终端中，使用一个已知存在的文件测试：emacsclient -n +LINE:10 ~/path/to/test.org。
- 如果这个命令能成功在 Emacs 中打开文件并跳转到第10行，说明emacsclient和服务器通信正常。问题可能出在 EspressoBar 构建的命令行参数（特别是文件路径或行号）上。
排查步骤 4：查看 EspressoBar 的日志。
- 在开发模式下（npm start），错误信息通常会打印在启动应用的终端控制台里。
- 在生产版本中，日志可能输出到特定的文件。在 macOS 上，可以尝试在终端运行~/Library/Logs/EspressoBar/log.log（路径可能不同）。查看日志中关于执行emacsclient命令的错误输出。

问题：跳转到了文件，但位置不对（不是标题所在行）。

原因：行号计算错误。EspressoBar 在扫描时记录的是标题在文件中的绝对行号。但如果文件使用了#+INCLUDE等指令，或者标题前面有折叠的源代码块，Emacs 实际打开时显示的行号可能与物理行号有偏差。
解决方案：EspressoBar 目前使用的是物理行号，对于绝大多数简单 Org 文件是准确的。如果遇到偏差，可以考虑更复杂的方案：在扫描时，不仅记录行号，还记录标题的全文内容。跳转时，不使用+LINE:参数，而是使用--eval参数执行一段 Elisp 脚本，在文件中搜索该标题内容。但这会降低跳转的可靠性（标题内容可能重复）和速度。

6.2 文件扫描与性能

问题：扫描大量 Org 文件时，应用启动慢或界面卡顿。

原因：同步、递归地读取和解析所有文件，在文件数量多（如超过1000个）时会阻塞主进程，导致界面无响应。
解决方案（EspressoBar 已采用）：
1. 异步与非阻塞：使用 Node.js 的fs.promises.readdir和fs.promises.readFile进行异步操作。
2. 增量扫描与缓存：首次扫描后，将结果（文件路径、Pin 信息、文件修改时间mtime）缓存到本地。下次启动时，先读取缓存，然后只检查那些mtime发生变化的文件，进行增量更新。
3. 节流与防抖：在用户频繁修改设置（如添加扫描目录）时，不要立即触发全量扫描。可以设置一个延迟（如500毫秒），等用户停止操作后再开始扫描。
4. Web Worker：对于极其耗时的解析任务（如果未来引入完整 Org 解析器），可以考虑放入 Web Worker 线程中执行，避免阻塞 UI 线程。

问题：某些 Org 文件中的 Pin 没有被识别。

排查步骤 1：检查标签格式。确保:pinned:标签紧跟在标题文本后面，中间有空格，且标签前后都有冒号。例如* 标题 :pinned:是正确的，* 标题:pinned:（缺少空格）可能无法被简单正则匹配。
排查步骤 2：检查文件编码和换行符。确保文件是 UTF-8 编码。Windows 的 CRLF (\r\n) 和 Unix 的 LF (\n) 换行符，在正则匹配$（行尾）时可能会有影响。使用更健壮的正则，如/(.*?)\s*:pinned:\s*$/。
排查步骤 3：检查文件权限。确保应用有权限读取该目录和文件。

6.3 打包与分发问题

问题：打包后的应用在别的电脑上无法运行，提示模块找不到。

原因：通常是因为依赖项没有正确打包。Electron 应用包含 Node.js 环境，但一些原生模块（native addons）需要针对目标平台重新编译。
解决方案：
1. 确保在package.json的dependencies中列出了所有运行时必需的包，而不是devDependencies。
2. 对于需要原生编译的模块，使用electron-builder的asarUnpack配置项，将这些模块从 ASAR 归档中解压出来，因为它们在压缩包内无法运行。
3. 在 CI 流水线中，为每个目标平台（macOS, Windows, Linux）分别构建，确保原生模块在正确的平台上编译。

问题：macOS 应用无法通过公证（Notarization），用户打开时被警告。

原因：从 macOS Catalina 开始，所有分发的应用都需要经过 Apple 的公证，否则会被 Gatekeeper 拦截。
解决方案：
1. 你需要一个 Apple Developer 账号。
2. 在electron-builder.json中配置你的开发者 ID 证书和 App 专用密码。
3. 在 CI 脚本中，构建完成后调用electron-builder的公证命令。electron-builder内置了对公证流程的支持，可以自动完成上传、等待、添加票据（staple）等一系列操作。
4. 这是一个相对复杂的过程，涉及证书管理、脚本编写，建议仔细阅读electron-builder和 Apple 的官方文档。

开发像 EspressoBar 这样的工具，最大的成就感来自于它切实地融入并改善了你自己的工作流。它不追求功能的庞杂，而是死死咬住“减少上下文切换、保持焦点”这一个痛点，并用一种优雅的技术组合将其解决。从最初的“这想法不错”，到一步步实现文件扫描、托盘集成、Emacs 跳转，再到搭建自动化的发布流水线，整个过程就像打磨一件趁手的兵器。它可能永远不会有庞大的用户群，但在那些同时热爱 Emacs 的严谨和现代 UI 的便捷的极客手中，它就是独一无二的生产力倍增器。如果你也被“信息过载”所困扰，不妨试试 EspressoBar，或者以它为蓝本，打造属于你自己的“工作记忆”外挂。