我去年给一个Mac端的Electron工具加“双窗口分屏”功能的时候第一反应跟很多人一样——直接让用户按绿键把两个窗口拖到左右两侧不就行了反正macOS自带分屏。但方案评审时产品一句话问住我了“两个窗口中间那个可拖拽的分隔条呢”系统分屏压根不给你这个能力Electron里虽然有多个BrowserWindow的机制但窗口间的布局同步、拖拽重排、边界防抖都得自己一个个解决。这篇就是把完整实现过程写下来。适合正在做Electron多窗口布局、想在Mac上实现类似IDE分屏交互的朋友也适合刚接触Electron主进程与渲染进程通信、想知道怎么管理多个窗口实例的入门开发者。核心内容就三块双窗口基础架构怎么搭、左右半屏定位算法怎么写、分隔条拖拽的IPC链路如何做到不卡顿。1. 分屏需求拆解先搞明白你要做哪种分屏1.1 为什么不用macOS系统自带的分屏我先说结论如果你的需求只是“两个窗口快速占据屏幕左右两半”那系统自带的分屏已经完全够用甚至不用写一行代码。用户长按绿色按钮窗口就会进入分屏选位模式选左边选右边都行。但这里有几个硬伤做过实际项目的人应该都有体会系统分屏的宽高比是固定的两个窗口各占50%你没法让左窗口60%、右窗口40%也没法拖动中间分隔条微调。进入分屏后窗口的位置和尺寸由系统接管Electron里setBounds的调用会被系统忽略或者延迟生效两个窗口之间的“同步感”就没了。系统分屏要求窗口可以被重新“合并”和“拆分”但你的窗口如果是无边框的frame: false绿色按钮的行为会变得非常奇怪甚至不出分屏选项。所以如果你的场景是“左编辑右预览”“左图表右配置”“左主界面右调试面板”需要精确控制两个窗口的占比那系统分屏这条路走不通。我最终选择的是应用内自建双窗口布局一个主窗口、一个面板窗口、中间一条可拖拽分隔条全部由Electron主进程控制坐标和尺寸。1.2 需求边界拖拽分屏其实是“两次交互”的组合光说“拖拽分屏”其实有歧义开发前一定先跟用户对齐交互细节。我这次要做的功能拆开看是两件事第一件事打开第二个窗口并完成左右分屏定位。用户在菜单栏点击“分屏模式”主进程同时创建或复用两个BrowserWindow把它们分别放置到当前显示器的左右两半中间留出几像素空隙。第二件事拖动中间分隔条实时调节两个窗口宽度。鼠标按住分隔条左右移动主窗口和面板窗口的边界跟着平滑移动拖完之后两个窗口仍然保持无缝对接。这两件事对应的技术点完全不同。第一件事靠screen模块和窗口setBounds第二件事靠渲染进程捕获鼠标事件、通过IPC通知主进程、再同步修改两个窗口的几何尺寸。把这两件事拆开想后面的代码就不会写成一团。我强烈建议在做之前画一下状态图有哪些窗口实例、它们之间是什么关系、拖拽过程中谁拥有“布局控制权”。我自己是踩过坑的一开始把拖拽逻辑写在渲染进程里想让窗口B自己挪动自己结果发现跨窗口的坐标系统一塌糊涂后来才把所有布局计算和窗口定位全部收敛到主进程渲染进程只负责上报鼠标坐标。这个架构决策让后面所有问题都变得可追踪。2. 双窗口基础搭建BrowserWindow创建、实例管理与通信协议设计2.1 创建两个“平级”的窗口而不是父子窗口打开第二个Electron窗口很多人第一反应是给new BrowserWindow传入parent: mainWin。这个做法我强烈不推荐。父子窗口在macOS上有默认行为子窗口会被父窗口“带着走”父窗口移动时子窗口跟着移动而且子窗口永远置顶显示在父窗口之上。分屏场景下两个窗口应该是平级关系——各自独立移动、独立调整尺寸中间只通过主进程做坐标同步。所以创建时不要设置parent就用普通的两个BrowserWindow实例const { app, BrowserWindow, ipcMain, screen } require(electron); const path require(path); let mainWin null; let panelWin null; function createWorkWindow({ page, frame true }) { const win new BrowserWindow({ width: 800, height: 600, frame, show: false, backgroundColor: #1e1e1e, webPreferences: { preload: path.join(__dirname, preload.js), contextIsolation: true, nodeIntegration: false, }, }); win.loadFile(views/${page}.html); win.once(ready-to-show, () win.show()); win.on(closed, () { // 在 close 回调里把全局引用置空避免再次操作已经销毁的窗口 if (win mainWin) mainWin null; if (win panelWin) panelWin null; }); return win; } function openSplitView() { if (mainWin panelWin) { layoutSplit(mainWin, panelWin, currentRatio); return; } mainWin createWorkWindow({ page: index.html }); panelWin createWorkWindow({ page: panel.html, frame: false }); layoutSplit(mainWin, panelWin, currentRatio); }几个细节说明一下show: false加ready-to-show再展示是避免白屏闪烁的标准做法。窗口加载页面期间如果直接show()用户会先看到一片空白或者默认背景色体验很糟糕。macOS上尤其明显因为系统默认的窗口背景是白色跟深色界面对比强烈。frame: false用在面板窗口上去掉标题栏和关闭按钮视觉上更接近一个“内嵌面板”跟分隔条、布局系统配合起来也更干净。副作用是这个窗口没法被鼠标拖动移动但这正好符合需求——分屏模式下窗口位置由主进程锁定用户不需要手动拖它。contextIsolation: true和nodeIntegration: false是Electron的安全基线。渲染进程不能直接访问Node.js全局对象只能通过preload脚本暴露的接口通信。分屏功能涉及渲染进程发坐标、主进程改窗口位置通信边界必须清楚否则后面排查问题会非常痛苦。2.2 用模块级状态管理窗口实例不要依赖全局变量上面的代码用了mainWin和panelWin两个模块级变量看起来简单但项目一大了就会遇到一个问题closed事件之后你忘了把mainWin置空然后去调用mainWin.setBounds()Node直接抛异常。我自己在开发时就遇到过这种情况——用户在分屏模式下关掉了面板窗口主进程还在按老逻辑给两个窗口同步位置结果进程直接崩溃。后来我改成用一个Map来管理所有窗口实例const windows new Map(); function registerWindow(key, win) { windows.set(key, win); win.on(closed, () windows.delete(key)); } function getWindow(key) { return windows.get(key); }这样做的另一个好处是将来如果要支持三窗口、四窗口分屏只需要扩展key的集合主进程的逻辑不用改结构。比如后面做“左中右三栏”布局就能直接复用这套注册管理机制。再加上合理的类型定义我一般连着key的类型也一并定义清楚整个多窗口管理会非常清晰。2.3 preload桥接主渲染进程的最小消息协议现在两个窗口已经有了但怎么把鼠标坐标从渲染进程安全地送出来我在preload脚本里暴露了一套专门的API只允许分屏相关的三个操作开始拖拽、移动拖拽、结束拖拽。// preload.js const { contextBridge, ipcRenderer } require(electron); contextBridge.exposeInMainWorld(electronAPI, { startDrag: (payload) ipcRenderer.send(split-drag-start, payload), moveDrag: (payload) ipcRenderer.send(split-drag-move, payload), endDrag: () ipcRenderer.send(split-drag-end), });渲染进程收到鼠标事件后只需要调用window.electronAPI.moveDrag({ x: e.clientX, y: e.clientY })坐标数据会进入主进程的IPC监听器。所有布局计算都在主进程完成渲染进程完全不碰screen模块也不碰其他窗口的引用。这是我在这个项目里坚持的架构原则渲染进程只能“上报事件”不能“控制全局”。3. 分屏定位核心算法workArea计算、多显示器坐标与setBounds时机3.1 找到“正确”的显示器光标坐标与workArea做完窗口管理下一步是把两个窗口放到左右两半。这里有一个特别容易坑人的地方很多教程直接写screen.getPrimaryDisplay()但用户如果在双屏系统的副屏上点击“分屏模式”两个窗口跑到主屏上去了体验非常奇怪。正确做法是使用screen.getDisplayNearestPoint(cursorPoint)获取鼠标当前所在的那个显示器。function getCurrentDisplay() { const cursor screen.getCursorScreenPoint(); return screen.getDisplayNearestPoint(cursor); }拿到显示器对象后不要直接用display.bounds要用display.workArea。bounds是整个显示器的物理范围包含菜单栏、Dock栏占用的区域。workArea才是用户真正能摆放窗口的区域。Mac上如果不用workArea窗口底部会被Dock挡住一部分或者顶部被菜单栏顶出屏幕代码跑通后一看到这个细节才发现之前都白写了。3.2 两个窗口的rect分配公式与最小宽度保护分屏布局的核心就是一个矩形分配公式。假设当前显示器的可用区域是workArea宽度为totalWidth高度为height左右窗口之间留一个gap我一般用2像素视觉上刚好一条细缝当前比例是ratio0到1之间0.5代表各占一半。function computeSplitRects(display, ratio) { const { x, y, width, height } display.workArea; const gap 2; const minWidth 320; // 每个窗口的最小宽度保护 const maxRatio 1 - (minWidth * 2 gap) / width; const safeRatio clamp(ratio, minWidth / width, maxRatio); const mainWidth Math.floor((width - gap) * safeRatio); const panelX x mainWidth gap; return { main: { x, y, width: mainWidth, height }, panel: { x: panelX, y, width: width - mainWidth - gap, height }, }; }这里clamp函数负责把比例限制在合法范围内防止用户把分隔条拖到一边后另一个窗口被压缩到接近消失。minWidth设为320是有讲究的小于这个宽度时窗口里的人很难再正常操作所以我在拖拽逻辑里也用了同一套限制。拖拽和分屏共用一套计算函数代码维护成本大大降低。3.3 setBounds一步定位避免状态中间态拿到两个rect之后主进程调用窗口的setBounds方法。这里有一个细节很容易被忽略setBounds应该一次设置完整边界而不是先setPosition再setSize。分开调用会出现“窗口A已经移动、窗口B还在原位”的中间状态虽然只有一个事件循环的时间差但视觉上会有明显的闪烁感。function layoutSplit(mainWin, panelWin, ratio) { if (!mainWin || mainWin.isDestroyed() || !panelWin || panelWin.isDestroyed()) return; const display getCurrentDisplay(); const rects computeSplitRects(display, ratio); mainWin.setBounds(rects.main, false); panelWin.setBounds(rects.panel, false); }setBounds第二个参数animate我在macOS上测试时发现设为false更合适。如果设为true拖拽过程中每个帧都会触发一段动画过渡两个窗口来回追赶画面会非常“肉”完全跟不上鼠标速度。关掉动画后窗口边界跟鼠标几乎是实时同步的手感立刻直线上升。4. 拖拽分隔条的交互链路独立窗口方案、IPC协议与20ms节流4.1 六像素宽的无边框小窗口就是分隔条本体分隔条怎么实现我试过两种方案第一种把分隔条画在主窗口的HTML里通过CSS和JS控制。这个方案的问题在于分屏时鼠标移到分隔条上它只属于主窗口的渲染区域面板窗口无法感知而且窗口A和窗口B之间那2像素gap是真实的屏幕间隙不是CSS能覆盖的区域在gap附近鼠标会“掉”到另一个窗口下面。第二种做一个独立的、无边框、透明背景的小窗口宽6像素高度跟随屏幕。鼠标移入这个窗口时系统会把光标样式自动改成col-resize。这个方案最稳因为它天然处于两个窗口之间不依赖任何一个窗口的渲染层。我在实际项目里用的就是这个方案运行起来几乎没有存在感但交互却很可靠。function createDividerWindow() { const display getCurrentDisplay(); const { x, y, width, height } display.workArea; dividerWin new BrowserWindow({ x: Math.floor(x width / 2 - 3), y, width: 6, height, frame: false, transparent: true, resizable: false, movable: false, alwaysOnTop: true, skipTaskbar: true, focusable: false, webPreferences: { preload: path.join(__dirname, preload.js), contextIsolation: true, nodeIntegration: false, }, }); dividerWin.loadFile(views/divider.html); return dividerWin; }divider.html里就是一段居中的竖线样式注意要overflow: hidden整个窗口不允许滚动。鼠标指针样式可以直接在CSS里写html, body { margin: 0; padding: 0; height: 100%; overflow: hidden; } body { cursor: col-resize; background: transparent; }分隔条窗口本身的背景是透明的所以用户看到的只是一条两像素的竖线但实际可点击区域有6像素宽手感上比纯两像素线宽容很多拖拽不容易脱手。4.2 拖拽事件链start/move/end三阶段设计分隔条窗口加载完成后在渲染进程里监听鼠标事件。三个事件构成完整链路mousedown的时候发送split-drag-start携带当前鼠标坐标。mousemove的时候发送split-drag-move携带最新坐标。mouseup的时候发送split-drag-end。let dragging false; document.addEventListener(mousedown, (e) { dragging true; window.electronAPI.startDrag({ x: e.clientX, y: e.clientY }); }); document.addEventListener(mousemove, (e) { if (!dragging) return; window.electronAPI.moveDrag({ x: e.screenX, y: e.screenY }); }); document.addEventListener(mouseup, () { dragging false; window.electronAPI.endDrag(); });这里有两个细节需要交代清楚。第一mousemove里我传的是e.screenX和e.screenY也就是鼠标在全屏幕坐标系下的绝对坐标。分隔条窗口自己只有6像素宽窗口内部的相对坐标clientX变化范围太小没法准确反映用户的拖拽距离必须在主进程里用屏幕绝对坐标做计算。第二为什么把dragging状态放在渲染进程而不是主进程因为主进程只处理消息如果渲染进程在mousedown之后不小心没有触发后续事件主进程无法自行判断拖拽是否还在继续。渲染进程维护一个布尔值可以保证没有坐标垃圾消息持续外发。主进程端的处理逻辑就是维护一个拖拽状态对象和一个“待处理坐标”指针let currentRatio 0.5; let dragState null; let pendingDragPoint null; let dragFlushTimer null; ipcMain.on(split-drag-start, (_event, point) { const display getCurrentDisplay(); const { x, width } display.workArea; // ratio 增量按显示器宽度折算 dragState { startDisplayWidth: width, startRatio: currentRatio, startScreenX: point.x, }; pendingDragPoint point; }); ipcMain.on(split-drag-move, (_event, point) { if (!dragState) return; pendingDragPoint point; scheduleDragFlush(); }); ipcMain.on(split-drag-end, () { dragState null; pendingDragPoint null; if (dragFlushTimer) { clearTimeout(dragFlushTimer); dragFlushTimer null; } });主进程记录拖拽开始时的startRatio和startScreenX在移动过程中用“当前X - 起始X”除以显示器宽度得到比例增量。这样拖拽距离在整个显示器宽度范围内都会映射到合理的比例区间不会出现跨屏拖拽时比例跳跃的问题。4.3 20ms节流把IPC风暴挡在主进程外面如果你直接每收到一个moveDrag就去调用layoutSplit拖拽过程会非常流畅吗完全不是。Electron的IPC消息在拖拽这种高频场景下每秒能产生一百多条主进程每条消息都去同步两个窗口边界会造成两个窗口频繁重排、CPU占用飙升甚至在某些M1机型上出现肉眼可见的掉帧。我的做法是20ms一次节流合并所有中间坐标只取最新值function scheduleDragFlush() { if (dragFlushTimer) return; dragFlushTimer setTimeout(flushDragMove, 20); } function flushDragMove() { dragFlushTimer null; if (!dragState || !pendingDragPoint) return; const deltaX pendingDragPoint.x - dragState.startScreenX; const ratio clamp( dragState.startRatio deltaX / dragState.startDisplayWidth, 0.3, 0.7 ); currentRatio ratio; layoutSplit(mainWin, panelWin, ratio); // 分隔条窗口也要同步移动到新位置 if (dividerWin !dividerWin.isDestroyed()) { const display getCurrentDisplay(); const { x, y, width, height } display.workArea; const dividerX Math.floor(x width * ratio - 3); dividerWin.setBounds({ x: dividerX, y, width: 6, height }, false); } }20ms意味着每秒最多更新50次对于窗口位置同步来说完全够用视觉上也已经非常顺滑。如果你想要更高帧率可以改成requestAnimationFrame的tick驱动但我在实际测试中发现20ms和16ms的区别几乎看不出来反而20ms的CPU占用更低尤其当两个窗口里都有复杂页面时节省出来的主进程时间片能让页面渲染更跟手。5. 实际踩坑记录焦点丢失、指针捕获、动画抖动与显示器热插拔5.1 拖拽会偷走“焦点”面板窗口要按需设置第一个坑是焦点问题。面板窗口frame: false且位于右侧用户拖完分隔条之后如果不做任何处理焦点会留在面板窗口上。这会导致主窗口里的编辑器失焦、快捷键失效甚至某些依赖blur事件的逻辑被错误触发。我的解决思路很简单分两类处理。如果面板窗口是一个纯预览、纯展示的窗口那直接禁止它获得焦点在创建时加上focusable: false。这样用户拖完分隔条焦点自动保持在主窗口。但如果面板窗口也需要交互比如它里面也有表单、有输入框那就不能禁止焦点只能在split-drag-end之后主动把焦点还给主窗口一次ipcMain.on(split-drag-end, () { // ... if (mainWin !mainWin.isDestroyed()) { mainWin.focus(); } });这里要提醒一句不要无脑在每次layoutSplit里都调用mainWin.focus()否则主窗口会一直抢焦点用户想在面板窗口里输入内容时根本点不进去。5.2 mouseup丢失Pointer Capture与拖拽超时兜底第二个坑非常隐蔽。用户在拖拽分隔条时如果鼠标快速地滑出分隔条窗口边界或者拖拽过程中按住了触控板再做手势抬起mouseup事件可能会没有触发。结果就是渲染进程里的dragging一直停留在true分隔条窗口明明已经不被鼠标按住了但后续所有mousemove都会继续触发移动逻辑窗口会跟着鼠标乱飘。解决这个问题我用了一个组合方案。第一在渲染进程的mousedown事件里调用document.body.setPointerCapture(e.pointerId)这样后续的mousemove和mouseup事件会被“锁定”到分隔条窗口上不会因为鼠标移出窗口而丢失。document.addEventListener(mousedown, (e) { dragging true; document.body.setPointerCapture(e.pointerId); window.electronAPI.startDrag({ x: e.clientX, y: e.clientY }); });第二在主进程加一个“拖拽超时”兜底如果在拖拽状态下超过200ms没有收到新的移动消息就自动结束拖拽。这防止了某些极端情况下Pointer Capture也失效比如系统弹出了通知面板导致事件被中断ipcMain.on(split-drag-move, (_event, point) { if (!dragState) return; pendingDragPoint point; if (dragIdleTimer) clearTimeout(dragIdleTimer); dragIdleTimer setTimeout(() { dragState null; pendingDragPoint null; dragIdleTimer null; }, 200); scheduleDragFlush(); });有了这个兜底即使没有正常收到endDrag整个拖拽链路也不会一直卡在“半拖拽”状态用户体验上最多就是“拖了一下没反应”但窗口不会乱跑也不影响下一次拖拽。5.3 显示器热插拔、比例恢复与布局持久化第三个坑是显示器变化。Mac用户经常插拔外接显示器、切换扩展屏如果代码里只算一次display对象显示器变化后窗口布局就全乱了。Electron的screen模块提供了display-added和display-removed事件我干脆注册了一个统一的重排函数screen.on(display-added, () relayoutAfterDisplayChange()); screen.on(display-removed, () relayoutAfterDisplayChange()); function relayoutAfterDisplayChange() { if (!mainWin || !panelWin) return; const display getCurrentDisplay(); layoutSplit(mainWin, panelWin, currentRatio); updateDividerPosition(); }另外建议把用户的拖拽比例currentRatio持久化。我用的是最简单的方案写到一个用户数据目录下的JSON文件里退出时保存、启动时读取。这样用户下次打开应用时上次拖好的左右比例自动恢复虽然只是一条很小的体验细节但能实实在在地提升好感度。我在文件里还会顺带记录当前显示器ID如果显示器变了就默认回到50/50而不是强行在陌生的分辨壁上应用旧比例。// 保存布局偏好 const fs require(fs); const path require(path); const layoutPrefFile path.join(app.getPath(userData), layout-pref.json); function saveLayoutPref() { const pref { ratio: currentRatio, displayId: getCurrentDisplay().id, savedAt: Date.now(), }; fs.writeFileSync(layoutPrefFile, JSON.stringify(pref, null, 2)); } function loadLayoutPref() { try { const raw fs.readFileSync(layoutPrefFile, utf-8); const pref JSON.parse(raw); if (pref pref.displayId getCurrentDisplay().id) { currentRatio pref.ratio; } } catch (_e) { // 文件不存在或解析失败直接使用默认 0.5 } }一些零碎但实用的调整拖拽过程中被setBounds频繁驱动的窗口页面里如果有大量动画或定时器Electron会因为这些窗口被认为“不在前台”而做后台节流导致页面帧率骤降。可以在创建窗口时加上一行win.webContents.setBackgroundThrottling(false);这样窗口即使不是焦点窗口页面动画也能保持正常。这个配置尤其在分屏模式下非常关键——右侧面板如果在持续播放视频或渲染图表不做这行设置拖拽过程中画面会明显变卡。另外分隔条窗口的alwaysOnTop: true设置我测试后发现一个副作用它会把系统自带的“显示桌面”手势挡住。解决办法是给分隔条窗口设置setAlwaysOnTop(true, floating)并配合setVisibleOnAllWorkspaces(true, { visibleOnFullScreen: true })这是macOS上非焦点小面板比较常用的组合。如果你不需要分隔条在所有空间都能看到也可以不加这两行但至少保证它在普通桌面空间里能正常显示和交互。还有一个经常被忽略的问题菜单栏。如果你用的是默认菜单用户按CmdM最小化主窗口或者按CmdH隐藏应用分隔条窗口可能残留。不用专门处理只要在窗口blur事件里做一次状态清理就好。比如主窗口被最小化时把分隔条也隐藏掉恢复时再显示。这个逻辑简单但能让整个分屏体验很“懂事”不会出现主窗口没了、一条分隔线还挂在屏幕中间的情况。最后说一个小细节双击分隔条可以恢复50/50均分。这个交互我是在做用户测试时发现的强烈痛点——大家拖来拖去之后经常想一键回到中间但不知道去哪里找设置。加了一行dblclick监听之后这个利用率比预期高很多。分屏这个功能本身不算复杂但涉及到的窗口管理、IPC协议、坐标计算这些细节如果不提前设计好架构很容易被各种边界情况拖进泥潭。核心的体会就是所有布局状态收敛到主进程管理渲染进程尽量做“哑终端”这套思路不仅适用于双窗口分屏将来扩展成三栏、四栏布局也只是改一个计算函数的事情。