accept 属性仅作为系统文件选择器的提示而非强制过滤，macos、windows、ios 和安卓 webview 中表现各异且常失效，后端校验是唯一可靠防线。
accept 属性在 macOS 文件选择器里为什么只显示部分文件
它只影响系统原生对话框的默认筛选逻辑，不改变底层行为。macOS 的 Finder 弹窗会根据 accept 值自动折叠非匹配类型——比如 accept="image/*" 会让 .txt、.exe、.log 默认不可见；但用户点一下“所有文件”下拉菜单，立刻就能看到并选中任意后缀。这不是 bug，是设计使然：浏览器把 accept 当作 hint 传给系统 API，而 macOS 将其解释为“建议过滤”，不是强制拦截。
常见误判是写了 accept="image/jpeg,image/png" 却发现 .jpg 文件没出现。原因通常是 MIME 类型不被 macOS 正确识别（例如某些旧版系统将 .jpg 报为 image/pjpeg），而该值不在你的 accept 列表中。解决方法不是加更多 MIME，而是补上扩展名：accept="image/jpeg,image/png,.jpg,.png"。
Windows 上 accept=".pdf" 为什么有时失效
Windows 文件选择器对扩展名的支持比 MIME 更稳定，但仍有两个关键限制：
- 扩展名必须带前导点号，
.pdf✅，pdf❌ - 多个值之间**不能有空格**：
accept=".pdf,.docx"✅，accept=".pdf , .docx"❌（IE/Edge Legacy 会直接忽略整个属性）
更隐蔽的问题是：某些企业环境启用了组策略禁用扩展名过滤，此时无论怎么写 accept，系统对话框都会显示全部文件。这种情况下，前端 JS 校验和后端校验就成为唯一防线。
iOS Safari 对 accept="video/*" 的特殊处理
iOS Safari 不是简单地“支持”或“不支持”通配符，而是主动干预选择入口。当你写 accept="video/*"，它可能直接禁用相册、iCloud Drive 等非摄像头来源的选项，只留下“拍摄视频”按钮——这会让用户根本无法从图库上传已存视频。
正确做法是显式列出常用格式：accept="video/mp4,video/quicktime"。注意 video/quicktime 对 .mov 文件更可靠，而 video/mp4 覆盖大部分 H.264 编码的 .mp4 文件。别依赖 video/*，它在 iOS 上既不稳定，也不符合实际使用路径。
安卓 WebView 中 accept 属性经常被忽略
大量安卓 App 内嵌的 WebView（尤其是基于旧版 Chromium 或定制内核的）会完全忽略 accept 属性。你写的 accept="application/pdf" 在 Chrome for Android 上生效，但在某银行 App 的 WebView 里可能毫无反应。
这不是配置错误，是 WebView 实现缺失。验证方式很简单：用 DevTools 连接该 WebView，检查渲染出的 <input type="file"> 元素是否真含有 accept 属性；如果没有，说明封装层（如 React Native 的 WebView 组件或 Flutter 的 webview_flutter）压根没透传该 prop。
此时只能靠 JS 补位：监听 change 事件，遍历 event.target.files，用 file.name.toLowerCase().endsWith('.pdf') 快速过滤，并清空非法项——别指望系统级筛选。
真正容易被忽略的点是：accept 属性的跨平台表现差异，不是“偶尔不准”，而是“在特定环境里彻底失效”。它从来不是一道门，只是个指向正确房间的箭头；箭头歪了，人还是会走进隔壁房间——所以后端校验不是备选方案，是唯一落锁的方式。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
