ios safari等浏览器对accept="image/*"解析过严，导致相册jpg无法选择；应改用精确mime类型与扩展名组合如accept="image/jpeg,image/png,.jpg,.jpeg,.png"，并配合js扩展名+magic bytes校验及后端二进制头校验。
accept="image/*" 为什么选不了相册里的 JPG？
这不是你写错了，是 iOS Safari 和部分安卓 WebView 的设计限制：它们对 image/* 解析过严，可能直接屏蔽相册入口，或把 .heic、.webp 当成“非标准图片”拒之门外。更糟的是，某些系统（如 macOS）会把 .psd、.svg 也归入 image/*，而 SVG 可含脚本，PSD 不是通用图片格式。
真正起作用的写法必须同时包含 MIME 类型和扩展名，且逗号后**不能有空格**：
-
accept="image/jpeg,image/png,image/gif,.jpg,.jpeg,.png,.gif"✅ 覆盖主流格式及大小写变体 -
accept="image/jpeg,image/png,.jpg,.jpeg,.png"✅ 若明确只要 JPG/PNG，不混用通配符 -
accept="image/*,.jpg,.png"❌image/*和扩展名混用，iOS Safari 可能失效 -
accept="image/jpg"❌image/jpg非标准 MIME，应为image/jpeg
选完文件后，JS 怎么做二次校验？
event.target.files 列表里每个 file 对象的 type 属性不可信——重命名过的 hack.html 改成 report.jpg，file.type 就会是 image/jpeg，但内容仍是 HTML。
必须立刻在 change 事件里做两件事：
- 用
file.name.toLowerCase().match(/\.(jpg|jpeg|png|gif)$/i)做扩展名白名单比对 - 对关键业务（如头像上传），加 magic bytes 校验：用
FileReader读前 4 字节，JPG 是\xff\xd8\xff，PNG 是\x89PNG - 若用了
multiple，要遍历整个files数组，不能只检查第一个 - 提示信息要具体：
"已选 1 个不支持的文件（scan.tif）"，而不是笼统报错
后端校验为什么不能只看文件扩展名？
前端所有限制都可被绕过：curl 直传、DevTools 删除 accept、拖拽伪造文件到 Drop 区……服务端收到的 Content-Type 请求头、req.file.mimetype（Node.js）、$_FILES['file']['type']（PHP）全可伪造。
唯一可信的是文件二进制流开头几个字节（magic bytes）：
- PNG 必须以
\x89PNG开头（4 字节） - JPEG 必须以
\xff\xd8\xff开头（至少 3 字节） - 推荐库：Node.js 用
file-type，Python 用python-magic，Java 用Apache Tika - 存储时强制重命名，如
avatar_abc123.jpg，剥离原始文件名
移动端常见失效场景和应对
华为 EMUI、小米 MIUI 的 WebView 常完全忽略 accept；iOS Safari 在某些版本下对 .webp 或 .heic 不识别 MIME；微信内置浏览器甚至会把 image/* 当成“拒绝所有”。
应对策略很实际：
- 不要依赖单个值，坚持 MIME + 扩展名双写，比如
accept="image/webp,.webp,image/avif,.avif" - 如果业务允许，优先用
accept="image/jpeg,image/png,.jpg,.jpeg,.png"，避开争议格式 - 在 JS 校验失败时，明确告诉用户“该文件不是标准图片，请用相机或图库重新选择”，而不是“类型不支持”
- 真要兼容 iOS 相册，
accept="image/*"有时反而比精确列表更管用——但必须配合后端强校验
最常被忽略的一点：accept 从不拦截提交，它只影响文件选择框的初始过滤。任何“限制上传”的想法，本质都是在骗自己。真正的防线只有一条：后端读取文件头并拒绝非图片二进制数据。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
