使用 `robot` 类模拟键盘操作上传文件时，若未正确释放组合键（如 ctrl），会导致系统级按键卡住，进而引发全局键盘异常——这是典型的键位未释放导致的系统输入阻塞问题。
在自动化测试中，借助 java.awt.Robot 模拟 Ctrl+V 粘贴文件路径、再用 Ctrl+Enter 确认对话框，是一种常见的绕过 Web 元素不可直接 sendKeys() 限制的方案。但该方法高度依赖底层操作系统输入事件，任何未配对的 keyPress() 都会持续“按下”对应物理键，从而干扰后续所有用户操作——这正是你遇到“重启才恢复”的根本原因。
从你提供的代码可见，问题明确出现在最后两行：
robot.keyPress(KeyEvent.VK_CONTROL); Thread.sleep(500); robot.keyPress(KeyEvent.VK_ENTER); Thread.sleep(500); // ❌ 缺少对应的 keyRelease()！
此处仅按下了 Ctrl 和 Enter，却未调用 robot.keyRelease(KeyEvent.VK_CONTROL) 和 robot.keyRelease(KeyEvent.VK_ENTER)。由于 Ctrl 键处于持续按下状态，系统将把后续所有单字母按键（如 S）识别为 Ctrl+S（保存），F 变成 Ctrl+F（查找），P 变成 Ctrl+P（打印）——这完美解释了你在记事本或资源管理器中观察到的“随机弹窗”现象。
✅ 正确做法是：每个 keyPress() 必须有且仅有一个严格配对的 keyRelease()，且释放顺序建议与按下顺序相反（尤其涉及修饰键时）。以下是修复后的关键代码段：
// ✅ 正确：粘贴路径（Ctrl+V） robot.keyPress(KeyEvent.VK_CONTROL); robot.keyPress(KeyEvent.VK_V); robot.keyRelease(KeyEvent.VK_V); // 先释放 V robot.keyRelease(KeyEvent.VK_CONTROL); // 再释放 Ctrl Thread.sleep(300); // ✅ 正确：确认文件选择（通常为 Enter；部分系统需 Alt+O 或 Tab+Enter，但此处假设标准回车） robot.keyPress(KeyEvent.VK_ENTER); robot.keyRelease(KeyEvent.VK_ENTER);
⚠️ 额外重要注意事项：
- 避免硬编码 Thread.sleep()：延迟不稳定，易因系统负载失败。应结合 AutoIt、SikuliX 或更可靠的 UI 自动化工具（如 Windows 下使用 Windows Desktop API 封装的 WinAppDriver）替代纯 Robot 方案。
- Robot 是系统级操作，无沙箱隔离：一旦出错（如异常中断），极易遗留按键状态。务必在 finally 块中强制释放所有已按下的修饰键（如 Ctrl、Shift、Alt），或在测试套件 @AfterSuite 中重置键盘状态。
- 跨平台风险高：VK_ENTER 在 macOS 上可能需替换为 VK_RETURN，Linux 桌面环境行为也可能不同。生产环境强烈建议弃用 Robot 实现文件上传，转而采用 元素的 sendKeys(absoluteFilePath)（需确保元素可交互）或服务端预上传 + 接口注入方式。
总结：Robot 不是“黑魔法”，而是裸金属输入模拟器——它不理解应用逻辑，只忠实地发送按键事件。尊重其规则（压即释、顺序严谨、异常兜底），才能避免让测试用例变成系统键盘的“永久劫持者”。
