SetWindowPos加HWND_TOPMOST不生效的关键在于窗口句柄有效性、线程消息循环就绪及系统策略拦截；需在WM_SHOWWINDOW或WM_PAINT后调用，配合SWP_NOMOVE|SWP_NOSIZE|SWP_NOACTIVATE，并确保UI线程执行。
SetWindowPos 为什么加了 HWND_TOPMOST 还不生效
关键在窗口句柄是否有效、线程消息循环是否就绪，以及是否被系统策略拦截（比如全屏游戏、UWP 应用）。SetWindowPos 必须在窗口已创建且完成首次绘制后调用，否则会被忽略。常见错误是创建窗口后立刻设置顶，但此时 WM_CREATE 可能还没处理完，窗口尚未进入可交互状态。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 在
WM_SHOWWINDOW或WM_PAINT首次触发后调用SetWindowPos，更稳妥的是在PostMessage(hWnd, WM_USER + 1, 0, 0)延迟一帧再执行 - 确保传入的
hWnd是有效的顶层窗口句柄（不是子窗口），可用IsWindow先校验 - 必须指定
SWP_NOMOVE | SWP_NOSIZE | SWP_NOACTIVATE，否则可能意外改变位置/大小，或抢走输入焦点导致用户反感
HWND_TOPMOST 和 HWND_NOTOPMOST 的行为差异
HWND_TOPMOST 不是“永久置顶”，而是让窗口始终在所有非 TOPMOST 窗口之上，但它仍会屈居于其他已设为 HWND_TOPMOST 的窗口之下——谁设得晚，谁压在上面。而 HWND_NOTOPMOST 是“非强制置顶”，它只保证高于普通窗口，但低于所有 HWND_TOPMOST 窗口，适合做半透明工具栏这类需要“不打扰但可见”的场景。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 若需长期稳定置顶，应在窗口生命周期内定期重置：比如响应
WM_ACTIVATE时检查当前 z-order，必要时再调一次SetWindowPos(hWnd, HWND_TOPMOST, ...) - 避免在后台线程调用
SetWindowPos；必须在创建该窗口的 UI 线程中执行，否则可能失败且不报错 - 某些安全软件或 Windows 设置（如“专注助手”）会临时禁用 TOPMOST，此时
SetWindowPos返回 TRUE 但实际无效——需配合GetWindowPlacement检查showCmd是否为SW_SHOWMAXIMIZED或SW_SHOWNORMAL来间接判断
SetWindowPos 调用失败但没报错怎么办
Windows API 多数函数靠返回值判断成败，SetWindowPos 成功返回非零值，失败返回 0。但它不设置 GetLastError()，所以不能靠 GetLastError 查原因。真正有用的线索藏在参数合法性里：比如 hWnd 为空、窗口已被销毁、或当前进程没有桌面交互权限（服务进程默认无权操作用户桌面窗口）。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 调用前加断言：
assert(IsWindow(hWnd) && "window handle invalid")，比事后排查快得多 - 若窗口由另一个进程创建（比如注入 DLL 后操作第三方窗口），需确保目标进程未启用 UIPI（User Interface Privilege Isolation），否则跨完整性级别调用会被静默拒绝
- 调试时可用
EnumThreadWindows(GetCurrentThreadId(), ...)列出当前线程所有窗口，确认目标hWnd是否在其中
全局置顶在多显示器或 DPI 缩放下的注意事项
置顶本身不受多屏影响，但窗口坐标系和缩放会影响视觉表现。如果窗口在高 DPI 显示器上创建，而 SetWindowPos 传入的是物理像素坐标（没做 DPI 缩放适配），可能导致窗口错位或部分不可见；更隐蔽的问题是：当用户把窗口拖到另一块不同 DPI 的屏幕时，系统可能自动调整其大小，进而触发 WM_SIZE，此时若代码里硬编码了尺寸逻辑，会和置顶行为产生冲突。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 调用
SetProcessDpiAwarenessContext(DPI_AWARENESS_CONTEXT_PER_MONITOR_AWARE_V2)开启每监视器 DPI 感知（Win10 1703+） - 获取窗口位置前，先用
GetDpiForWindow(hWnd)拿当前 DPI，再对坐标做MulDiv(x, 96, dpi)归一化处理 - 不要依赖
GetWindowRect的绝对坐标做置顶逻辑；改用GetWindowPlacement获取rcNormalPosition，它已按当前 DPI 校准
真正麻烦的不是怎么设 TOPMOST，而是怎么让它“不干扰用户又一直顶着”——比如用户 Alt+Tab 切换时你强行保持激活，或者在演示模式下被系统自动降级，这些边界情况比 API 调用本身更消耗调试时间。
