适用结论 #
本次只比较两者共同支持的 Windows 平台。WindowGrid 的官方支持列表止于 Windows 10，Workspacer 面向 Windows 10+；本次以 Windows 10 为共同基准，Windows 11 上的行为仅作为兼容性风险讨论，不构成“跨平台差异”。
一句话结论：WindowGrid 把“用鼠标拖窗口”这件事做到了极低的学习成本，代价是停止维护带来的长期风险；Workspacer 把“用键盘管窗口”做成了一套可编程的工作流，代价是需要先投入配置和学习。 如果窗口整理对你来说是偶尔的、以鼠标为主的动作，WindowGrid 的网格吸附路径更短；如果你每天在编辑器、终端和浏览器之间高频切换，且愿意用 C# 脚本定义布局规则，Workspacer 的键盘平铺模型在长期使用中效率上限更高。
测试边界 #
以下信息来自官网、项目发布页和可核实的第三方技术资料，未进行 CPU、内存、启动耗时等实测。凡未实际运行的部分，标注“基于官方文档”或“官网未说明”。
| 软件 | 版本信息来源 | 本次平台 | 验证深度 |
|---|---|---|---|
| WindowGrid | 官网 windowgrid.net 当前发布的 1.3.1.1（便携 ZIP 433.8 KB） | Windows 10；Windows 11 兼容性仅作风险标注 | 功能与交互基于官网说明和公开技术文档；资源占用仅有旧版第三方参考值，非本次实测 |
| Workspacer | GitHub workspacer/workspacer Releases，已转为社区项目，当前主线为 0.9.x 系列，存在预发布版本 |
Windows 10（官方基线）；Windows 11 在社区提交中已有适配迹象 | 快捷键与配置模型基于官网 key bindings 页面和 GitHub 发布说明；资源占用仅有第三方文章参考值，非本次实测 |
需要单独说明的边界：WindowGrid 的官网支持列表未包含 Windows 11，但公开讨论中有“可在 Windows 11 运行”的第三方记录。本报告不把“能运行”等同于“官方支持”，Windows 11 上的 DPI 缩放与多显示器坐标问题在官网已知问题中已有记录，属于兼容性风险而非本次同平台比较的扣分项。Workspacer 的 Windows 11 适配在社区 PR 中有针对性修改（如忽略 Windows 11 开始菜单和搜索窗口），但整体仍以 Windows 10 为基线。
同平台能力矩阵 #
| 维度 | WindowGrid | Workspacer |
|---|---|---|
| 安装与兼容 | 有：便携 ZIP 与安装两种方式；依赖 .NET Framework 4.6；支持 Vista SP2 至 Windows 10，x86/x64 | 有：提供 WinGet、Chocolatey 和便携安装路径；依赖 .NET 运行时；官方基线 Windows 10+，社区已处理部分 Windows 11 窗口 |
| 核心功能 | 有：鼠标拖拽窗口时右键唤出动态网格，松开右键吸附；默认 12×6 网格可自定义；兼容 AeroSnap；可自定义输入（空格/右键/中键等） | 有：键盘驱动的平铺布局引擎；工作区隔离（Alt+1..9）；焦点移动与窗口交换（Alt+j/k、Alt+Shift+j/k）；多显示器焦点切换（Alt+w/e/r） |
| 交互效率 | 有（在“鼠标精确定位”场景下极短路径：拖→右键→选格→松手，无需记忆快捷键） | 有（在“键盘连续操作”场景下路径更短：全键盘完成布局切换、窗口移动、工作区隔离，手不离键盘） |
| 自动化/扩展 | 有限：输入绑定可自定义，但无脚本化布局 API；官网将“保存窗口位置”列为未来功能（截至 1.3.1.1 未实现） | 有：C# 脚本配置文件（workspacer.config.csx），可编程定义工作区、布局引擎、插件和栏部件；社区已有 gaps 插件、侧边栏等扩展 |
| 资源占用 | 未确认（本次未实测）；第三方旧版参考值约 72 MB（.NET/WPF 架构），官方未提供当前版本指标 | 未确认（本次未实测）；第三方文章提及约 10 MB 量级，官方描述为“不增加显著开销”，未提供可复核的基准数据 |
| 隐私与更新策略 | 有限：免费软件，官网提供自动更新；但核心版本自 2016 年后无实质功能更新，第三方资料一致指向“停止维护” | 有限：MIT 开源；已从个人项目转为社区组织维护，有活跃 PR 和预发布版本，但版本号仍处于 0.x 阶段，稳定性承诺有限 |
矩阵中的“有 / 有限 / 未确认”只反映在 Windows 10 同平台、面向窗口布局管理 场景下的证据强度。资源占用一栏的旧版第三方数值仅作架构参考，不作为二者之间的结论性对比依据。
三个真实工作流 #
工作流一：高频轻任务——“把当前窗口挪到左半屏，再把终端放到右下” #
这是每天发生几十次的动作。目标是不打断思路，在 1 到 2 秒内完成布局微调。
WindowGrid 在这个场景下的路径极短：按住标题栏拖动 → 右键唤出网格 → 光标扫过目标区域 → 松开右键、再松开左键。整个过程只用鼠标，不需要看键盘，也不需要记忆任何组合键。对于“偶尔整理一次窗口”或“鼠标已经在手上”的状态，这是认知负担最低的路径。
Workspacer 的等效操作是键盘序列：Alt+Space 切换布局引擎，或直接用 Alt+Shift+J/K 交换窗口位置，Alt+H/L 收缩/扩展主区域。单次操作需要记忆键位，但在连续调整多个窗口时，键盘的双手不离主键区的优势开始显现——不需要在鼠标和键盘之间来回切换。
结论反转条件：如果用户需要逐像素或任意比例摆放窗口（比如左侧 60%、右侧 40%），WindowGrid 的自定义网格可以做到，而 Workspacer 的平铺引擎输出的是算法布局，不能任意画矩形。此时 WindowGrid 的鼠标精度不可替代。
工作流二：复杂任务——“三个工作区：代码、调试、文档，互不干扰” #
当窗口数量超过 6 个、任务上下文开始混杂时，问题从“摆窗口”变成“隔离上下文”。
Workspacer 的工作区模型直接对应这个需求：Alt+1 到 Alt+9 切换工作区，Alt+Shift+1..9 把当前窗口送到指定工作区。再配合 C# 配置文件为不同工作区绑定不同的布局引擎和插件，可以把“代码工作区”固定为“编辑器主区域 + 终端次区域”，“文档工作区”固定为平铺或浮动模式。这是 WindowGrid 在架构上不具备的能力：WindowGrid 管理的是当前屏幕上的窗口位置，不管理工作区抽象。
WindowGrid 在这个场景下的角色退化为“在某个工作区内部做精确定位”。如果用户已经用 Windows 虚拟桌面隔离了任务，WindowGrid 仍然可以在每个桌面内完成网格吸附；但它本身不提供跨工作区的窗口调度。
结论反转条件：如果用户的工作流已经建立在Windows 原生虚拟桌面之上，并且不打算迁移到 Workspacer 的工作区模型，那么引入 Workspacer 的收益会被“两套工作区概念并存”的认知成本抵消。此时 WindowGrid + 原生虚拟桌面是更简单的组合。
工作流三：异常恢复——“窗口跑到屏幕外了，或者 DPI 缩放把布局打乱了” #
这是窗口管理工具最容易暴露边界的地方。
WindowGrid 的官网已知问题中直接列出了 “在 DPI 缩放不同的显示器之间移动非 DPI 感知窗口时出现问题” 。这意味着在混合 DPI 的多显示器环境中，WindowGrid 的网格坐标可能和实际窗口位置不一致，用户需要手动把窗口“救回来”，而工具本身没有提供自动修复入口。它的优势在于操作是即时可见的：网格叠加层让用户能直观看到吸附目标，出问题时也容易判断是坐标错位还是窗口不响应。
Workspacer 的异常恢复路径更依赖配置和快捷键：Alt+N 重置当前工作区布局，Alt+O 输出所有窗口的调试信息，Alt+Shift+O 输出光标下窗口的调试信息。对于“窗口跑到不可见区域”这类问题，Workspacer 没有一键召回窗口的默认绑定，用户需要借助布局重置或手动调整。它的可诊断性来自调试输出，但恢复操作的便捷性不如 WindowGrid 的“重新拖一次”。
结论反转条件：如果异常发生在停止维护的 WindowGrid 上，而问题恰好是官网已知但不会再修复的缺陷（如 DPI 错位），用户没有 upstream 修复可等；Workspacer 作为社区项目虽然也不承诺稳定性，但至少存在提交修复的路径。在这个意义上，“谁能被修”比“谁恢复更快”更关键。
工程化选型 #
| 团队约束 / 场景 | 首选 | 迁移成本 | 维护风险 | 替代路径 |
|---|---|---|---|---|
| 个人开发者，鼠标为主，不想花时间配置 | WindowGrid | 低：便携运行，解压即用；无需学习键位 | 高：停止维护，新 Windows 版本/新 DPI 环境的兼容问题不会修复 | Windows 原生 Snap Layouts（Win11）或 MaxTo 等仍在更新的商业工具 |
| 键盘流开发者，愿意用 C# 定义布局 | Workspacer | 中：需要理解工作区模型、编辑 .csx 配置、记忆默认键位或自行重绑 |
中：社区维护，版本处于 0.x，稳定性依赖社区活跃度；但配置和插件可版本化 | GlazeWM、komorebi 等其他 Windows 平铺管理器 |
| 多显示器混合 DPI 环境 | 谨慎选 WindowGrid；优先验证 Workspacer 在该环境下的布局计算 | 两者都需要实际测试；WindowGrid 的 DPI 问题在官网已有记录，Workspacer 的社区提交中涉及多显示器场景但未专门声明 DPI 修复 | WindowGrid 无修复路径；Workspacer 可提 issue 但无 SLA | 操作系统原生窗口管理或商业工具 |
| 需要将窗口布局“代码化”、纳入 dotfiles 管理 | Workspacer | 中：配置即代码，可纳入版本控制；但需要 C# 基础 | 低至中：配置文件自主可控，工具本身替换成本较高 | 无完全等效的轻量替代；平铺管理器生态中另有选择 |
| 企业/受管设备，不允许安装来源不明的常驻工具 | 两者均需谨慎 | WindowGrid 便携但停止维护，安全更新缺失；Workspacer 开源但需 .NET 运行时 | 受管环境通常有白名单限制，两者都可能不在默认许可范围内 | 操作系统内置窗口管理功能 |
选型的核心变量不是“谁的功能更多”，而是你对“停止维护”的容忍度与对“配置投入”的回报预期之间的权衡。WindowGrid 用极低的学习成本换取了鼠标端的即时满足，但把长期兼容性风险留给了用户；Workspacer 用前期的配置和学习成本换取了可编程、可版本化的工作区模型，但把稳定性押在社区维护的持续性上。两者都不是“装完就不用管”的工具，只是需要用户承担的代价类型不同。
下载信息 #
| 软件名称 | 适用平台 | 下载地址 |
|---|---|---|
| WindowGrid | Windows | 去下载 |
| Workspacer | Windows | 去下载 |
本次比较仅针对 Windows 10 同平台场景。WindowGrid 在 Windows 11 上的行为请以实际试用为准；Workspacer 的社区版本更新状态建议以 GitHub Releases 页面为最终依据，配置语法以项目文档和 workspacer.config.csx 实际结构为准。