SetForegroundWindow直接调用常失败，因要求调用线程必须处于前台状态；后台线程、服务进程或跨会话场景下会静默失效，需配合AttachThreadInput、ShowWindow、AllowSetForegroundWindow等手段并校验窗口可见性、进程完整性级别及虚拟桌面状态。
Windows平台下用SetForegroundWindow激活进程窗口
直接调用SetForegroundWindow是让窗口获得输入焦点最常用的方式，但它有严格前提：调用线程必须拥有前台状态（foreground state），否则系统会静默失败。这意味着不能在后台线程或服务中随意调用它——哪怕你拿到了目标窗口句柄。
常见错误现象：SetForegroundWindow返回FALSE，但没报错；任务栏图标闪烁但窗口不弹出；窗口短暂亮起又退到后台。
- 先用
GetForegroundWindow确认当前前台窗口，再用AttachThreadInput把当前线程和目标窗口所属线程输入队列关联（需目标线程已进入消息循环） - 调用前最好先用
ShowWindow确保窗口不是最小化或隐藏状态，例如ShowWindow(hwnd, SW_RESTORE) - 如果目标进程刚启动，它的主线程可能还没创建窗口消息循环，此时应加短延时或轮询
FindWindow，避免空句柄操作
如何通过进程ID获取主窗口句柄
进程ID本身不直接对应窗口，必须遍历其创建的顶层窗口并筛选出“主窗口”——通常指可见、启用、非工具窗口且属于该进程的首个匹配项。
关键点在于EnumWindows + GetWindowThreadProcessId组合使用，而不是依赖FindWindow（后者需要知道类名或标题，不可靠）。
立即学习“C++免费学习笔记（深入）”；
- 遍历时用
IsWindowVisible和IsWindowEnabled过滤掉无效窗口 - 跳过子窗口：检查
GetParent(hwnd) == nullptr - 避免误选托盘图标窗口：用
GetWindowLong(hwnd, GWL_EXSTYLE) & WS_EX_TOOLWINDOW排除 - 多个窗口时优先选
WS_VISIBLE | WS_POPUP或WS_VISIBLE | WS_OVERLAPPED风格的
跨会话（Session 0隔离）场景下无法激活的现实限制
Windows Vista之后的服务默认运行在Session 0，而用户桌面在Session 1及以上。即使你拿到用户会话中某个进程的PID，从服务进程中调用SetForegroundWindow也必然失败——这是系统级安全限制，无法绕过。
典型表现：GetLastError()返回ERROR_ACCESS_DENIED，或函数直接返回FALSE且无日志提示。
- 若程序以服务身份运行，必须改用“交互式服务”模式（不推荐）或通过
WTSQueryUserToken+CreateProcessAsUser在用户会话中启动辅助进程来执行激活逻辑 - 普通桌面程序无需考虑此问题，但打包成安装器或后台守护进程时容易踩坑
- UAC提升后的新进程可能归属不同完整性级别，导致
SetForegroundWindow被UIPI（用户界面特权隔离）拦截，此时需确保调用方和目标窗口完整性级别一致
完整流程中容易忽略的细节
从启动进程到成功唤起前台，中间至少涉及四层状态校验：进程是否存在 → 主窗口是否已创建 → 窗口是否可见/启用 → 当前线程是否有权激活。任一环节中断都会导致静默失败。
- 不要假设
ShellExecute后立刻能FindWindow到窗口，有些GUI程序初始化慢，建议用WaitForInputIdle等待主线程空闲 -
SetForegroundWindow在Windows 10 1809+对非活动虚拟桌面的窗口无效，需先用SwitchToThisWindow（已废弃但仍可用）或MoveWindowToDesktop（需API >= 1903）切换桌面 - 某些全屏游戏或Kiosk模式应用会主动重置前台状态，即使你成功激活，几秒后也可能被系统强制切回
