cv2.waitKey() 无法可靠识别 Delete 键，因其仅返回低 8 位键码；应改用 cv2.waitKeyEx() 获取完整虚拟键值，并避免使用 & 0xFF 掩码操作。
`cv2.waitkey()` 无法可靠识别 delete 键，因其仅返回低 8 位键码；应改用 `cv2.waitkeyex()` 获取完整虚拟键值，并避免使用 `& 0xff` 掩码操作。
在 OpenCV 的键盘事件处理中，cv2.waitKey() 是最常用的方法，但它存在一个关键限制：它会截断操作系统传入的原始键值，仅保留最低 8 位（即 & 0xFF 效果已内建）。这导致许多功能键（如 Delete、F1–F12、方向键、Home、End 等）无法被准确识别——因为它们在 Windows 上通常以扩展键码（extended key code）形式返回，高位包含重要标识信息。
例如，在 Windows 平台下：
- 按下 Delete 键时，系统实际发送的是
0x2E0000（十六进制），其中高字节0x2E表示 VK_DELETE 虚拟键码，后缀0x0000表示扩展键标志； -
cv2.waitKey(1)会将其截断为0x00（即十进制0），因此key == 127（ASCII DEL）或key == 0均不可靠； - 而
cv2.waitKeyEx(1)则原样返回0x2E0000（即十进制3014656），可精准匹配。
✅ 正确做法：使用 cv2.waitKeyEx() 并直接比对完整键值：
import cv2
# 示例：检测 Delete 键（Windows）及跨平台兼容写法
while True:
# 注意：无需 & 0xFF！waitKeyEx 返回完整整数
key = cv2.waitKeyEx(1)
if key == -1: # 无按键事件
continue
print(f"Raw key code: 0x{key:X} (dec: {key})")
# Windows Delete 键：0x2E0000 → 十进制 3014656
if key == 0x2E0000:
print("✅ Delete key detected on Windows!")
break
# macOS/Linux 可能不同（如部分环境返回 127 或 65535），建议按需适配
# （注：OpenCV 对非 Windows 平台的功能键支持有限，实际行为依赖 backend 和 GUI 库）
cv2.destroyAllWindows()⚠️ 重要注意事项：
-
永远不要对
waitKeyEx()结果执行& 0xFF：这会彻底破坏扩展键信息，使0x2E0000变成0x00，导致无法识别； -
cv2.waitKey()内部已自动做& 0xFF，所以显式添加不仅多余，还会将超时返回值-1错误转为255，干扰逻辑判断； -
waitKeyEx()自 OpenCV 3.2+ 起稳定支持，但仅在启用 GUI 后端（如 Win32、Cocoa、GTK）时有效；若使用 headless 模式（如cv2.setHeadless(True)）或某些 Docker 环境，可能返回-1或不支持； - 跨平台一致性有限：Delete 键在 macOS 或 Linux 下可能映射为不同值（如
127或65535），建议结合sys.platform做条件判断，或优先测试目标部署环境。
? 总结：要稳健捕获 Delete 键，请统一迁移到 cv2.waitKeyEx()，移除所有 & 0xFF，并使用十六进制常量（如 0x2E0000）进行精确匹配。这是 OpenCV 官方推荐的功能键检测方式，也是解决该问题的唯一可靠路径。
