错误提示必须分层：前端校验即时反馈、服务端响应精准同步、ui状态严格对应；避免静默失败，禁用模糊弹窗，确保用户明确知道“为什么失败”和“怎么改”。
文件上传失败时，用户需要立刻知道“为什么失败”和“怎么改”，而不是看到空白页、静默失败或浏览器默认的模糊弹窗。最有效的错误提示必须分层：前端校验即时反馈 + 服务端响应精准同步 + UI状态严格对应。
input[type="file"] 的 change 事件里别急着报错
很多同学一监听到 change 就调 alert() 或直接加警告类，结果用户点“取消”选文件，input.files.length 是 0，按钮却变红了；或者文件明明合法，只是还没提交，就提前触发了错误态。
- 先判断
input.files.length === 0：说明用户没选或点了取消，此时应重置状态，不设任何错误 - 再检查
file是否存在且满足基础条件（如file.size 、<code>file.type.startsWith("text/html")） - 仅当校验失败时，才设置按钮警告类：
button.classList.add("btn-warning")，并配button.title = "仅支持 HTML 文件" - 不要用
disabled锁死按钮——它会破坏可访问性，也阻断重试路径
服务端返回 4xx 时必须同步更新 UI 状态
前端校验能拦住一部分问题，但真实拒绝往往来自后端：比如文件头不是 text/html、内容含恶意脚本、或服务器磁盘满。这时如果 UI 还停留在“上传中”或“成功”状态，用户就会困惑。
- 在
fetch().then(response => { if (response.status >= 400) { ... } })或catch()中处理错误分支 - 务必先清除可能残留的成功类（如
btn-success），再加btn-warning - 从响应体中提取具体错误信息（如
await response.json()中的message字段），写入button.title或独立提示区 - 网络超时、中断等非 4xx/5xx 场景也应归为“被拒”感知，统一文案：“上传失败，请重试”
用 setCustomValidity() 替换原生表单气泡提示
如果你把 <input type="file"> 放在带 required 的表单里，用户不选文件就点提交，浏览器会弹默认气泡（如“请填写此字段”）。这种提示太泛，无法说明“只接受 HTML”。
- 在
blur或change后手动校验，合法时调input.setCustomValidity("")（注意：必须是空字符串''，null或undefined不生效） - 非法时设具体文案：
input.setCustomValidity("请上传 .html 或 .htm 文件") - 立刻触发显示：
input.reportValidity()—— 这步不能省，否则什么都不会弹 - 避免在
input事件里频繁调用，否则每敲一个字都弹一次
拖拽上传区域要在 dragenter 阶段就提示格式错误
用户把文件拖进上传区，悬停 1 秒后才释放，结果发现类型不符——体验断层。更优做法是在 dragenter 时就解析 e.dataTransfer.items，根据 item.type（如 "text/html"）实时判断并高亮错误区域。
- 监听
dragenter，遍历e.dataTransfer.items，过滤出kind === "file"的项 - 对每个项检查
item.type是否在白名单内（注意：item.type可能为空，需 fallback 到扩展名） - 只要有一个不合规，就给容器加
drag-error类，并显示浮动提示：“仅支持 HTML 文件” -
dragover里只需e.preventDefault()维持拖拽行为，别重复校验 - 离开区域（
dragleave）或释放（drop）后，记得清理状态类
真正麻烦的是跨层状态同步：前端校验、服务端响应、DOM 元素 class、title 属性、焦点管理、屏幕阅读器播报——任何一个环节脱节，错误提示就变成干扰项。别追求“一次写完”，先确保按钮类和错误文案严格跟随服务端响应变化，再逐步补全拖拽、表单、可访问性细节。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
