windows下用getasynckeystate实时检测按键需检查返回值最高位0x8000以确认当前按下状态，避免误判历史触发；linux下用termios关闭行缓冲与回显实现单字符读取；跨平台应条件编译而非依赖std::cin。
Windows下用GetAsyncKeyState实时检测按键
它不阻塞、不需窗口消息循环，适合游戏或快捷键监听。但要注意：返回值是short，必须检查第15位是否为1（即(GetAsyncKeyState('A') & 0x8000) != 0），只查高位才能确认“当前正被按下”，否则可能误判为刚释放过的残留状态。
常见错误是直接写if (GetAsyncKeyState('A'))——这会把“曾按下过但已松开”的历史状态也当真，导致单次按键触发多次逻辑。
- 只对ASCII字符和常用虚拟键码（如
VK_LEFT、VK_SPACE）有效，中文输入法下的组合键（如Ctrl+Shift+U）无法可靠捕获 - 需要
#include <windows.h></windows.h>，且程序要有前台焦点才能稳定响应（后台进程可能被系统限频） - 高频轮询（比如每毫秒调一次）几乎无性能压力，但别在主线程死循环里跑，建议用独立线程或结合
Sleep(1)
Linux下用termios关闭回显并读单字符
标准cin >> key要按回车才生效，而终端默认是行缓冲模式。改用termios可切换成字符级输入：先tcgetattr保存原设置，再清掉ICANON（禁用行缓冲）和ECHO（关闭回显），最后tcsetattr生效。
注意read(STDIN_FILENO, &c, 1)在非阻塞模式下可能返回0（EOF）或-1（EAGAIN），但通常设为阻塞更稳妥；如果程序中途被信号中断，read可能返回-1且errno == EINTR，得重试。
- 箭头键、F1-F12等会产生多字节ESC序列（如←是
\033[A），需连续读2–3次才能完整识别，不能只取第一个字节 - 退出前务必恢复原始
termios设置，否则终端会乱（光标不显示、回车不换行等），可用RAII封装或atexit()注册恢复函数 - 该方法依赖终端，SSH连接或重定向到文件时会失效（
isatty(STDIN_FILENO)可提前判断）
C++跨平台？别硬套std::cin，它根本不读按键事件
std::cin.get()或std::getline()本质仍是等待换行符，底层走的是C标准库的fgetc，受制于系统终端驱动的行缓冲策略。所谓“跨平台”方案如果只靠标准库，结果就是Windows下卡住、Linux下要回车、macOS下行为还不一致。
真正跨平台的路只有两条：要么用SDL2 / GLFW这类图形库接管输入（适合有窗口的应用），要么用第三方终端库如libuv或linenoise（适合命令行工具）。自己写条件编译虽然可控，但#ifdef __linux__和#ifdef _WIN32之间差的不只是头文件，还有信号处理、线程调度、甚至键盘重复延迟的实现逻辑。
- Qt的
QKeyEvent看起来优雅，但它强制要求GUI事件循环，控制台程序根本用不了 - 某些教程推荐
conio.h的_getch()，这在MSVC上能用，但GCC/Clang不支持，也不是C++标准，移植性等于零 - 如果只是想让脚本式工具支持快捷键（比如按q退出），优先考虑Linux用
termios+ Windows用GetAsyncKeyState双实现，比强求统一更省心
为什么kbhit()和_getch()在现代C++项目里容易崩
这两个函数来自老旧的conio.h，微软早已标记为deprecated。VS2019之后默认不链接legacy_stdio_definitions.lib，直接调用会报LNK2019未解析外部符号；即使链接成功，在启用/MDd（动态调试CRT）时也可能因CRT版本混用崩溃。
更隐蔽的问题是：它们和C++流（std::cin）共享stdin缓冲区，混用会导致数据错位——比如先调_getch()读了'Y'，再std::cin >> num就可能把后续输入吞掉或阻塞在奇怪位置。
- 替代方案不是“找个新函数”，而是明确区分场景：需要无回车交互 → 用平台原生API；只需要用户输完回车 → 老老实实用
std::getline() - 如果必须兼容旧代码，至少加一层包装，用
#ifdef隔离实现，并在头文件里用static_assert锁死编译器和运行时环境 - 最常被忽略的一点：键盘输入永远不是“纯数据”，它夹杂着输入法状态、终端编码（UTF-8 vs GBK）、甚至SSH的传输延迟——调试时看到的“没反应”，八成是卡在了输入法预编辑区里
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
