应监听 change 事件在用户选文件后确认，而非拦截 click；若取消则清空 value；更可靠的做法是分离选择与上传，用自定义模态框在点击上传按钮时二次确认，并禁用按钮防重复提交。
点击上传按钮后如何拦截并确认用户意图
浏览器原生的 <input type="file"> 不支持直接拦截点击事件来弹出确认框，因为文件选择对话框由系统触发，JavaScript 无法在它弹出前介入。必须换思路：不阻止原生行为，而是把“确认”逻辑放在用户选完文件之后、真正提交之前。
常见错误是试图给 input[type="file"] 绑定 click 事件并调用 confirm()，这会导致确认框在系统对话框之前出现，但用户点“取消”也无法阻止文件选择器弹出——它已经触发了。
- 正确做法：监听
change事件，在用户选中文件后立刻询问确认 - 若用户点“取消”，清空
input.files并重置input.value（否则下次点击不会再次触发change） - 注意：Safari 对
input.value = ''的兼容性较好；Chrome/Firefox 也支持，但不要用input.type = 'text'; input.type = 'file'这类 hack 方式重置
document.getElementById('upload').addEventListener('change', function(e) {
if (e.target.files.length === 0) return;
if (!confirm('确定要上传 ' + e.target.files[0].name + ' 吗？')) {
e.target.value = ''; // 清空输入值，重置状态
}
});
使用 FormData 提交前二次确认更可靠
如果上传逻辑是通过 fetch 或 XMLHttpRequest 手动构造请求，把确认环节放在提交前比在 change 时更可控——避免用户误选又取消导致 UI 状态混乱。
这种场景下，change 只负责记录文件，真正触发确认的是后续的“上传”按钮（比如一个独立的 <button></button>），而非文件输入框本身。
- 分离关注点：文件选择 ≠ 文件上传，用户可能选错再换，不应每次选都弹确认
- 确认时可展示更多上下文，比如文件大小：
(e.target.files[0].size / 1024).toFixed(1) + ' KB' - 若用
FormData.append()构造数据，确认后再 append，避免提前持有引用却未发送
移动端 Safari 的 confirm() 弹窗会被静默拦截
iOS Safari 在非用户手势（如异步回调）中调用 confirm() 会失败或无响应，而 change 事件虽由点击触发，但部分版本仍视为“非直接手势链”。实际测试发现，某些 iOS 版本下 change 中的 confirm() 会卡住或跳过。
稳妥方案是改用自定义模态框（HTML + CSS 实现），确保在用户点击后同步渲染并聚焦确认按钮。哪怕只是简单 <div id="confirm-modal">...</div> 配合 display: block 切换，也能绕过 Safari 的限制。
- 不要依赖
confirm()在 iOS 上的一致表现 - 自定义弹窗需加
tabindex="0"和focus()确保键盘可访问 - 点击“确定”后立即执行上传，避免再次触发文件选择逻辑
防止重复点击上传按钮导致多次请求
确认通过后，如果用户快速连点上传按钮，可能并发发出多个请求。这不是确认逻辑的问题，但常和它一起发生。
最简方案是在提交开始时禁用按钮，并在请求结束（无论成功失败）后恢复。注意：不要只在 then() 里恢复，catch() 也必须处理，否则失败后按钮永远不可点。
- 禁用按钮时最好同时修改
textContent，比如变成“上传中…” - 若用
fetch，记得检查response.ok而非只看是否抛错（HTTP 4xx/5xx 不会 reject） - 上传大文件时，可结合
AbortController支持取消，但确认环节本身不涉及中断逻辑
真正的难点不在“怎么弹窗”，而在于确认时机与文件生命周期的匹配——什么时候该拦、什么时候已晚、哪些环境根本不让拦。把确认塞进 change 看似简单，但在 iOS 和多文件场景下容易漏 case。最稳的路径是：用户选好 → 点上传按钮 → 弹自定义确认 → 点确定 → 发请求 → 请求结束恢复 UI。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
