不能。GetConsoleScreenBufferInfo 仅返回 CONSOLE_SCREEN_BUFFER_INFO 结构，包含光标位置、窗口大小等缓冲区信息，不含 HWND 字段；获取控制台窗口句柄应使用 GetConsoleWindow() 函数。
GetConsoleScreenBufferInfo 能不能直接拿到 HWND？
不能。这个函数只返回控制台屏幕缓冲区信息（如光标位置、窗口大小），CONSOLE_SCREEN_BUFFER_INFO 里没有 HWND 字段。很多人误以为控制台和普通窗口一样有显式句柄，其实 Win32 控制台是特殊的子系统——它由 conhost.exe 托管，主进程的 GetConsoleWindow() 才是正解。
GetConsoleWindow() 是最可靠的方法
该函数专为获取当前进程关联的控制台窗口句柄设计，只要进程有控制台（无论是 AllocConsole 创建的，还是 cmd 启动的），就返回有效 HWND；没控制台时返回 NULL。
使用要点：
- 需包含
<windows.h> - 无需额外权限或初始化，调用即得
- 返回值必须检查是否为
NULL，尤其在服务或无界面环境下容易失败 - 如果进程通过
FreeConsole()主动释放了控制台，后续调用也返回NULL
示例：
立即学习“C++免费学习笔记（深入）”；
HANDLE hConsole = GetStdHandle(STD_OUTPUT_HANDLE);
HWND hwnd = GetConsoleWindow();
if (hwnd == NULL) {
// 没有控制台窗口，可能运行在后台或被重定向
}
为什么 FindWindow(L"ConsoleWindowClass", nullptr) 不推荐？
这个方法依赖窗口类名硬编码，且存在多个隐患：
- Windows 版本差异大：Win10 1903+ 默认用新
WindowsTerminal，类名变成WindowsTerminal或WTWindow，老代码直接失效 - 多控制台场景下无法区分归属：如果同时开了多个 cmd，
FindWindow可能返回任意一个，不保证是当前进程的 - UAC 提权后类名可能变化，或被安全策略隐藏窗口
除非你明确要 hook 其他进程的控制台（且已知其类名），否则绕过 GetConsoleWindow() 直接枚举是自找麻烦。
AttachConsole + GetConsoleWindow 的组合陷阱
当进程原本没有控制台（比如 GUI 程序），想临时附加一个时，常见错误是：
- 调用
AttachConsole(ATTACH_PARENT_PROCESS)后立即调用GetConsoleWindow()—— 这时句柄可能还没就绪，返回NULL - 未同步重定向标准流：
freopen("CONIN$", "r", stdin)和freopen("CONOUT$", "w", stdout)缺一不可，否则printf仍输出到原位置 - 忘记在退出前调用
FreeConsole()，导致控制台窗口残留
正确顺序应为：AttachConsole → 重定向 stdio → GetConsoleWindow()（可加短延时或循环等待非空）→ 使用 → FreeConsole()。
真正难的不是获取句柄本身，而是判断「此刻有没有一个确定归属、可用、未被重定向或隐藏的控制台窗口」——这需要结合 GetStdHandle、GetConsoleMode 和 GetConsoleWindow 三者交叉验证，而不是只盯住一个 API。
