应使用自定义模态框替代 confirm()，并严格校验后端权限与设备ID，防止误删。confirm() 在移动端不可靠，且无法替代安全校验；USB操作须将 confirm 放在设备断开前，删除请求需幂等并带短时效 token。
点击按钮时阻止默认移除行为
浏览器不会自动弹出“移除此设备”确认框，所谓“警告”其实是开发者自己用 confirm() 拦截了点击事件。直接绑定 onclick="return confirm('确定要移除此设备？')" 最简单，但容易忽略表单提交或链接跳转的副作用。
- 如果按钮是
<button type="submit"></button>，confirm()返回false会阻止表单提交，但不会阻止后续 JS 执行——得手动加event.preventDefault() - 如果是
<a href="/remove?id=123"></a>，仅靠return confirm(...)不够，必须配合event.preventDefault()+ 手动跳转（确认后才window.location.href = ...） - 现代写法推荐用
addEventListener，避免内联 JS 难维护：document.getElementById('remove-btn').addEventListener('click', function(e) { if (!confirm('确定要移除此设备？')) { e.preventDefault(); } });
避免在 WebUSB 或 navigator.usb 中误触发 confirm
调用 navigator.usb.requestDevice() 或 device.disconnect() 本身不弹窗，但有人把 confirm() 塞进 USB 设备断开回调里，结果用户点“取消”后设备其实已经断开了——因为断开动作在 confirm 之前就执行了。
- 务必把设备操作逻辑放在
confirm()判断之后，而不是之前 -
navigator.usb.getDevices()返回的是已连接设备列表，不等于“当前可移除”，别拿它当设备状态依据 - Chrome 对 USB 设备管理有权限模型，
confirm()无法替代权限提示；用户拒绝权限后，requestDevice()会直接 reject，不是静默失败
移动端 Safari 不支持 confirm 弹窗的替代方案
iOS Safari 在某些上下文（如 PWA 全屏模式、iframe 内）会静默吞掉 confirm()，用户点按钮毫无反应，还以为功能坏了。
- 不要依赖
confirm()做关键确认，改用自定义模态框（div+position: fixed），确保 DOM 可见、可交互 - 自定义弹窗需手动禁用背景滚动：
document.body.style.overflow = 'hidden'，关闭时恢复 - 触控区域要够大，按钮至少
44px高，否则 iOS 会判定为不可点击 - 别用
alert()或prompt()替代，它们在移动端同样不可靠
服务端删除前仍需二次校验
前端 confirm() 只是体验层，不能当安全措施。用户绕过 JS、重复点击、抓包重放，都可能导致误删。
- 后端接口必须校验当前用户是否有权删除该设备 ID，不能只信前端传来的
device_id - 建议加短时效 token（如 30 秒内有效），由前端在 confirm 后请求生成，再带入删除请求
- 删除操作应设为幂等：重复提交同一删除请求，返回 200 或 404，不报错也不重复删
- 真要防手滑，可在数据库加软删除字段（
is_deleted），而非物理删除
事情说清了就结束。最常被跳过的其实是后端校验那步——前端弹得再醒目，删库跑路还是发生在服务端。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
