应使用自定义模态框替代 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()，用户点按钮毫无反应，还以为功能坏了。

HTML Text Extract

从HTML页面（URL、文件或标准输入）中提取主体内容文本，去除导航、页脚、广告和模板文本。可直接传递给readability_check或其他文本工具。

下载

• 不要依赖 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），而非物理删除

事情说清了就结束。最常被跳过的其实是后端校验那步——前端弹得再醒目，删库跑路还是发生在服务端。