企业官网建设流程全解析

• 桌面应用
• 即时通讯

本文基于 teams-for-linux 仓库中的架构决策记录 ADR-010（多窗口支持），完整还原项目为何在 2025 年 11 月拒绝为同一账号提供多窗口能力，梳理单窗口架构的源码级约束（单实例锁、IPC 白名单、浏览器工具假设），并解释该决策在 2026 年 9 月为何被推翻、由更窄的 ADR-032 取代。读完后，你能理解在 Electron 封装 Web 应用这一场景下，"多窗口"看似简单、实则牵动全局状态与生命周期设计的本质原因，以及一个被否决决策如何沉淀为后续演进的基石。

ADR-010 的文档定位与状态

ADR-010: Multiple Windows Support for Single Account 是项目 ADR（Architecture Decision Record，架构决策记录）序列中的一员，位于 docs-site/docs/development/adr/ 目录下。它最初在 2025 年 11 月做出"拒绝多窗口"的决策；在当前的仓库版本中，其状态被标注为已被 ADR-032 取代（Superseded），分析内容保留下来作为历史记录。

这个"状态"本身值得注意：ADR-010 的拒绝前提——"Teams Web 应用不容忍同一账号的第二个实例"——在 2026 年 9 月被实测推翻（浏览器标签页测试 + 实时通话期间的应用内 spike）。因此本文既是对一次被否决决策的技术复盘，也是观察"前提被证伪后，一个架构决策如何被更精准的新决策取代"的完整样本。

问题背景：Issue #1984 的需求

该决策源于需求 Issue #1984：用户希望像原生 Windows 版 Teams 客户端那样，为单个账号打开多个窗口，支持：

• 将单条聊天弹出为独立窗口（Pop-out windows for individual chats）
• 为会议提供独立窗口（Separate windows for meetings）
• 同时访问会议与聊天对话（Simultaneous access to meetings and chat conversations）

用户在报告中认为 Teams PWA 曾经支持过该功能、后来被禁用。调研澄清了这一误解：Teams PWA 从未原生支持多窗口或聊天弹出，这是 Web 应用本身的限制，而非 Electron 封装层的问题。

核心决策：拒绝多窗口支持

决策结论：拒绝多窗口支持（Reject multiple windows support）。应用继续采用单窗口模型。

拒绝理由共有五条，逐条对应源码中可验证的事实。

1. Teams PWA 的固有限制

Microsoft Teams PWA 不原生支持多窗口或聊天弹出。这是 Web 应用层面的根本限制，而非 Electron 封装层的问题。即使封装层强行创建多个BrowserWindow，底层 Web 应用也可能因认证冲突、共享 Worker 等预期外的行为而运行不正常。

2. 现有架构假设单窗口运行

当前架构从多处默认了"只有一个窗口"这一前提。以下源码可以佐证这些假设：

单实例锁。应用入口 app/index.js 通过app.requestSingleInstanceLock()请求单实例锁，失败则直接app.quit()，并在拿到锁后绑定second-instance事件（app/index.js）。这从启动层面就锁死了"一个账号一个进程实例"的模型。

const gotTheLock = app.requestSingleInstanceLock(); // ... if (gotTheLock) { app.on("second-instance", mainAppWindow.onAppSecondInstance); // ... } else { console.info("App already running"); app.quit(); }

IPC 通道白名单。所有渲染进程发起的 IPC 调用都要通过 app/security/ipcValidator.js 中的allowedChannels允许列表校验。ADR-010 决策时记录为约 72 条通道，全部按"单窗口通信"设计；当前代码中该允许列表已扩展到 70 多条以上，且每条通道的 handler 都默认只有一个窗口作为发送方。

浏览器工具假设单窗口上下文。app/browser/preload.js 中的模块列表加载了二十余个app/browser/tools/下的工具（tray 图标更新、活跃度跟踪、认证、通话状态等），它们普遍以模块级变量维护状态，默认自己就是唯一的那个窗口。

状态管理分散在模块级变量中。例如通话状态用一个单一的isOnCall布尔标志表示（见 app/mainAppWindow/browserWindowManager.js），这种"全局只有一个通话"的表达方式在多窗口下无法直接成立。

3. 需要大范围重构

要让多窗口成立，几乎每个 IPC handler 都需要引入"窗口标识 + 状态聚合"；浏览器工具需要跨窗口协调。而这一重构带来一系列没有明确答案的问题：

• 托盘图标显示的未读数该取哪个窗口？
• 通话状态如何跨窗口处理？
• 通知该发给哪个窗口？
• 屏幕共享状态如何管理？

4. 收益不确定

即便实现，Teams Web UI 也可能因认证/会话冲突、预期单窗口的共享 Worker/Service Worker、以及面向非此用例设计的 Web 应用的意外行为，而无法在多窗口下正确工作。

5. 高维护负担

会显著增加代码库复杂度，并随着 Teams Web 持续演进带来持续的维护挑战。

备选方案对比

ADR-010 认真评估并否决了三种方案，每条都写明了优缺点与拒绝理由。

方案 1：允许多个独立实例

用不同的userData目录运行多个完全独立的实例。

• 优点：实现简单（移除单实例锁即可）、每个窗口完全隔离、无需状态同步。
• 缺点：每个实例有独立托盘图标、窗口间无协调、内存占用更高、登录会话独立、且并未实现用户期望的"弹出"体验。
• 拒绝原因：无法提供用户期望的一体化体验。不过文档保留了余地——可以作为高级用户选项通过 CLI 参数提供（这一点在后文的"现有变通方案"中落地）。

方案 2：主窗口 + 副窗口模式

保留一个主窗口，允许功能受限的副窗口。

• 优点：全局状态的归属清晰、复杂度低于完整多窗口、与原生客户端行为一致。
• 缺点：仍需大量 IPC 重构、浏览器工具需要窗口类型感知、Teams Web UI 是否支持该模型未知、窗口生命周期管理复杂。
• 拒绝原因：在 Teams PWA 限制下，高实现成本换取不确定的收益。值得注意的是，这正是后来 ADR-032 最终采用的方向——当 ADR-010 拒绝它的前提（"PWA 不容忍同账号并发实例"）被证伪后，这条窄路径重新变得可行。

方案 3：单窗口内的 BrowserViews

用 Electron 的BrowserViews在单窗口内创建"虚拟"窗口。

• 优点：无需 IPC 重构、单窗口上下文得以保留、内存占用更低。
• 缺点：不是真正的独立窗口（难以移到不同显示器）、需要自定义窗口管理 UI、不符合用户预期。
• 拒绝原因：无法提供用户想要的真正独立窗口体验。

现有变通方案：多实例运行

ADR-010 的"后续考量"部分明确指出，用户现在就能通过指定不同的用户数据目录来运行多个独立实例：

# 实例 1（默认） teams-for-linux # 实例 2（独立 profile） teams-for-linux --user-data-dir=/path/to/profile2

每个实例独立运行，特性包括：

• 独立托盘图标
• 独立登录会话
• 独立配置
• 更高内存占用
• 实例间无协调

文档强调：这是一个 workaround，并非原生客户端那种一体化多窗口体验，但它确实让用户能同时查看不同账号或上下文。这与上面"方案 1"被保留为高级选项的思路一致——--user-data-dir是 Electron/Chromium 的标准命令行开关，应用直接透传，无需额外代码。

后续演进：ADR-010 如何被 ADR-032 取代

理解 ADR-010 被取代的机制，是理解整个多窗口演进的关键。ADR-032: Opt-in Secondary Window for the Same Account During Calls 在 2026 年 9 月提出，取代了 ADR-010。它指出 ADR-010 的多个前提已不再成立：

前提被证伪。ADR-010 担心的"潜在认证/会话冲突"并未出现。2026-09-10，在一次客户端通话期间从浏览器标签页重新加入同一会议：无提示、无强制接管、两个实例都在、名册只显示一个参与者；2026-09-18 的 spike 在通话进行中用生产preload.js打开第二个BrowserWindow，该窗口在一秒内以已登录状态加载、作为完整客户端工作数分钟，而第一个窗口的通话未受影响。

当初假设"缺失"的构件如今都已存在。ADR-032 列举了这些可复用的现成能力（均已在当前代码中验证）：

• 会议链接拦截：app/mainAppWindow/index.js 的onNewWindow通过meetupJoinRegEx拦截会议链接并在主窗口加载（其默认正则见 app/config/defaults.js）。
• 可复用的窗口打开策略：app/mainAppWindow/profileWindowOpenPolicy.js 已是一个针对非主 webContents 的窗口打开策略。
• 按会话注册的屏幕共享选择器：setDisplayMediaRequestHandler按会话注册，同分区的第二窗口自然继承。
• 通话状态事件链路：speakingIndicator从 WebRTC stats 检测通话并经activityHub发出call-connected/call-disconnected，ActivityManager转发为 IPC，browserWindowManager转成应用事件。
• Graph 日历访问：携带Calendars.Read的 Teams 会话令牌（见 ADR-030），GraphApiClient.getCalendarView()能取回带onlineMeeting.joinUrl的日程。

ADR-032 的决策：新增一个可选（opt-in）副窗口——第二个BrowserWindow加载同一账号的 Teams Web 应用，让通话留在一个窗口、另一个窗口保持为完整客户端。配置项secondaryWindow.enabled（默认false），不改变现有用户行为。通话从不被"移动"，它只存在于被加入或被应答的那个窗口里。

这解释了为什么 ADR-010 的"拒绝"并非终局：它基于 2025 年 11 月的证据做出了当时最合理的选择；当关键前提在 2026 年 9 月被实测推翻、且所需构件已齐备时，一条更窄、更聚焦的"通话期间副窗口"设计便取代了宽泛的"多窗口支持"。

决策记录的方法论价值

ADR-010 展示了架构决策记录的三个实践要点，对维护 Electron + Web 应用的项目尤有参考价值：

• 前提与决策分离记录：ADR-010 把"为什么拒绝"（五条理由）与"基于什么前提"（PWA 限制、构件缺失）分开，使得前提被证伪时只需引入新决策取代，而非改写历史。
• 拒绝也要留出口：方案 1 被拒的同时保留了"可作为 CLI 高级选项"的余地，最终落地为--user-data-dir变通方案。
• 关联可追踪：文末的 Related 部分列出了单实例锁、窗口打开 handler、IPC 校验等源码位置，让"拒绝"这一决策能被后续读者（及 ADR-032）快速定位与复用。

关键源码与文档索引

• ADR-010 多窗口支持决策记录
• ADR-032 通话期间副窗口（取代 ADR-010）
• 单实例锁实现 app/index.js
• 窗口打开/会议链接拦截 onNewWindow app/mainAppWindow/index.js
• meetupJoinRegEx 默认配置 app/config/defaults.js
• IPC 通道白名单 app/security/ipcValidator.js
• 浏览器工具模块列表 app/browser/preload.js
• 通话状态标志 isOnCall app/mainAppWindow/browserWindowManager.js
• 可复用窗口打开策略 app/mainAppWindow/profileWindowOpenPolicy.js

（本文所有结论均基于当前仓库文档与源码；ADR-010 中标注的行号如app/index.js:61、app/mainAppWindow/index.js:530-553是决策当时的位置，当前代码中对应实现已移动至文中给出的实际行号。）

• 桌面应用
• 即时通讯