Win10下Delphi Hook控件时鼠标静止WM_NCHITTEST高频触发是否正常？

该现象属于Windows系统的正常行为，既不是代码逻辑疏漏，也不是Win10新版本API的异常变更。

消息的真实触发逻辑 #

WM_NCHITTEST是Windows窗口命中测试机制的核心消息，很多开发者对它的触发规则存在认知偏差：

• 公开文档通常只说明“鼠标移动时，系统会沿窗口层级链向鼠标指针下的窗口逐次发送WM_NCHITTEST，判断命中的窗口区域，以此决定后续派发的鼠标消息类型”，但很少提及系统自带的固定间隔轮询机制：哪怕鼠标完全静止，系统也会按固定频率向当前指针下的窗口持续发送WM_NCHITTEST，用来校验窗口层级、区域边界、可见性是否发生变化——比如窗口被拖动、被其他窗口遮挡、代码动态修改客户区范围的场景，不需要依赖鼠标移动事件就能实时更新命中结果，保证鼠标交互的响应速度。
• 在Win10 20H2及后续版本中，这个后台轮询的默认频率被系统调到了较高水平，适配高DPI、多窗口叠加场景下的流畅交互需求，静止悬停时每秒收到几十到上百条WM_NCHITTEST是系统的默认行为。

为什么你的测试场景会感知到异常的高频率 #

你观察到的“每秒数百条持续计数”的效果，其实是测试代码和系统机制形成了正反馈循环：

• 你的钩子逻辑中，每收到一条WM_NCHITTEST就立刻执行Label1.Caption := FormatFloat(...)修改文本。修改Label内容会立刻触发控件重绘、窗口区域重新计算，这个过程会打破系统原本的命中测试缓存，导致系统需要重新校验当前的命中结果，进而派发新的WM_NCHITTEST。相当于每一条触发的消息，都在主动制造下一条消息的触发条件，最终形成计数爆发式增长的效果。
• 可以通过两个简单的对照实验验证这个逻辑：
  • 删掉代码里更新Label Caption的逻辑，只保留对WM_NCHITTEST的纯计数，不做任何UI相关操作，此时计数会稳步增长，但不会出现每秒数百条的爆发式涨幅，回到系统默认的轮询频率水平。
  • 给Label更新逻辑加时间戳判断，只有距离上次刷新超过1秒才更新一次文本，此时计数增长速度会回落到正常水平，不会再形成正反馈循环。

开发注意事项 #

• 不需要因为WM_NCHITTEST的高频触发做特殊性能处理：只要你的窗口过程对该消息的处理是轻量透传（也就是直接调用默认窗口过程，返回标准的命中测试结果，不做额外的重绘、界面修改操作），哪怕每秒收到上百条消息，也不会带来可感知的性能消耗。
• 如果你的业务确实需要拦截处理WM_NCHITTEST逻辑，不要在该消息的处理分支里执行任何会触发窗口重绘、区域变更的操作，否则很容易和系统的轮询机制形成上述的正反馈循环。

内容的提问来源于stack exchange，提问作者Guy R