《一套全局滚动跑遍 Windows、macOS 与 Linux：三套钩子的取舍》

我维护的 FlowScroll 是一个 Python 全局无级滚动工具，目标是把浏览器里按住中键自动滚动的手感带到整个系统。难点不在滚动算法，而在三个操作系统给全局输入留的口子各不相同，同一个功能要走三条完全不同的路。

第一组：Windows——钩子最顺手，但要管住它的副作用

Windows 是三个系统里做全局输入最顺手的一个。系统提供了低层鼠标钩子，装好之后，不管焦点在哪个窗口，中键按下、松开、滚轮转动都会先经过我这里，我再决定放行、吃掉，还是翻译成自动滚动。

顺手归顺手，坑也不少。第一个坑是钩子回调里不能干重活：它跑在系统注入的线程里，多算一点，整个系统的鼠标都会跟着卡。回调里我只把事件扔进队列就返回，判断、加速曲线、滚动输出全放在自己的工作线程里做。第二个坑是中键的语义冲突：有些软件自己就用中键，比如浏览器中键点链接是后台打开标签。我的取舍是默认只在“按下中键进入自动滚动”这一种手势上接管，其他语义尽量放行；实在冲突的软件单独留一个排除名单，而不是为了一款软件改全局规则。

还有一个容易被忽略的点：钩子按会话装，锁屏、切换用户、远程桌面之后可能失效。我的做法是每次收到会话变化通知就检查一次，不在就悄悄重装，不弹提示。

第二组：macOS——权限是第一道关，能力是第二道关

macOS 的路子和 Windows 正好反过来：能力本身不难，难的是先拿到进门的资格。系统要求监听全局按键和鼠标事件的应用必须拿到辅助功能权限，这个权限只能由用户本人在系统设置里手动打开，程序自己点不开，也绕不过去。第一次启动时如果我不把这件事讲清楚，用户只会看到一个“没有反应”的软件，然后直接删掉。

我的做法是把权限申请做成启动流程里的一步：先用一句大白话说明这个权限是用来监听中键的，再给一个按钮打开系统设置里对应的那一页，剩下的步骤用图加文字写清楚。拿到权限之后，技术路线和 Windows 类似：用系统事件监听接口截获中键事件，再自己输出滚动。区别在于，macOS 对这类监听有看门机制，空闲太久或系统资源紧张时，监听可能被悄悄停掉。我的处理是加一个心跳自检：定时发一个无害探针确认监听还活着，死了就按流程重建，重建时不重复弹窗打扰用户。

手感上也有取舍：macOS 用户对滚动方向、加速度的默认期待和 Windows 用户不一样。我的做法是不跟系统默认值较劲，默认跟随系统设置，用户明确想改时，才在工具设置里给一个独立开关。

第三组：Linux——X11 和 Wayland 是两条路，不要假装是一条

Linux 是三个系统里最分裂的一个，分裂点不在发行版，而在显示协议。X11 下面有成熟的全局输入监听路子，装好就能用，和 Windows 的体验最接近；Wayland 下面，出于安全考虑，系统从设计上就不允许普通应用监听全局输入，拿不到别的窗口的鼠标事件。这是协议层面的限制，不是换个库就能绕过去的。

我在这个地方吃过的最大亏，就是一开始想写一套代码同时覆盖两者，结果代码里到处是分支判断，X11 的路子在 Wayland 上跑不通，反过来也一样。最后定下来的取舍是：先检测当前会话跑的是哪个协议，再走对应实现；Wayland 下如果系统实在不给全局输入的口子，就退一步，只做本应用窗口内和已授权范围内的滚动，并在界面上明明白白告诉用户哪些功能受限，而不是假装一切正常、让用户去猜为什么中键没反应。

原则是：把“能不能监听”交给环境检测，而不是交给用户去试。用户不需要知道 X11 和 Wayland 的区别，启动时只需看到一句诚实的话：当前环境支持什么、不支持什么。

三个系统之上，共用的只有一层薄薄的逻辑

三个系统走三条路，但三条路之上我只留了一层共用逻辑：事件归一化、加速曲线、自动滚动状态机。各系统只负责把原始事件翻译成同一份格式——“中键按下”“中键松开”“滚轮转动一格”——剩下的判断全由共用层做：多快进入自动滚动、速度按什么曲线长、松开后滑多远停、误触怎么过滤。

这一层一定要薄。权限、钩子、协议差异这些脏活全留在各系统实现里，共用层只认归一化后的事件。

结论：跨平台工具，先认清每个系统给的口子

回头看，全局滚动本身不复杂，复杂的是每个系统对“全局”两个字的态度不同：Windows 把口子公开留出来，代价是开发者自己管副作用；macOS 把权限放在用户手里，代价是第一次启动必须把话讲清楚；Linux 在两个协议之间分裂，代价是必须先检测环境再决定走哪条路。

认清口子，再决定取舍，工具才做得下去。如果你也在做系统级小工具，或者想把中键滚动带到整个系统，欢迎看看 FlowScroll：免费开源的 Python 全局无级滚动工具，Windows 上的体验最完整。