自定义布局保存：把常用窗口摆好位置存成自己的 Layout，下次一键切换

一、问题的本质：布局保存到底在保存什么

很多人第一次接触“布局保存”这个概念，是在使用平铺式窗口管理器（Tiling Window Manager）的时候。i3wm 用户敲下 i3-save-tree，把当前工作区的窗口树导出成 JSON；AwesomeWM 用户则通过 awful.layout 切换预设布局。但如果你用的是 Windows 或 macOS 的普通桌面环境，这件事反而变得模糊——系统似乎“记得”一些窗口位置，又似乎总是记不准。

要理解布局保存，先要回答一个根本问题：一个“布局”在技术上由哪些状态构成？

从操作系统窗口管理的视角看，至少涉及以下几层状态：

• 几何状态：窗口的 x、y 坐标，宽度、高度，以及是否最大化、最小化、全屏。这是最直观的一层。
• 层级状态：窗口的 z-order（堆叠顺序），哪些窗口置顶，哪些被遮挡。
• 归属状态：窗口属于哪个显示器、哪个虚拟桌面（工作区）、哪个应用程序实例。
• 语义状态：窗口的“角色”——是主编辑窗口、参考文档窗口，还是终端窗口。这一层往往被忽略，却是恢复质量的关键。

本文评述：把布局保存等同于“记住坐标”，是绝大多数布局工具体验不佳的根源。坐标是结果，不是意图。用户真正想保存的是“我工作时窗口之间的相对关系”，而不是“某个像素点上的矩形”。这一区分，贯穿本文始终。

1.1 一个被低估的事实：窗口位置从来不是稳定的

在深入方案之前，有必要先破除一个幻觉：在主流桌面环境中，窗口位置本身就不是一个被严格保证的状态。以 Windows 为例，Win32 API 中的 SetWindowPos 只是“建议”窗口移动到某处，窗口过程（WndProc）完全可以在收到 WM_WINDOWPOSCHANGING 时修改这些值。macOS 的 AppKit 中，窗口位置受 NSWindow 的 frame autosave 机制影响，但应用可以选择不遵守。Linux 的 X11 下，窗口管理器（WM）和应用之间存在复杂的重定位协商，Wayland 则进一步把窗口位置的控制权收归合成器。

这意味着：布局保存与恢复，本质上是一场“请求-响应”博弈，而非“写入-读取”操作。你保存的是一个期望状态，恢复时系统能否达成这个期望，取决于窗口管理器、应用、显示器拓扑三方的配合程度。理解这一点，才能理解为什么很多布局工具“有时候灵、有时候不灵”。

1.2 布局保存的五阶段模型

综合上述分析，笔者提出一个贯穿全文的五阶段模型，作为后续讨论的骨架：

阶段	核心任务	主要难点
采集	枚举窗口、读取几何与语义状态	窗口句柄不稳定、应用识别困难
序列化	把状态编码为可存储格式	格式选择、版本兼容、可读性
存储	写入磁盘、管理多套布局	路径规范、并发、迁移
恢复	按快照重建窗口布局	时序、显示器拓扑变化、应用启动延迟
校验	验证恢复结果、处理失败	容错策略、用户反馈

这五个阶段并非线性，而是存在反馈循环——恢复失败后往往需要重新采集。后文将逐阶段展开。

二、窗口状态模型：从几何坐标到语义描述

2.1 几何状态的采集

采集窗口几何状态，各平台有对应的 API。Windows 上使用 EnumWindows 遍历顶层窗口，配合 GetWindowRect 获取矩形；macOS 上通过 Accessibility API（AXUIElement）读取 kAXPositionAttribute 和 kAXSizeAttribute；Linux 上则依赖 EWMH 规范中的 _NET_CLIENT_LIST 与 _NET_WM_STATE。

一个容易踩的坑是：GetWindowRect 返回的是包含阴影和边框的“外框”，而用户感知的是“内容区”。在 Windows 10/11 上，DWM 会给窗口加上不可见的扩展边框，直接使用 GetWindowRect 保存再恢复，窗口会逐次“膨胀”。正确做法是使用 DwmGetWindowAttribute 配合 DWMWA_EXTENDED_FRAME_BOUNDS 获取真实边界。这个问题在微软官方文档中有明确说明，但仍有大量布局工具中招。

本文评述：几何采集的精度问题，看似是细节，实则是布局工具“漂移”现象的主因。窗口每恢复一次就偏移几个像素，几十次之后布局面目全非。解决之道不是“更精确地采集”，而是引入归一化坐标——后文 2.3 节详述。

2.2 窗口指纹：如何稳定识别一个窗口

保存布局时，你保存的是“某个窗口在某个位置”。恢复时，你需要找到“同一个窗口”。但窗口句柄（HWND、AXUIElement、X11 Window ID）在应用重启后基本都会变化。这就需要一个稳定的窗口指纹（Window Fingerprint）。

笔者建议的指纹由以下字段组合而成，按优先级降序匹配：

1. 可执行文件路径 + 进程启动参数：最稳定，但同一应用多实例时无法区分。
2. 窗口标题：对编辑器、浏览器标签页有效，但标题常变（如“未命名 - 记事本”）。
3. 窗口类名 / 应用 Bundle ID：中等稳定，用于兜底。
4. 进程 ID + 窗口创建时间戳：仅在同一会话内稳定，跨会话失效。

实践中，单一字段都不够，需要设计一个匹配评分函数。例如，可执行路径完全匹配得 50 分，标题模糊匹配得 30 分，类名匹配得 20 分，总分超过阈值即认为是同一窗口。这种思路在学术上被称为“实体解析”（Entity Resolution），在数据库领域有成熟研究。本文将其迁移到窗口管理场景，属于跨领域方法借用。

2.3 归一化坐标：对抗显示器拓扑变化

如果你今天用 2560×1440 的主屏保存了布局，明天换到 1920×1080 的笔记本上恢复，绝对坐标会全部错位。解决方案是存储归一化坐标：把窗口位置表示为相对于所在显示器工作区的比例。

设显示器工作区为 (Wx, Wy, Ww, Wh)，窗口为 (x, y, w, h)，则归一化坐标为：

nx = (x - Wx) / Ww
ny = (y - Wy) / Wh
nw = w / Ww
nh = h / Wh

恢复时反向计算。这样即使分辨率变化，窗口的相对位置也能保持。但要注意：归一化会丢失像素级精度，对于需要精确对齐的场景（如双屏拼接显示同一张图）并不适用。因此，一个成熟的布局格式应该同时存储绝对坐标和归一化坐标，恢复时根据显示器是否变化来选择使用哪一套。

三、序列化格式设计：JSON、TOML 还是二进制

3.1 格式选型的权衡

布局数据的序列化格式，直接决定了工具的可扩展性、可调试性和跨平台能力。以下是主流选择的对比：

格式	优势	劣势	适用场景
JSON	通用、库支持好、可读	冗长、无注释	跨工具交换
TOML	可读性强、支持注释	嵌套表达略笨拙	用户手写配置
YAML	表达力强、注释友好	解析歧义多、安全坑	复杂嵌套配置
二进制	紧凑、读写快	不可读、调试难	高频自动保存

本文评述：对于布局保存这种“低频写入、高频读取、偶发手改”的场景，TOML 或 JSON 是更务实的选择。二进制格式虽然性能好，但布局数据量本身很小（几十个窗口不过几 KB），性能不是瓶颈，可调试性才是。

3.2 一个可扩展的布局 Schema 设计

无论选哪种格式，Schema 设计才是核心。以下是一个兼顾几何、语义与版本兼容的布局结构示例（以 TOML 表达）：

[meta]
name = "coding"
version = 2
created_at = "2025-03-14T10:22:00Z"
display_signature = "2560x1440@0,0|1920x1080@2560,0"

[[windows]]
fingerprint = "code.exe|main"
title_pattern = "*.code-workspace"
display = 0
normalized = { x = 0.0, y = 0.0, w = 0.5, h = 1.0 }
absolute = { x = 0, y = 0, w = 1280, h = 1440 }
state = "normal"
z_order = 1

[[windows]]
fingerprint = "chrome.exe|profile-default"
title_pattern = "*GitHub*"
display = 0
normalized = { x = 0.5, y = 0.0, w = 0.5, h = 0.5 }
absolute = { x = 1280, y = 0, w = 1280, h = 720 }
state = "normal"
z_order = 2

这个 Schema 的几个设计要点值得说明：

• version 字段：为未来格式演进留出空间。恢复时若版本不匹配，可走迁移逻辑或降级处理。
• display_signature：记录保存时的显示器拓扑签名，恢复时用于判断是否需要走归一化路径。
• fingerprint + title_pattern：双重匹配，提高窗口识别准确率。
• normalized + absolute 并存：给恢复策略留出选择余地。

3.3 版本兼容与迁移

布局格式一旦发布，就会有用户保存的旧文件。格式升级时必须考虑向后兼容。常见策略有三种：

1. 宽松解析：新版本能读旧格式，缺失字段用默认值填充。这是成本最低的方案。
2. 显式迁移：读取旧版本时调用迁移函数，转换为新结构后再处理。
3. 双写过渡：一段时间内同时写新旧两种格式，给用户升级留缓冲。

笔者认为，对于个人工具类项目，宽松解析 + 显式迁移的组合最为实用。双写过渡会增加维护负担，除非有大量外部消费者，否则不必采用。

四、平台方案横向对比：Windows / macOS / Linux

4.1 Windows：FancyZones 与 PowerToys

微软 PowerToys 套件中的 FancyZones 是目前 Windows 平台上最成熟的窗口布局工具。它允许用户定义区域（Zone）模板，然后把窗口拖入区域。FancyZones 的布局以 JSON 存储在 %LOCALAPPDATA%\Microsoft\PowerToys\FancyZones\ 下，包含自定义模板和已保存的布局。

FancyZones 的设计哲学是“区域优先”——它保存的是区域模板，而非窗口与区域的绑定关系。这意味着它不直接支持“一键恢复某组窗口到某组区域”。要实现这个效果，需要配合 PowerToys 的 Workspaces 功能（2023 年后引入）。Workspaces 会记录窗口的应用、位置和启动参数，本质上是一个布局快照系统。

本文评述：FancyZones 与 Workspaces 的分工，反映了微软对“布局”概念的两层理解——区域是静态的视觉划分，工作区是动态的窗口编排。这种分层设计值得借鉴，但也带来了学习成本。对于只想“一键切换”的用户，Workspaces 更直接。

官方文档：FancyZones 文档；Workspaces 文档。

4.2 macOS：Rectangle、Magnet 与原生 Stage Manager

macOS 上的窗口管理长期依赖第三方工具。Rectangle（开源）和 Magnet（商业）提供了快捷键驱动的窗口吸附。Rectangle 支持通过 URL Scheme 或 AppleScript 触发动作，但原生不提供“保存当前布局”功能。要实现布局保存，通常需要借助 Hammerspoon 这样的自动化工具，用 Lua 脚本读取窗口位置并写入文件。

macOS Ventura 引入的 Stage Manager 提供了另一种思路：它不保存精确位置，而是把窗口分组到“舞台”上。这更接近“语义布局”而非“几何布局”。本文评述：Stage Manager 的抽象层级更高，牺牲了精确控制，换来了对显示器变化和窗口增减的鲁棒性。这是一种值得关注的权衡方向。

Rectangle 项目地址：github.com/rxhanson/Rectangle；Hammerspoon 窗口管理教程：hs.window 文档。

4.3 Linux：i3wm、Sway 与 KDE KWin 脚本

Linux 是布局保存技术最活跃的平台，因为平铺式窗口管理器把布局作为一等公民。

i3wm 提供 i3-save-tree 命令，把当前工作区的窗口树导出为 JSON。这个 JSON 可以直接被 i3 的配置文件引用，实现“启动时恢复布局”。但 i3-save-tree 的输出包含大量注释和需要手工调整的字段，实际使用中往往需要脚本预处理。

Sway（i3 的 Wayland 移植版）继承了类似机制，并提供了 swaymsg -t get_tree 用于获取窗口树 JSON。Sway 的布局恢复更可靠，因为 Wayland 下合成器对窗口位置有完全控制权。

KDE Plasma 的 KWin 支持通过 KWin Scripts 操作窗口。社区项目如 kwin-window-geometry 提供了保存和恢复窗口几何的脚本。KWin 的优势在于它同时支持平铺和堆叠，覆盖面更广。

平台	代表工具	布局保存能力	恢复可靠性
Windows	FancyZones + Workspaces	强（含应用启动）	中高
macOS	Rectangle + Hammerspoon	中（需脚本）	中
Linux/X11	i3wm	强（窗口树）	高
Linux/Wayland	Sway	强（窗口树）	高

五、多显示器与工作区：拓扑感知的恢复策略

5.1 显示器拓扑签名

多显示器是布局恢复最大的变数。用户可能在公司用双屏，回家用单屏，出差用笔记本自带屏。如果布局文件只记录绝对坐标，换环境后必然错乱。

解决思路是引入“显示器拓扑签名”：把当前所有显示器的分辨率、相对位置、主屏标识编码成一个字符串。恢复时先比较签名，若一致则用绝对坐标；若不一致，则走归一化路径，并按显示器数量做降级映射。

降级映射的策略可以是：

• 显示器减少：把多余显示器上的窗口按顺序迁移到主屏，并按比例缩放。
• 显示器增加：把主屏上的窗口按语义分组，尽量分散到新显示器。
• 分辨率变化：使用归一化坐标重新计算绝对位置。

5.2 虚拟工作区的处理

Windows 的虚拟桌面、macOS 的 Spaces、Linux 的工作区，都会影响窗口归属。保存布局时，必须记录窗口所在的工作区索引或名称。恢复时，如果工作区数量不足，需要先创建工作区再放置窗口。

Windows 上操作虚拟桌面的 API 长期不公开，直到 Windows 10 引入 IVirtualDesktopManager 接口。但该接口功能有限，无法直接创建工作区。实践中，很多工具选择忽略虚拟桌面，只处理当前桌面上的窗口。本文评述：这是一个务实的妥协，但也意味着布局保存的完整性打了折扣。

5.3 时序问题：应用启动不是瞬时的

恢复布局时，如果窗口对应的应用尚未启动，你无法移动一个不存在的窗口。因此，恢复流程必须包含“等待窗口出现”的逻辑。常见做法是轮询：每隔 200ms 枚举一次窗口，检查指纹是否匹配，直到超时（如 30 秒）。

更优雅的方案是事件驱动。Windows 上可以监听 SetWinEventHook 的 EVENT_OBJECT_CREATE；macOS 上可以注册 AXObserver；Linux 上可以监听 EWMH 的 _NET_CLIENT_LIST 变化。事件驱动比轮询更及时，但实现复杂度更高，且需要处理事件丢失的情况。

笔者认为，对于个人工具，轮询 + 合理超时已经足够。事件驱动适合对恢复速度有严格要求的场景，比如演示环境的一键切换。

六、工程落地：手把手实现一个布局管理器

6.1 技术选型

为了让示例具有可操作性，我们以 Windows 平台为例，用 Python 实现一个最小可用的布局管理器。选择 Python 是因为它有成熟的 pywin32 库封装 Win32 API，且跨平台迁移到 macOS（pyobjc）和 Linux（python-xlib）时思路一致。

依赖安装：

pip install pywin32

6.2 采集模块

采集模块的核心是枚举顶层窗口并提取状态。以下代码展示了关键逻辑：

import win32gui
import win32process
import psutil

def enum_windows():
    results = []
    def callback(hwnd, _):
        if not win32gui.IsWindowVisible(hwnd):
            return
        title = win32gui.GetWindowText(hwnd)
        if not title:
            return
        rect = win32gui.GetWindowRect(hwnd)
        _, pid = win32process.GetWindowThreadProcessId(hwnd)
        try:
            proc = psutil.Process(pid)
            exe = proc.exe()
        except Exception:
            exe = "unknown"
        results.append({
            "hwnd": hwnd,
            "title": title,
            "exe": exe,
            "rect": rect,
        })
    win32gui.EnumWindows(callback, None)
    return results

注意这里用了 GetWindowRect，如前所述，生产环境应替换为 DwmGetWindowAttribute。这里为了代码简洁保留原 API。

6.3 序列化与存储

采集到的数据写入 TOML 文件。Python 3.11 起标准库自带 tomllib（仅读），写入可用 tomli-w：

import tomli_w
from pathlib import Path

def save_layout(name, windows):
    data = {
        "meta": {"name": name, "version": 1},
        "windows": windows,
    }
    path = Path.home() / ".layouts" / f"{name}.toml"
    path.parent.mkdir(exist_ok=True)
    with open(path, "wb") as f:
        tomli_w.dump(data, f)

6.4 恢复模块

恢复模块需要处理窗口匹配和位置设置。核心是 SetWindowPos：

import win32con

def restore_window(hwnd, x, y, w, h):
    win32gui.SetWindowPos(
        hwnd,
        win32con.HWND_TOP,
        x, y, w, h,
        win32con.SWP_SHOWWINDOW
    )

完整的恢复流程需要：读取布局文件 → 对每个窗口条目，轮询查找匹配的 HWND → 调用 SetWindowPos → 记录失败项。

6.5 命令行接口与快捷键绑定

用 argparse 提供两个子命令：

layout save coding
layout restore coding

然后用 AutoHotkey 或 Windows 快捷方式绑定快捷键，实现“一键切换”。AutoHotkey 示例：

#!1::Run "python layout.py restore coding"
#!2::Run "python layout.py restore writing"

这样 Win+Alt+1 切到编码布局，Win+Alt+2 切到写作布局。

七、前沿预判：AI 辅助布局与声明式桌面

7.1 从命令式到声明式

当前的布局保存本质上是命令式的：记录“窗口 A 在位置 P”。声明式思路则是描述“我想要一个编码环境”，由系统推导出窗口安排。这种思路在 NixOS 的窗口管理器配置、Kubernetes 的 Pod 调度中都有影子。

本文评述：声明式布局的难点在于“意图”难以形式化。用户说“我想要专注写作”，系统如何知道该开哪些窗口、怎么摆？这需要引入用户行为建模，而这又涉及隐私问题。短期内，声明式更适合有明确规则的专业场景（如交易员的多屏监控）。

7.2 机器学习在窗口管理中的应用

学术上，已有研究探索用强化学习优化窗口布局。例如，2023 年 UIST 会议上有论文提出基于用户操作序列预测下一个窗口位置。这类研究的共同挑战是数据稀缺——每个用户的使用模式差异大，难以训练通用模型。

更务实的 AI 应用是“布局推荐”：根据当前打开的窗口集合，推荐最接近的历史布局。这本质上是相似度匹配问题，可以用简单的编辑距离或 Jaccard 系数实现，不需要深度学习。

7.3 Wayland 与合成器主导的未来

Wayland 协议把窗口位置的控制权完全交给合成器，应用无法自行决定位置。这对布局保存既是挑战也是机遇：挑战在于传统基于 X11 的窗口操作 API 失效；机遇在于合成器可以统一管理布局，提供更可靠的保存恢复接口。

Sway、Hyprland 等 Wayland 合成器已经提供了比 X11 时代更强大的布局控制能力。笔者认为，未来布局保存的最佳实践将首先在 Wayland 生态中成熟，然后反向影响 Windows 和 macOS。

八、安全边界与常见坑位

8.1 权限问题

在 macOS 上，读取其他应用的窗口信息需要“辅助功能”权限。在 Windows 上，操作管理员权限运行的窗口需要提升自身权限。这些权限要求必须在文档中明确说明，否则用户会遇到“工具不工作”的困惑。

8.2 特殊窗口的处理

并非所有窗口都应该被保存和恢复。系统托盘、输入法候选框、临时弹窗等，如果被纳入布局，会造成混乱。建议维护一个排除列表，按窗口类名或进程名过滤。

8.3 失败恢复与用户反馈

恢复失败是常态而非例外。工具应该记录哪些窗口恢复成功、哪些失败，并给用户可操作的反馈。例如：“3 个窗口已恢复，Chrome 未找到（可能未启动）”。沉默失败是最糟糕的设计。

九、总结与操作清单

回到本文的核心主线：布局保存的本质是状态快照，而状态快照的质量取决于你采集了哪些状态、如何序列化、如何恢复。几何坐标只是冰山一角，窗口指纹、显示器拓扑、工作区归属、应用启动时序，共同决定了恢复的成败。

如果你打算自己实现一个布局管理器，以下是可操作清单：

1. 先定义 Schema：包含 meta、windows 两部分，meta 记录版本和显示器签名。
2. 设计窗口指纹：至少用 exe 路径 + 标题模式双字段匹配。
3. 同时存绝对和归一化坐标：恢复时按显示器签名选择。
4. 实现轮询等待：应用启动有延迟，不能假设窗口立即可用。
5. 维护排除列表：过滤系统窗口和临时弹窗。
6. 记录恢复日志：成功和失败都要可见。
7. 绑定快捷键：一键切换是核心体验，不要让用户敲命令行。

布局保存不是一个“做完就完”的功能，而是一个需要持续打磨的体验。显示器会变、应用会更新、用户习惯会演化。好的布局工具应该像一位安静的助手，在你需要时把桌面恢复成你熟悉的样子。