做 Windows 桌面图像识别时，一个很容易被低估的问题是：识别代码在固定位置测试正常，并不代表用户移动窗口后仍然正常。窗口从屏幕左侧拖到右侧，或者从 1920×1080 的屏幕换到 2560×1440 的屏幕，原来写死的截图区域和点击坐标就会整体偏移。
金手指早期的一些识别流程也遇到过这种情况。开发机上按钮位置固定，连续测试没有问题；换到不同窗口位置以后，同一张模板有时找不到，有时虽然能找到，点击位置却落在按钮外侧。后来我们把关键识别区域、覆盖层和点击位置全部调整为以当前游戏窗口为基准，稳定性才真正提升。
屏幕坐标和窗口坐标是两套概念
屏幕坐标以整个桌面的左上角为原点。例如一个按钮在屏幕上的位置是 (1350, 620)，这个位置只对当前窗口摆放方式有效。用户把窗口向左移动 200 像素后，按钮的新屏幕坐标也会向左移动 200 像素。
窗口相对坐标则以游戏客户区左上角为原点。只要游戏窗口内部布局没有变化，按钮相对于窗口的位置通常保持一致。实际点击前，程序读取当前窗口位置，再把相对坐标换算成最新的屏幕坐标。这样窗口移动以后，识别区域和点击目标会跟着移动。
这个思路看起来简单，但实现时还要区分窗口外框、标题栏和真正的客户区。如果直接拿整个窗口左上角做基准，Windows 主题、边框宽度或窗口模式变化都可能产生几像素到几十像素的偏差。
每次关键操作前都要获取最新窗口位置
另一种常见问题是，程序启动时只读取一次窗口坐标，之后一直复用。用户在任务运行过程中移动窗口，旧坐标仍然保存在内存里，后续识别自然会偏移。
我们现在的处理方式是：
- 选择队长窗口后保存窗口标识，而不是只保存一次坐标；
- 每次关键截图前重新获取窗口当前矩形；
- 所有识别区域先使用窗口相对位置描述，再换算成屏幕区域；
- 识别结果也转换为相对位置，方便日志和调试覆盖层统一展示；
- 执行点击前再次确认目标窗口和最新坐标，降低窗口刚刚移动造成的误差。
这样做会比完全固定坐标多几次系统调用，但对于桌面自动化来说，稳定性通常比节省这点时间更重要。
DPI 缩放会同时影响截图和点击
在 2K 或 4K 显示器上，Windows 经常使用 125%、150% 等缩放比例。部分接口返回的是逻辑坐标，截图工具和鼠标接口使用的却可能是物理像素。如果两套坐标没有统一，就会出现一种很典型的现象：模板识别框看起来是对的，鼠标点击却按固定比例偏到旁边。
排查这类问题时，需要同时记录窗口矩形、截图尺寸、系统缩放比例和最终点击坐标，单看鼠标位置往往找不到原因。金手指在调试关键流程时，会把识别区域和点击点画在窗口截图上，再对比实际分辨率检查偏移，而不是依靠肉眼猜测一个修正值。
固定减去几像素也许能让当前电脑暂时正常，但换一台设备后通常会再次出问题。更可靠的做法是把程序声明为 DPI 感知，并统一截图、窗口矩形和鼠标输入使用的坐标体系。
多分辨率下模板也需要同步适配
窗口位置变化解决的是平移问题，窗口尺寸变化还会带来缩放问题。同一个按钮在 1080P 窗口中可能宽 80 像素，在更大的窗口里可能变成 100 像素。如果始终用一张固定尺寸模板匹配，置信度会明显下降。
我们的处理思路不是无限扩大搜索范围，而是围绕预期尺寸准备有限的多尺度匹配，并优先缩小到业务上合理的窗口区域。这样既能适应常见尺寸变化，又能减少页面中相似文字、相似按钮造成的误识别。
模板匹配阈值也不是越低越好。阈值过高可能漏掉轻微缩放或抗锯齿变化，阈值过低则容易把相似图案当成目标。比较有效的方式是保存失败截图和候选位置，分析真实样本后再调整阈值，而不是只根据一次成功结果决定。
找到目标以后不要立刻盲点
图像识别返回一个高分候选位置，只能说明这一帧画面里出现了相似区域。弹窗可能正在切换，按钮可能刚刚消失，窗口也可能在识别后被其他窗口遮挡。因此点击之前还需要做最基本的复核：
- 确认目标仍然位于当前游戏窗口客户区；
- 确认窗口没有最小化或切换到其他程序；
- 对关键按钮进行短间隔再次识别；
- 点击后观察预期界面是否出现；
- 未出现时回到当前步骤重新识别，而不是连续点击固定位置。
这种“识别、点击、验证”的闭环比“识别一次后连续执行坐标脚本”更慢一点，却更适合实际桌面环境。
开发日志比一句稳定更有价值
对开发者来说，真正有用的稳定性来自每一次失败截图、日志时间点和可复现步骤。窗口移动、DPI 缩放、弹窗遮挡和界面加载速度都会影响结果，因此我们会继续把识别流程做成窗口相对、多尺度并且可验证的操作链。