FindWindow 返回0主因是窗口类名或标题不匹配，需用Spy++确认真实值；动态标题应改用EnumWindows+GetWindowTextLength+StringBuilder遍历；操作前须用IsWindow验证句柄有效性，SendMessage失败多因UIPI拦截或无消息循环。
FindWindow 为什么总是返回 0？
直接调用 FindWindow 返回 0，基本等于没找到——不是 API 失败，而是条件不匹配。它只认窗口类名（lpClassName）或窗口标题（lpWindowName）的**完整、精确、未截断**字符串，且区分 Unicode/ANSI 编码。比如记事本默认标题是“无标题 - 记事本”，但若用户改过标题、开了多个实例、或用了 Windows 11 的新 UI（标题栏文字被裁剪），FindWindow 就会失效。
实操建议：
- 先用 Spy++ 或
WinSpy++确认目标窗口的真实标题和类名，别信任务管理器或 Alt+Tab 显示的内容 - 如果标题动态变化（如含文件名、时间戳），改用
EnumWindows+GetWindowText遍历比对，支持模糊匹配 - 确保 P/Invoke 声明中
CharSet设为CharSet.Unicode（.NET Core/.NET 5+ 默认如此，但 .NET Framework 项目需显式指定）
EnumWindows 遍历时 GetWindowText 拿不到完整标题？
GetWindowText 写入缓冲区时，若传入的字符数组长度不够，它会静默截断，不报错也不提示。常见错误是传 new char[256]，结果遇到长路径或含 emoji 的标题就丢内容。
实操建议：
- 先调用一次
GetWindowTextLength获取实际长度，再分配对应大小的StringBuilder（不是char[]） - 用
StringBuilder.Capacity预留足够空间（例如 1024），避免多次扩容影响遍历性能 - 注意：某些 UWP 应用或受保护进程（如银行软件）会拒绝返回标题，此时
GetWindowText返回 0，需跳过处理
C# 中怎么安全判断窗口是否已销毁？
拿到句柄后不能直接用，因为窗口可能在你调用 FindWindow 后瞬间关闭。用 IsWindow 是最轻量的验证方式，比发消息或查进程更可靠。
实操建议：
- 每次使用前都调用
IsWindow(hWnd)，返回false就立刻放弃该句柄 - 避免缓存句柄长期复用——尤其跨线程或定时轮询场景，窗口生命周期不可控
- 如果后续要发消息（如
SendMessage），记得检查IsWindowEnabled和IsWindowVisible，否则可能阻塞或失败
为什么 SendMessage 调用失败但 GetLastError 是 0？
SendMessage 本身不设置 last error，只有部分失败路径（如目标线程挂起）才让 GetLastError 有意义。更常见的原因是：目标窗口没消息循环（控制台程序）、句柄无效、消息 ID 不被支持，或者跨权限（如管理员进程向非管理员进程发消息会被 UIPI 拦截）。
实操建议：
- 优先用
PostMessage替代SendMessage，避免线程阻塞和 UIPI 限制 - 发自定义消息前，确认目标窗口已注册该消息（
RegisterWindowMessage），否则接收端收不到 - 调试时用
SetWindowsHookEx(WH_CALLWNDPROC)在目标进程侧抓消息流，比单看返回值更准
窗口句柄操作的麻烦点不在 API 调用本身，而在 Windows 对窗口状态、权限、UI 线程模型的隐式约束——这些约束不会报错，只会让结果看起来“随机失败”。
