accept="application/pdf,.pdf"是唯一稳配方案，需同时指定MIME类型和扩展名且逗号后不能有空格；前端校验须结合文件名后缀与PDF魔数%PDF，后端必须通过二进制头验证。
accept="application/pdf,.pdf" 是唯一稳配方案
单写 accept=".pdf" 或 accept="application/pdf" 都会掉坑：iOS Safari 可能完全不显示 PDF 文件，安卓 WebView 常忽略扩展名，Windows 某些环境下上报的是 application/x-pdf 而非标准值。必须 MIME 类型 + 扩展名双写，且逗号后不能有空格。
-
accept="application/pdf,.pdf"✅ 同时覆盖 Safari、Chrome、Edge、主流安卓 WebView -
accept="application/x-pdf,.pdf"❌application/x-pdf不是标准 MIME，部分浏览器不认 -
accept="application/pdf , .pdf"❌ 逗号后带空格 → 旧版 Safari 直接丢弃整个属性 - 别用
accept="application/pdf,application/x-pdf,.pdf"—— 多余且增加解析失败风险
为什么写了 accept 却还是选不出 PDF 文件
这不是代码写错，而是浏览器和系统层面对 accept 的实现差异导致的：
- macOS Finder 对扩展名匹配极弱，只依赖 MIME，
.pdf几乎无效 - 某些 PDF 文件实际被系统识别为
application/x-pdf或空字符串，accept不做模糊匹配 - 自定义上传组件（如 Element Plus 的
el-upload）可能没把accept透传给底层原生<input type="file">，要用 DevTools 检查 DOM 中是否真渲染了带该属性的input - iOS Safari 对
accept="application/*"类通配写法基本无视，必须显式列出具体类型
前端 JS 校验必须做，且不能信 file.type
file.type 是浏览器推测值，可为空、可伪造——把 malware.exe 改名成 report.pdf，file.type 就可能变成 application/pdf，但内容仍是可执行文件。
- 优先用
file.name.toLowerCase().endsWith('.pdf')判断扩展名（注意大小写） - 更高安全要求时，用
FileReader读前 4 字节校验 magic number：%PDF（十六进制25 50 44 46） - 设了
multiple后，event.target.files里可能混着合法与非法文件，必须遍历每一项，不能只检查第一个 - 提示要具体：“已选 1 个不支持的文件（invoice.docx）”，而不是笼统弹“文件类型错误”
后端才是唯一可信防线，且必须看文件头
所有前端限制都可被绕过：curl、Postman、DevTools 修改 DOM、拖拽 Drop 区域……服务端收到的 Content-Type 请求头、req.file.mimetype（Node.js）、$_FILES['file']['type']（PHP）全不可信。
立即学习“前端免费学习笔记（深入）”；
- 必须读取文件二进制流前几个字节（magic bytes）：
%PDF是 PDF 的唯一可信标识 - 推荐库：
file-type（Node.js）、python-magic（Python）、Apache Tika（Java） - 扩展名只是辅助，不能作为判断依据；验证通过后建议重命名保存，剥离原始扩展名，由服务端附加安全后缀
- 尤其警惕
.html、.js、.php等可执行类扩展名，即使 MIME 看似合法也应拒绝或隔离存储
真正麻烦的从来不是怎么写 accept，而是忘了它根本不是过滤器——它只是个提示框筛选器，连“门禁卡”都算不上，顶多算门口贴张告示。
