accept 属性仅优化文件选择体验，不提供安全校验；真正有效的文件类型校验必须由后端通过 content-type 和文件头（magic bytes）完成，前端需配合扩展名正则和多端真机测试。
accept 属性只过滤文件选择器，不校验上传内容
浏览器的 accept 属性根本不会阻止用户上传“不符合类型”的文件——它只是告诉文件选择对话框默认显示哪些后缀。用户点开下拉菜单、手动选“All Files”，或者拖拽一个 .exe 进来，照样能通过。
常见错误现象：表单提交后后端报错“不支持的文件类型”，但前端明明写了 accept="image/*"；或者用户上传了 .jpg，但实际是伪造的 HTML 文件（MIME 类型为 text/html），accept 完全不拦。
- 真正起作用的是后端对
Content-Type和文件头（magic bytes）的校验 -
accept的唯一价值是提升用户体验：减少误选、加快浏览 - 不要用它做安全边界，否则上线当天就会被绕过
accept 值不是 MIME 类型列表，而是类型提示集合
很多人以为写 accept="image/png, image/jpeg" 就能精确匹配，其实浏览器只把它当提示——有些浏览器会忽略 MIME 类型中的参数（如 image/png; charset=utf-8），有些则直接按扩展名回退匹配。
更麻烦的是，同一类文件在不同系统上报的 MIME 类型可能不同：.jpg 在 macOS 可能是 image/jpeg，在 Windows 可能是 image/pjpeg，而 accept 不支持通配符或模糊匹配。
- 优先用类型组，比如
accept="image/*"比罗列多个 MIME 更可靠 - 需要限定具体格式时，配合扩展名：
accept="image/png, .png, .jpg, .jpeg" - 避免只写 MIME（如
accept="application/pdf"），某些安卓 WebView 会完全失效 - 注意逗号后不能有空格：
accept="text/plain, .txt"✅，accept="text/plain , .txt"❌（部分旧版 Safari 拒绝解析）
input[type="file"] 多文件 + accept 组合容易漏掉边界情况
当同时设置 multiple 和 accept，用户仍可能一次选中混合类型文件（比如同时勾选 .pdf 和 .zip）。此时 accept 不会拦截，files 列表里照常出现所有文件——前端需自行遍历过滤。
典型场景：上传证件照要求仅限 .jpg 或 .png，但用户批量选了 10 个文件，其中 2 个是 .psd。
- 必须在
change事件里检查event.target.files每一项的type和name -
file.type不可靠（可能为空或伪造），建议结合file.name.match(/\.(jpg|jpeg|png)$/i) - 若要提前禁用提交按钮，得实时校验并提示：“已选 2 个不支持的文件（xxx.psd, yyy.tif）”
移动端 accept 行为差异大，别信文档写的“标准”
Android Chrome 对 accept="video/*" 会弹出相机和图库两个入口，但部分国产定制系统（如华为 EMUI）直接忽略 accept，只显示图库；iOS Safari 则严格限制：设 accept="audio/*" 后，无法从 iCloud 上传音频，只能用录音功能。
更隐蔽的问题是：微信内置浏览器（X5 内核）会把 accept="image/webp" 当成无效值，降级为全部文件可选。
- 测试时务必真机覆盖 Android（尤其 OPPO/Vivo）、iOS、微信环境
- 对关键业务（如身份证上传），接受
.jpg、.jpeg、.png即可，别加.webp或.heic - 如果必须支持 HEIC，得靠 JS 解码或服务端转码，
accept帮不上忙
accept 是个温柔的提示，不是门禁卡。它没法替你判断文件是不是真的图片，也没法保证用户不拖进来一个压缩包。真正的防线永远在服务端校验和客户端二次检查之间——而多数人只写了第一行 accept 就去喝咖啡了。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
