SetConsoleCtrlHandler是Windows下响应Ctrl+C或关闭按钮的唯一可靠方式，必须在主线程以WINAPI调用约定注册全局函数，回调中仅设原子标志位并返回TRUE，由主循环协调清理。
Windows 控制台程序如何响应 Ctrl+C 或关闭按钮
直接说结论：SetConsoleCtrlHandler 是 Windows 下唯一可靠的方式，让控制台程序在用户按下 Ctrl+C、点击窗口右上角 ×、或系统关机时执行自定义清理逻辑。它不是“异常捕获”，也不是信号 handler（像 Linux 的 signal()），而是一个 Windows 特有的控制台事件回调机制。
常见错误是试图用 try/catch 捕获 Ctrl+C —— 完全无效；或者只注册 handler 却没做线程同步，导致主线程已退出、回调还在访问已析构对象；又或者返回 FALSE 后没手动调用 ExitProcess()，结果程序卡住不动。
- 必须在主线程中调用
SetConsoleCtrlHandler，且越早越好（比如main()开头） - 回调函数必须是
WINAPI调用约定（即__stdcall），C++ 成员函数不能直接传入（需 static 或全局函数） - 返回
TRUE表示“我处理了，别终止进程”，返回FALSE表示“交还给系统默认行为（立刻终止）” - 若想优雅退出，通常返回
TRUE，然后在回调里设标志位 + 主循环检测，或用SetEvent()唤醒等待线程
回调函数里能安全做什么
控制台控制事件回调运行在**独立的系统线程**中，且有严格限制：不能调用大多数 Win32 API（如 CreateThread、LoadLibrary、printf），也不能执行耗时操作。它的设计目标是快速响应并通知主逻辑，而非完成全部清理工作。
典型安全操作包括：
立即学习“C++免费学习笔记（深入）”；
- 设置一个
volatile std::atomic<bool></bool>标志（如g_shutdown_requested） - 调用
SetEvent(g_shutdown_event)唤醒主线程或工作线程 - 调用
Beep()或OutputDebugString()（仅限调试）
不安全操作示例：
std::cout → 可能死锁（<code>cout内部加锁，与控制台 I/O 线程冲突）-
delete g_resource;→ 对象可能正被其他线程使用，析构不安全 -
std::this_thread::sleep_for(...);→ 阻塞回调，系统会判定你的程序无响应
完整可运行示例（含线程协同）
以下是最小可行结构，重点展示标志位协作和主线程退出等待：
#include <windows.h>
#include <atomic>
#include <thread>
#include <iostream>
std::atomic<bool> g_shutdown_requested{false};
BOOL WINAPI ConsoleCtrlHandler(DWORD dwType) {
switch (dwType) {
case CTRL_C_EVENT:
case CTRL_CLOSE_EVENT:
case CTRL_LOGOFF_EVENT:
case CTRL_SHUTDOWN_EVENT:
g_shutdown_requested = true;
return TRUE; // 阻止系统默认终止
default:
return FALSE;
}
}
int main() {
if (!SetConsoleCtrlHandler(ConsoleCtrlHandler, TRUE)) {
std::cerr << "Failed to set console handler\n";
return 1;
}
std::cout << "Running... Press Ctrl+C or close window to exit.\n";
while (!g_shutdown_requested) {
std::this_thread::sleep_for(std::chrono::milliseconds(100));
}
std::cout << "Cleanup started...\n";
// 这里放资源释放、日志刷盘等操作
std::cout << "Goodbye.\n";
return 0;
}
注意：CTRL_LOGOFF_EVENT 和 CTRL_SHUTDOWN_EVENT 在交互式登录会话中极少触发，但服务类控制台程序可能需要响应；如果只关心 Ctrl+C 和关闭按钮，保留前两个即可。
为什么 CTRL_CLOSE_EVENT 有时不触发
这是最常被忽略的坑：当程序创建了额外的 GUI 窗口（比如用 CreateWindow 或 Qt/WinAPI GUI 组件），或调用了 AllocConsole() 之后又调用 FreeConsole()，控制台句柄状态可能异常，导致 CTRL_CLOSE_EVENT 不再送达。
验证方法：在回调里加 OutputDebugString(L"Got CTRL_CLOSE"); 并用 Visual Studio 调试器 Attach，看输出；或用 Process Explorer 查看进程是否仍关联有效控制台（Property → Threads → Console Handle 是否为有效值）。
真正可靠的关闭响应依赖两点：一是确保程序始终持有且只持有一个控制台（不要反复 FreeConsole/AllocConsole），二是把所有清理逻辑收敛到单一标志位 + 主循环检查模式——而不是指望每次关闭都能进回调。
