【Bug已解决】The minimise button on the Codex desktop app doesnt work when you Zoom In 解决方案原始报错线索The minimise button on the Codex desktop app doesnt work when you Zoom In桌面应用在「放大显示」后出现最小化按钮点不动。一、现象长什么样用户在「系统设置 → 显示 → 缩放」里把界面放大到 125%、150% 或 175% 之后桌面上某个 Electron / Qt / Tk 类应用出现如下症状标题栏右上角的「最小化」按钮鼠标点上去毫无反应既不最小化窗口也不触发任何日志但把系统缩放调回 100%或应用以兼容模式、禁用缩放运行后同一个按钮立刻恢复正常更诡异的是有时把鼠标往按钮「右下方偏移十几个像素」反而能点中——就像按钮的「热区」整体发生了平移同样的代码在 100% 缩放的笔记本上从未出过问题唯独在高分屏台式机、或外接 4K 显示器被放大时必现。 这一类问题在跨平台桌面应用里非常典型本质不是「按钮没绑定事件」而是「鼠标点击的物理像素坐标」与「控件布局所用的逻辑坐标」落在了两个不同的坐标系里命中测试算错了位置。二、背景什么是显示缩放 / HiDPI / DPI 感知要理解这个 Bug先得厘清几个经常被混用的概念。2.1 DPI 与缩放比例DPIDots Per Inch每英寸的像素点数。一台 27 寸 4K 显示器物理 DPI 约 163而传统 1080p 显示器约 96。系统缩放比例scale factor为了让高分屏上字不至于小到看不清Windows / macOS 会把逻辑坐标乘以一个系数。例如 150% 缩放 scale 1.5。逻辑像素logical / CSS pixel vs 物理像素physical / device pixel应用内部布局用的是逻辑像素最终画到屏幕、鼠标事件回报的是物理像素。两者关系物理像素 逻辑像素 × scale。2.2 DPI 感知DPI Awareness操作系统在进程启动时需要知道「这个程序自己会不会处理缩放」Unaware不感知系统对整个窗口做位图拉伸模糊但进程内部所有坐标都按 96 DPI 算。老程序最省事但会糊。System DPI Aware进程按「系统级」DPI 计算但多显示器不同缩放时仍可能有问题。Per-Monitor DPI Awarev1 / v2进程能感知每个显示器各自的 DPI窗口在显示器间拖拽时会收到DpiChanged消息并自己重排。关键陷阱如果进程声明为 Unaware但 GUI 框架比如某些版本的 Electron 或 Tk 绑定又偷偷按真实 DPI 去摆放控件那么「系统回报的鼠标坐标」和「框架实际画控件的坐标」就会差一个 scale 倍率——这正是最小化按钮点不动的根源。三、为什么放大后按钮点不动坐标空间与命中测试错位命中测试hit-testing是 GUI 系统判断「鼠标当前落在哪个控件上」的过程。它通常这样工作操作系统把鼠标物理坐标如x300, y16物理像素交给应用应用把它换算成逻辑坐标x_logical 300 / 1.5 200再用逻辑坐标去比对每个控件的矩形button_rect (180, 0, 210, 30)命中 → 触发点击。 当DPI 感知设置与 GUI 框架的实际行为不一致时第 2 步常常被跳过或算错框架以为自己在 96 DPI 逻辑空间里按 100% 摆放了按钮逻辑宽度 30但系统因为进程是 Unaware又对整窗口做了 1.5 倍拉伸导致按钮在屏幕上实际占了 45 物理像素、且位置被整体平移系统回报的鼠标物理坐标没被框架除以 1.5于是框架拿「物理坐标」去比对「逻辑矩形」热区整体错位 → 点不中。 换句话说这不是按钮坏了是坐标系没对齐。这也解释了为什么「往右下偏移一点反而能点中」——你正好把物理坐标补偿进了那个错位量里。四、最小可运行复现Tkinter不设置 DPI 感知下面用标准库tkinter复现「按钮热区随缩放错位」的现象。在 Windows 上如果不显式声明 DPI 感知Tk 在某些版本会按系统 DPI 摆放控件却收到未缩放的鼠标坐标。代码在任意装了 Tk 的 Python 都能跑import sys import tkinter as tk def build_ui(): root tk.Tk() root.title(DPItest-no-awareness) root.geometry(420x220) log tk.Text(root, height8) log.pack(fillboth, expandTrue, padx8, pady8) # 右上角放一个“最小化”按钮这里用普通 button 模拟标题栏按钮 def on_minimize(): log.insert(end, 点击命中执行最小化\n) root.iconify() btn tk.Button(root, text最小化, commandon_minimize, width10, height1) btn.place(x300, y10) # 固定逻辑像素位置 root.mainloop() if __name__ __main__: build_ui()运行方式python dpitest_no_awareness.py把系统缩放调成 150%然后去点这个「最小化」按钮。你会观察到在部分 Tk/Windows 组合下鼠标必须明显偏离按钮视觉中心才能触发on_minimize而把窗口拖到 100% 缩放的显示器上就完全正常。这就是坐标系错位的直观证据。说明Tk 不同版本表现不一有的已经默认开启了 DPI 感知。本例的价值在于演示「固定像素 不感知」这一危险组合而不是精确复现某一个特定版本。五、解决方案一开启进程级 DPI 感知Windows最根本的修复是让进程老老实实声明自己能处理高 DPI这样系统就不会再偷偷拉伸窗口鼠标坐标和控件坐标会统一到逻辑空间。Windows 上用ctypes调用SetProcessDpiAwareness即可无需任何第三方库import sys import ctypes def enable_dpi_awareness(): 在 Windows 上开启 Per-Monitor DPI 感知。必须在创建任何窗口前调用。 if sys.platform ! win32: return try: # 2 PROCESS_PER_MONITOR_DPI_AWARE (PROCESS_DPI_AWARENESS 枚举) ctypes.windll.shcore.SetProcessDpiAwareness(2) except AttributeError: # 老系统回退到 SetProcessDPIAware() try: ctypes.windll.user32.SetProcessDPIAware() except AttributeError: pass if __name__ __main__: enable_dpi_awareness() # 关键必须在 Tk() 之前 import tkinter as tk root tk.Tk() root.title(DPItest-aware) root.geometry(420x220) tk.Label(root, text已开启 DPI 感知按钮热区与鼠标坐标一致).pack(padx10, pady20) root.mainloop()要点必须在创建任何窗口 / GUI 对象之前调用否则不生效返回值非零表示失败可结合GetLastError排查声明感知后框架内部会自动用physical / scale换算鼠标坐标命中测试自然对齐。六、解决方案二用「设备无关坐标」做命中测试如果你维护的是一个自己画控件自绘 UI / 游戏引擎 / 嵌入式 WebView的框架不能依赖系统 DPI 感知那就得在应用层统一坐标空间。核心原则只有一条所有布局与命中测试都用逻辑坐标物理坐标只在最后一步做乘除法运算。 下面是一个不依赖任何 GUI 框架、纯 Python 的命中测试演示它显式用scale把物理鼠标坐标换算回逻辑坐标再判定按钮是否被点中from dataclasses import dataclass dataclass class Rect: x: int y: int w: int h: int def contains_logical(self, lx: int, ly: int) - bool: return self.x lx self.x self.w and self.y ly self.y self.h def hit_test(button_rect: Rect, physical_x: int, physical_y: int, scale: float) - bool: # 关键先把物理坐标换回逻辑坐标再比对逻辑矩形 lx physical_x / scale ly physical_y / scale return button_rect.contains_logical(int(lx), int(ly)) if __name__ __main__: scale 1.5 # 系统 150% 缩放 # 标题栏“最小化”按钮的逻辑矩形逻辑像素 minimize_btn Rect(x390, y0, w30, h30) # 情况 A鼠标在物理 600,20 处点击 print(物理(600,20) 命中?, hit_test(minimize_btn, 600, 20, scale)) # 600/1.5400 落在 [390,420) 内 - True # 情况 B框架“忘了除以 scale”直接用物理坐标比对 - 错位 wrong minimize_btn.contains_logical(600, 20) print(错误比对(未除 scale) 命中?, wrong) # False正是 Bug 来源运行输出会清楚显示「正确换算后命中」「忘记换算则落空」。这把第三节的理论落成了一段可验证的代码。七、解决方案三让按钮随布局自适应避免「固定像素」很多标题栏按钮用place(x300, y10)这种绝对像素定位在缩放后极易错位。更稳妥的做法是用布局管理器 锚定anchor让按钮永远贴着右上角而不是写死坐标import tkinter as tk def build_resilient_ui(): root tk.Tk() root.title(DPItest-layout) root.geometry(420x220) # 用 pack sideRIGHT anchor 让按钮永远贴右上不写死像素 top_bar tk.Frame(root) top_bar.pack(sidetop, fillx) def on_minimize(): root.iconify() tk.Button(top_bar, text最小化, commandon_minimize, width8).pack(sideright, padx4, pady4) tk.Button(top_bar, text关闭, commandroot.destroy, width8).pack(sideright, padx4, pady4) tk.Label(root, text用布局锚定代替固定像素缩放后依然贴边).pack(padx10, pady30) root.mainloop() if __name__ __main__: # 配合第五节开启 DPI 感知效果最佳 try: import ctypes ctypes.windll.shcore.SetProcessDpiAwareness(2) except Exception: pass build_resilient_ui()布局管理器会跟随实际 DPI 重新计算控件矩形命中测试自然跟着对从根本上消除了「写死坐标 缩放」的错位风险。八、跨平台注意点macOS / LinuxDPI 缩放在三个平台上的机制不同但「统一坐标空间」的原则一致8.1 Windows用SetProcessDpiAwareness(2)Per-Monitor v2最稳窗口在显示器间拖动时监听WM_DPICHANGED重算布局别忘了声明感知后你自己读到的GetSystemMetrics已是逻辑值。8.2 macOSmacOS 原生坐标系天生是「点point」即逻辑像素NSScreen.backingScaleFactor才是物理倍率多数基于 Cocoa 的框架含新版本 Electron默认正确处理问题多出现在自己用CGDisplayBounds拿物理分辨率却没乘/除 scale 的自定义代码排查时打印backingScaleFactor确认命中测试用的是 point 而非 pixel。8.3 Linux含 Mint / Ubuntu主流桌面用 Wayland 或 X11 的Gdk/Qt缩放框架层gtk、Qt一般已封装好风险点在「自绘 自己读 X11 事件」X 事件坐标是物理像素而布局是逻辑像素需要按Gdk.Display.get_scale_factor()换算第 114 篇app-server SIGABRT会涉及 Linux 桌面进程崩溃与本篇的「先开 DPI 感知再建窗口」顺序原则相通——环境初始化必须早于 UI 对象创建。8.4 Electron 类应用附manifest 层面若你的应用是 Electron 封装除了进程内setProcessDpiAwareness还要在manifest/BrowserWindow构造时设置enableBlinkFeatures相关的高 DPI 选项并避免对webview做 CSSzoom缩放——CSSzoom会制造第二套坐标变换是标题栏按钮错位的高发区。九、排查清单遇到「放大后某按钮点不动」按下面顺序自查基本能在十分钟内定位进程是否声明了 DPI 感知Windows用GetDpiForSystem()或调试器看PROCESS_DPI_AWARENESS未声明或 Unaware 是头号嫌疑。鼠标坐标和控件矩形是否在同一坐标系在点击处理里同时打印「原始事件坐标」和「控件矩形」二者数值量级差一个 scale 倍率即可确认错位。按钮是不是用绝对像素place(x, y)钉死的改成布局锚定pack/grid anchor或 flex/absolute 相对右上角。是否混用了 CSSzoom或自绘缩放多层缩放叠加会让命中测试雪上加霜优先用系统级缩放而非 CSS zoom。多显示器不同缩放时是否重排监听 DPI 变化事件窗口跨屏后强制重算布局与热区。框架版本是否已知坑某些 Tk / Electron 旧版默认不开启感知升级或显式开启即可。最小化逻辑本身有没有被短路排除法先把按钮command换成打印日志确认「点不中」还是「点中但不执行」——前者是坐标问题后者是业务逻辑问题。十、小结「放大显示后最小化按钮点不动」看似是个偶发 UI Bug根子上是DPI 感知声明与 GUI 框架实际坐标行为不一致导致鼠标物理坐标和控件逻辑矩形落在了两个坐标系。通用修复三板斧声明 DPI 感知WindowsSetProcessDpiAwareness(2)且在建窗口前调用统一坐标空间命中测试一律先物理 / scale换算回逻辑坐标再比对布局锚定代替固定像素让控件随缩放自适应贴边。 跨平台时记住Windows 看PROCESS_DPI_AWARENESS、macOS 看backingScaleFactor、Linux 看get_scale_factor()三者数值含义一致——都是「物理像素 逻辑像素 × scale」。只要全程只用逻辑坐标做布局与命中测试缩放再高也不会让按钮跑偏。
【Bug已解决】The minimise button on the Codex desktop app doesnt work when you Zoom In 解决方案原始报错线索The minimise button on the Codex desktop app doesnt work when you Zoom In桌面应用在「放大显示」后出现最小化按钮点不动。一、现象长什么样用户在「系统设置 → 显示 → 缩放」里把界面放大到 125%、150% 或 175% 之后桌面上某个 Electron / Qt / Tk 类应用出现如下症状标题栏右上角的「最小化」按钮鼠标点上去毫无反应既不最小化窗口也不触发任何日志但把系统缩放调回 100%或应用以兼容模式、禁用缩放运行后同一个按钮立刻恢复正常更诡异的是有时把鼠标往按钮「右下方偏移十几个像素」反而能点中——就像按钮的「热区」整体发生了平移同样的代码在 100% 缩放的笔记本上从未出过问题唯独在高分屏台式机、或外接 4K 显示器被放大时必现。 这一类问题在跨平台桌面应用里非常典型本质不是「按钮没绑定事件」而是「鼠标点击的物理像素坐标」与「控件布局所用的逻辑坐标」落在了两个不同的坐标系里命中测试算错了位置。二、背景什么是显示缩放 / HiDPI / DPI 感知要理解这个 Bug先得厘清几个经常被混用的概念。2.1 DPI 与缩放比例DPIDots Per Inch每英寸的像素点数。一台 27 寸 4K 显示器物理 DPI 约 163而传统 1080p 显示器约 96。系统缩放比例scale factor为了让高分屏上字不至于小到看不清Windows / macOS 会把逻辑坐标乘以一个系数。例如 150% 缩放 scale 1.5。逻辑像素logical / CSS pixel vs 物理像素physical / device pixel应用内部布局用的是逻辑像素最终画到屏幕、鼠标事件回报的是物理像素。两者关系物理像素 逻辑像素 × scale。2.2 DPI 感知DPI Awareness操作系统在进程启动时需要知道「这个程序自己会不会处理缩放」Unaware不感知系统对整个窗口做位图拉伸模糊但进程内部所有坐标都按 96 DPI 算。老程序最省事但会糊。System DPI Aware进程按「系统级」DPI 计算但多显示器不同缩放时仍可能有问题。Per-Monitor DPI Awarev1 / v2进程能感知每个显示器各自的 DPI窗口在显示器间拖拽时会收到DpiChanged消息并自己重排。关键陷阱如果进程声明为 Unaware但 GUI 框架比如某些版本的 Electron 或 Tk 绑定又偷偷按真实 DPI 去摆放控件那么「系统回报的鼠标坐标」和「框架实际画控件的坐标」就会差一个 scale 倍率——这正是最小化按钮点不动的根源。三、为什么放大后按钮点不动坐标空间与命中测试错位命中测试hit-testing是 GUI 系统判断「鼠标当前落在哪个控件上」的过程。它通常这样工作操作系统把鼠标物理坐标如x300, y16物理像素交给应用应用把它换算成逻辑坐标x_logical 300 / 1.5 200再用逻辑坐标去比对每个控件的矩形button_rect (180, 0, 210, 30)命中 → 触发点击。 当DPI 感知设置与 GUI 框架的实际行为不一致时第 2 步常常被跳过或算错框架以为自己在 96 DPI 逻辑空间里按 100% 摆放了按钮逻辑宽度 30但系统因为进程是 Unaware又对整窗口做了 1.5 倍拉伸导致按钮在屏幕上实际占了 45 物理像素、且位置被整体平移系统回报的鼠标物理坐标没被框架除以 1.5于是框架拿「物理坐标」去比对「逻辑矩形」热区整体错位 → 点不中。 换句话说这不是按钮坏了是坐标系没对齐。这也解释了为什么「往右下偏移一点反而能点中」——你正好把物理坐标补偿进了那个错位量里。四、最小可运行复现Tkinter不设置 DPI 感知下面用标准库tkinter复现「按钮热区随缩放错位」的现象。在 Windows 上如果不显式声明 DPI 感知Tk 在某些版本会按系统 DPI 摆放控件却收到未缩放的鼠标坐标。代码在任意装了 Tk 的 Python 都能跑import sys import tkinter as tk def build_ui(): root tk.Tk() root.title(DPItest-no-awareness) root.geometry(420x220) log tk.Text(root, height8) log.pack(fillboth, expandTrue, padx8, pady8) # 右上角放一个“最小化”按钮这里用普通 button 模拟标题栏按钮 def on_minimize(): log.insert(end, 点击命中执行最小化\n) root.iconify() btn tk.Button(root, text最小化, commandon_minimize, width10, height1) btn.place(x300, y10) # 固定逻辑像素位置 root.mainloop() if __name__ __main__: build_ui()运行方式python dpitest_no_awareness.py把系统缩放调成 150%然后去点这个「最小化」按钮。你会观察到在部分 Tk/Windows 组合下鼠标必须明显偏离按钮视觉中心才能触发on_minimize而把窗口拖到 100% 缩放的显示器上就完全正常。这就是坐标系错位的直观证据。说明Tk 不同版本表现不一有的已经默认开启了 DPI 感知。本例的价值在于演示「固定像素 不感知」这一危险组合而不是精确复现某一个特定版本。五、解决方案一开启进程级 DPI 感知Windows最根本的修复是让进程老老实实声明自己能处理高 DPI这样系统就不会再偷偷拉伸窗口鼠标坐标和控件坐标会统一到逻辑空间。Windows 上用ctypes调用SetProcessDpiAwareness即可无需任何第三方库import sys import ctypes def enable_dpi_awareness(): 在 Windows 上开启 Per-Monitor DPI 感知。必须在创建任何窗口前调用。 if sys.platform ! win32: return try: # 2 PROCESS_PER_MONITOR_DPI_AWARE (PROCESS_DPI_AWARENESS 枚举) ctypes.windll.shcore.SetProcessDpiAwareness(2) except AttributeError: # 老系统回退到 SetProcessDPIAware() try: ctypes.windll.user32.SetProcessDPIAware() except AttributeError: pass if __name__ __main__: enable_dpi_awareness() # 关键必须在 Tk() 之前 import tkinter as tk root tk.Tk() root.title(DPItest-aware) root.geometry(420x220) tk.Label(root, text已开启 DPI 感知按钮热区与鼠标坐标一致).pack(padx10, pady20) root.mainloop()要点必须在创建任何窗口 / GUI 对象之前调用否则不生效返回值非零表示失败可结合GetLastError排查声明感知后框架内部会自动用physical / scale换算鼠标坐标命中测试自然对齐。六、解决方案二用「设备无关坐标」做命中测试如果你维护的是一个自己画控件自绘 UI / 游戏引擎 / 嵌入式 WebView的框架不能依赖系统 DPI 感知那就得在应用层统一坐标空间。核心原则只有一条所有布局与命中测试都用逻辑坐标物理坐标只在最后一步做乘除法运算。 下面是一个不依赖任何 GUI 框架、纯 Python 的命中测试演示它显式用scale把物理鼠标坐标换算回逻辑坐标再判定按钮是否被点中from dataclasses import dataclass dataclass class Rect: x: int y: int w: int h: int def contains_logical(self, lx: int, ly: int) - bool: return self.x lx self.x self.w and self.y ly self.y self.h def hit_test(button_rect: Rect, physical_x: int, physical_y: int, scale: float) - bool: # 关键先把物理坐标换回逻辑坐标再比对逻辑矩形 lx physical_x / scale ly physical_y / scale return button_rect.contains_logical(int(lx), int(ly)) if __name__ __main__: scale 1.5 # 系统 150% 缩放 # 标题栏“最小化”按钮的逻辑矩形逻辑像素 minimize_btn Rect(x390, y0, w30, h30) # 情况 A鼠标在物理 600,20 处点击 print(物理(600,20) 命中?, hit_test(minimize_btn, 600, 20, scale)) # 600/1.5400 落在 [390,420) 内 - True # 情况 B框架“忘了除以 scale”直接用物理坐标比对 - 错位 wrong minimize_btn.contains_logical(600, 20) print(错误比对(未除 scale) 命中?, wrong) # False正是 Bug 来源运行输出会清楚显示「正确换算后命中」「忘记换算则落空」。这把第三节的理论落成了一段可验证的代码。七、解决方案三让按钮随布局自适应避免「固定像素」很多标题栏按钮用place(x300, y10)这种绝对像素定位在缩放后极易错位。更稳妥的做法是用布局管理器 锚定anchor让按钮永远贴着右上角而不是写死坐标import tkinter as tk def build_resilient_ui(): root tk.Tk() root.title(DPItest-layout) root.geometry(420x220) # 用 pack sideRIGHT anchor 让按钮永远贴右上不写死像素 top_bar tk.Frame(root) top_bar.pack(sidetop, fillx) def on_minimize(): root.iconify() tk.Button(top_bar, text最小化, commandon_minimize, width8).pack(sideright, padx4, pady4) tk.Button(top_bar, text关闭, commandroot.destroy, width8).pack(sideright, padx4, pady4) tk.Label(root, text用布局锚定代替固定像素缩放后依然贴边).pack(padx10, pady30) root.mainloop() if __name__ __main__: # 配合第五节开启 DPI 感知效果最佳 try: import ctypes ctypes.windll.shcore.SetProcessDpiAwareness(2) except Exception: pass build_resilient_ui()布局管理器会跟随实际 DPI 重新计算控件矩形命中测试自然跟着对从根本上消除了「写死坐标 缩放」的错位风险。八、跨平台注意点macOS / LinuxDPI 缩放在三个平台上的机制不同但「统一坐标空间」的原则一致8.1 Windows用SetProcessDpiAwareness(2)Per-Monitor v2最稳窗口在显示器间拖动时监听WM_DPICHANGED重算布局别忘了声明感知后你自己读到的GetSystemMetrics已是逻辑值。8.2 macOSmacOS 原生坐标系天生是「点point」即逻辑像素NSScreen.backingScaleFactor才是物理倍率多数基于 Cocoa 的框架含新版本 Electron默认正确处理问题多出现在自己用CGDisplayBounds拿物理分辨率却没乘/除 scale 的自定义代码排查时打印backingScaleFactor确认命中测试用的是 point 而非 pixel。8.3 Linux含 Mint / Ubuntu主流桌面用 Wayland 或 X11 的Gdk/Qt缩放框架层gtk、Qt一般已封装好风险点在「自绘 自己读 X11 事件」X 事件坐标是物理像素而布局是逻辑像素需要按Gdk.Display.get_scale_factor()换算第 114 篇app-server SIGABRT会涉及 Linux 桌面进程崩溃与本篇的「先开 DPI 感知再建窗口」顺序原则相通——环境初始化必须早于 UI 对象创建。8.4 Electron 类应用附manifest 层面若你的应用是 Electron 封装除了进程内setProcessDpiAwareness还要在manifest/BrowserWindow构造时设置enableBlinkFeatures相关的高 DPI 选项并避免对webview做 CSSzoom缩放——CSSzoom会制造第二套坐标变换是标题栏按钮错位的高发区。九、排查清单遇到「放大后某按钮点不动」按下面顺序自查基本能在十分钟内定位进程是否声明了 DPI 感知Windows用GetDpiForSystem()或调试器看PROCESS_DPI_AWARENESS未声明或 Unaware 是头号嫌疑。鼠标坐标和控件矩形是否在同一坐标系在点击处理里同时打印「原始事件坐标」和「控件矩形」二者数值量级差一个 scale 倍率即可确认错位。按钮是不是用绝对像素place(x, y)钉死的改成布局锚定pack/grid anchor或 flex/absolute 相对右上角。是否混用了 CSSzoom或自绘缩放多层缩放叠加会让命中测试雪上加霜优先用系统级缩放而非 CSS zoom。多显示器不同缩放时是否重排监听 DPI 变化事件窗口跨屏后强制重算布局与热区。框架版本是否已知坑某些 Tk / Electron 旧版默认不开启感知升级或显式开启即可。最小化逻辑本身有没有被短路排除法先把按钮command换成打印日志确认「点不中」还是「点中但不执行」——前者是坐标问题后者是业务逻辑问题。十、小结「放大显示后最小化按钮点不动」看似是个偶发 UI Bug根子上是DPI 感知声明与 GUI 框架实际坐标行为不一致导致鼠标物理坐标和控件逻辑矩形落在了两个坐标系。通用修复三板斧声明 DPI 感知WindowsSetProcessDpiAwareness(2)且在建窗口前调用统一坐标空间命中测试一律先物理 / scale换算回逻辑坐标再比对布局锚定代替固定像素让控件随缩放自适应贴边。 跨平台时记住Windows 看PROCESS_DPI_AWARENESS、macOS 看backingScaleFactor、Linux 看get_scale_factor()三者数值含义一致——都是「物理像素 逻辑像素 × scale」。只要全程只用逻辑坐标做布局与命中测试缩放再高也不会让按钮跑偏。
