起因  我想在同一台 Windows 电脑上同时开两个 WorkBuddy——一个放日常工作流，一个跑长时间的批处理任务，两边互不干扰。  双击桌面图标，没有任何反应，只是把已经开着的窗口弹到了最前面。再点一次，还是一样。  这篇文章记录的，就是我找到原因、并最终实现多开的完整过程。  一、先看日志，别急着猜  多数 Electron 应用都会在用户数据目录下写启动日志。WorkBuddy 的日志在：  %USERPROFILE%\.workbuddy\logs\startup\<日期>\<pid>-<时分秒>.log    打开一份看看，答案就摆在第一屏：  [+6ms]    === Process started === pid=27716 argv=["D:\\WorkBuddy\\WorkBuddy.exe"]

[+413ms]  Phase: single instance lock, gotTheLock=true

[+7271ms] Phase: bootstrap complete - STARTUP COMPLETE    再去翻那些"点了没反应"的记录，它们长这样：  [+322ms] Phase: single instance lock, gotTheLock=false

[+324ms] SingletonLock failed: another instance running or userData dir inaccessible

[+325ms] EXITING: SingletonLock not acquired    结论很清楚：它抢不到"单实例锁"就自己退出了。这是 Electron 的标准做法，不是 bug。  二、单实例锁是什么  Electron 提供了 app.requestSingleInstanceLock() 这个 API：  const gotTheLock = app.requestSingleInstanceLock();

  app.quit();          // 已经有实例在跑，自己退出

  app.on('second-instance', (event, argv) => {

    // 第二个实例启动时会触发这里，通常用来聚焦已有窗口

}    它的作用就是保证"同一时间只有一个实例"。底层实现分平台：  Windows：一个命名互斥体（Mutex）  macOS / Linux：在用户数据目录里放一个锁文件  关键点在于：这个锁是绑定在"应用身份"上的。而应用身份由两部分决定——应用名（app.getName()）和用户数据目录（app.getPath('userData')）。  所以想让两个实例并存，只有两条路：让它们的应用名不同，或者让它们的用户数据目录不同。  三、asar 是透明的  Electron 应用把业务代码打包进一个叫 app.asar 的文件。它看起来是二进制的，其实只是"文件头 + 拼接的源码"——用任何文本搜索工具都能直接搜里面的字符串。  比如搜 requestSingleInstanceLock，就能找到 WorkBuddy 主进程的这一段：  acquireSingletonLock() {

Phase: single instance lock, gotTheLock=${e}

SingletonLock failed: another instance running or userData dir inaccessible

}    印证了前面的判断：抢不到锁 → 立刻退出。  四、官方其实留了开关  继续往下翻，在配置相关的代码里，发现了一个有意思的函数：  function detectInstanceNumber() {

  if (process.env.WORKBUDDY_FORCE_NO_INSTANCE_NUMBER) return '';

  let e = process.env.WORKBUDDY_INSTANCE_NUMBER?.trim();

    return path.basename(t).match(/-(\d+)$/)?.[1] ?? '';

}    这是官方内置的多实例机制，不是外挂。  逻辑是：  1.  优先读环境变量 WORKBUDDY_INSTANCE_NUMBER  2.  没有的话，看程序所在的目录名是不是以 -数字 结尾（比如装在 WorkBuddy-2 里）  3.  拿到实例号后，应用名会变成 WorkBuddy [2]  应用名变了，单实例锁自然就分开了——这正是官方支持并行安装多个实例的设计。  五、光有开关还不够：数据目录  但这里有个坑。如果两个实例共用一个用户数据目录，它们会同时读写同一份数据库、会话文件和本地存储，冲突风险很大。  好在代码里还有第二个开关：  function resolveWorkbuddyConfigDir() {

  return process.env.WORKBUDDY_CONFIG_DIR?.trim()

      || process.env.CODEBUDDY_CONFIG_DIR?.trim()

      || path.join(os.homedir(), resolveWorkbuddyDataFolderName());

}    WORKBUDDY_CONFIG_DIR 是第一优先级。把它指向一个独立目录，整个数据环境（数据库、会话、插件、密钥）就都隔离了。  六、实测  把两个开关一起用上，写成一个启动脚本：  @echo off

set "WORKBUDDY_CONFIG_DIR=%USERPROFILE%\.workbuddy-2"

start "" "D:\WorkBuddy\WorkBuddy.exe"    注意，Windows 批处理文件要保存成 CRLF 换行，纯 LF 有时会让 set 解析异常。  双击运行，验证三点：  1.  进程数变化：从 8 个变成 17 个（Electron 是多进程架构，一个实例本身就有 8 个左右的进程）  2.  新数据目录生成：%USERPROFILE%\.workbuddy-2 被创建，结构完整  3.  启动日志确认：  [+413ms] Phase: single instance lock, gotTheLock=true

[+7271ms] Phase: bootstrap complete - STARTUP COMPLETE    gotTheLock=true —— 第二个实例拿到了属于自己的锁，稳稳跑起来了。  七、一个没绕过去的坎  不过我没能把整条路走通：第二个实例的登录环节会卡住。  日志里是这样：  stuck pending requests  {"channel":"auth:login","ageMs":59774}

rpc VERY SLOW (rejected) {"channel":"auth:login","ageMs":89662}    登录请求发出去之后一直没有响应，大约 90 秒后被超时拒绝。同一时间，它的其他请求（读配置、列插件、查权限）全部正常返回——说明本地服务是健康的，只有登录这一条链路断了。  我怀疑和实例后缀有关：应用会按实例号派生自己的协议标识（workbuddy → workbuddy2），如果这个新协议没能在系统里注册成功，授权完成后就跳不回第二个实例。  试过用环境变量把协议改回标准值，也没解决。所以目前的结论是：多开本身在本地是成立的，但完整可用性取决于服务端的配合。这一步我没有走通，如实记录。  八、几个可复用的经验  1.  先看日志，再猜原因。Electron 应用的启动日志通常会精确记录到"卡在哪一阶段"，比反复试错快得多。  2.  asar 不是黑盒。它只是打包格式，文本搜索直接可用——想搞清楚一个 Electron 应用怎么工作，这是最快的第一步。  3.  环境变量常是官方留的口子。多实例、数据目录、日志路径这类东西，很多产品都会做成环境变量，方便企业部署和测试。先搜 WORKBUDDY_* / CODEBUDDY_* 这类前缀。  4.  单实例锁绑定"应用身份"，即应用名 + 用户数据目录。解决多开问题的钥匙，一定在这两者身上。  5.  本地能跑通 ≠ 全链路可用。涉及账号和服务端的环节，往往还有一层校验，这部分不是改配置能解决的。  写在最后  多开的正当用途其实很实在：把个人账号和公司账号分开、把稳定环境和测试环境分开、让一个窗口跑长任务的同时另一个窗口继续干活。  WorkBuddy 自己内置了实例号机制，说明它本来就考虑过这类场景——只是没做成一个显式的菜单项。  希望这篇记录能帮你少走点弯路。

读懂 Electron 单实例锁：以 WorkBuddy 多开为例#WorkBuddy#

起因  我想在同一台 Windows 电脑上同时开两个 WorkBuddy——一个放日常工作流，一个跑长时间的批处理任务，两边互不干扰。  双击桌面图标，没有任何反应，只是把已经开着的窗口弹到了最前面。再点一次，还是一样。  这篇文章记录的，就是我找到原因、并最终实现多开的完整过程。  一、先看日志，别急着猜  多数 Electron 应用都会在用户数据目录下写启动日志。WorkBuddy 的日志

客户端

开发工具

后端

WorkBuddy多开教程：通过环境变量WORKBUDDY_INSTANCE_NUMBER和WORKBUDDY_CONFIG_DIR实现双实例并行，隔离数据目录避免冲突。本文详解Electron单实例锁原理、asar源码分析及启动脚本配置，实测第二个实例成功运行，但登录环节存在兼容性问题。适合需要同时运行多个工作流的用户参考。

数据库

WorkBuddy 

Windows

Linux

MacOS

2026上云采购 | AI焕新·智启新局

workbuddy

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

WorkBuddy多开教程：通过环境变量WORKBUDDY_INSTANCE_NUMBER和WORKBUDDY_CONFIG_DIR实现双实例并行，隔离数据目录避免冲突。本文详解Electron单实例锁原理、asar源码分析及启动脚本配置，实测第二个实例成功运行，但登录环节存在兼容性问题。适合需要同时运行多个工作流的用...

读懂 Electron 单实例锁：以 WorkBuddy 多开为例#WorkBuddy#

读懂 Electron 单实例锁：以 WorkBuddy 多开为例#WorkBuddy#

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐