accept属性仅提供前端提示和系统级筛选，无法阻止用户绕过限制，必须配合后端校验；其值支持mime类型或扩展名，推荐双保险写法如"image/jpeg,image/png,.jpg,.png"，ios等平台支持薄弱，不可依赖。
accept 属性只过滤文件选择框，不校验上传行为
浏览器的 accept 属性只是给 <input type="file"> 提供一个前端提示和系统级筛选（比如 macOS 文件选择器会默认隐藏不匹配的文件），它**完全不阻止用户绕过限制**——例如拖拽非允许类型、用开发者工具删掉 accept、或后端直接接收任意 MIME 类型。真要限制，必须配合后端校验。
常见错误现象：accept=".pdf,.docx" 选不到 Word 文件；accept="image/*" 却能选中 .psd；上传后后端报错“不支持该格式”。
-
accept值是 MIME 类型或扩展名，但浏览器实现差异大：Chrome 对扩展名支持较好，Safari 更依赖 MIME 类型 - 扩展名写法必须带点，如
.jpg，不能写jpg - MIME 类型优先推荐标准值，如
image/jpeg而非image/jpg（后者不规范） - 多个值用逗号分隔，不要空格：
accept="image/png,image/jpeg,.pdf"
常用 accept 值怎么写才靠谱
别靠猜，按实际需要组合 MIME 和扩展名双保险。比如只要 JPG/PNG，写成：accept="image/jpeg,image/png,.jpg,.png"；只要 PDF 和 Word（.docx），写成：accept="application/pdf,application/vnd.openxmlformats-officedocument.wordprocessingml.document,.pdf,.docx"。
注意几个坑：
-
accept="image/*"看似方便，但会放行image/vnd.adobe.photoshop（.psd）、image/x-icon（.ico）等非预期格式 -
accept=".xlsx"在部分浏览器里无效，必须加上对应 MIME：application/vnd.openxmlformats-officedocument.spreadsheetml.sheet - 纯文本类建议显式列出：
accept="text/plain,.txt,.md,.log"，避免text/*匹配到text/html
accept 和 FormData 上传时的 MIME 不一致怎么办
用户选中文件后，File 对象的 type 字段由浏览器根据文件头或扩展名推测，可能为空或不准。比如重命名 report.pdf 为 report.jpg，再选中，file.type 可能变成 image/jpeg，但实际内容仍是 PDF。
所以不能依赖 file.type 做判断，更不能只靠 accept 就认为“安全”。如果要做前端二次校验：
- 读取文件前几百字节，检查 magic number（如 PDF 是
%PDF，PNG 是\x89PNG） - 用
FileReader+ArrayBuffer做轻量解析，比全量读取快 - 对关键业务（如合同上传），跳过前端 MIME 校验，直接交由后端解析并返回明确错误
移动端 iOS 的 accept 行为特别容易翻车
iOS Safari 对 accept 支持极弱。设 accept="image/*"，相册里仍能选视频；设 accept=".pdf"，文件 App 里点开 PDF 却可能直接预览而不触发 input change。这不是 bug，是系统级限制。
应对策略很实在：
- 在 iOS 上放弃依赖
accept过滤，改用「上传后立刻读取并提示格式错误」的交互 - 用
capture属性辅助场景限定，如<input accept="image/*" capture="camera">强制调起相机 - 若需严格控制，考虑用原生 SDK 或 WebView 容器接管文件选择逻辑
真正卡住上传类型的，从来不是 accept 属性本身，而是没意识到它连“门禁刷卡器”都算不上——顶多是个贴在门口的温馨提示。
