Screen to Gif 录制区域选择：一个嵌入式工程师眼中的“像素级控制”实践指南
你有没有遇到过这样的场景？
在调试一块刚点亮的工业HMI屏时，客户发来一句：“触摸没反应”，附带一张模糊截图——箭头手绘歪斜、关键按钮被任务栏遮挡、进度条颜色看不清。你花了20分钟复现，结果发现是串口配置里少了一个回车符。
又或者，在写一份MCU Bootloader升级文档时，反复截图、拼接、标注，最后导出的GIF在Confluence里放大后全是马赛克，同事还得再问一遍：“那个‘Verify’按钮到底点没点？”
这些不是效率问题，而是信息捕获链路的失真。而Screen to Gif的“录制区域选择”，正是这条链路上最常被忽略、却最具决定性的一环——它不生产内容，但它决定了内容是否可信、是否可复现、是否能脱离上下文独立传达意图。
这不是教你怎么点鼠标，而是带你拆开它的UI外壳，看看它如何与Windows内核对话、如何在多屏DPI混杂的桌面空间里精确定位一个像素、如何让一段3秒动图成为比千字文档更有力的技术证据。
为什么“选中一块区域”这件事，值得花时间深挖？
很多用户把Screen to Gif当成“轻量版OBS”：点开→拖一下→录完→导出。但当你开始用它记录Tera Term里的AT指令响应、Qt Creator中QML界面的过渡动画、或是WinUI3应用里那个半透明浮动工具栏时，你会发现：
- 同样的拖拽动作，在1080p主屏上框得很准，一挪到右侧4K副屏就偏移了5像素；
- 点击“跟随窗口”后，录出来的画面总缺了一小条标题栏阴影；
- 固定尺寸设成800×480，但导出的GIF实际是798×477，且边缘有轻微模糊。
这些问题背后，没有bug，只有系统级权衡：是优先保证坐标精度，还是兼容DirectX渲染？是响应鼠标事件更快，还是过滤抖动更彻底？是截取整个窗口矩形，还是只抠客户区？Screen to Gif的每个开关、每行配置、每次鼠标松开，都是对这些权衡的一次显式投票。
我们不讲抽象原理，直接从你按下鼠标左键那一刻开始，一层层往下拆：
拖拽框选：不只是“画个方块”，而是一场与Windows坐标的实时谈判
当你按住鼠标左键开始拖动，Screen to Gif做的第一件事，不是画框，而是接管你的鼠标坐标流。
它通过SetWindowsHookEx(WH_MOUSE_LL, ...)挂载低级鼠标钩子，绕过目标应用的消息循环，直接从系统输入队列中捕获原始MOUSEMOVE事件。这意味着：
✅ 即使你正在录一个全屏独占模式的游戏（虽然不推荐），它仍能拿到鼠标位置；
❌ 但如果你启用了Windows设置里的“
