ios safari 无法真正上传无损文件，因系统强制通过 imageio 将图像转为 srgb、8-bit、压缩 jpeg（质量82–92），heic/raw 元数据全丢失；唯一接近无损的方式是用 web share target 通过原生分享扩展传递原始文件。
iOS Safari 无法真正上传“无损文件”——它会强制压缩图像，这是系统级限制，不是前端能绕过的。 你看到的“原图上传”基本都是错觉，实际传输的是 Safari 自动降质后的 JPEG（即使 accept="image/*" 或选中 HEIC/RAW 文件）。
为什么 iOS Safari 传出来的图总是发灰、模糊、色偏
根本原因在于 WebKit 渲染管线对 input type="file" 的处理逻辑：iOS 15+ 起，Safari 在读取本地图像时会主动调用系统 ImageIO 框架进行解码+重编码，强制转为 sRGB 色域、8-bit、带压缩的 JPEG（质量约 82–92），HEIC/ProRAW/HEIF 全部被丢弃元数据并转码。这不是 bug，是苹果为内存和功耗做的硬性妥协。
- 即使你用
FileReader.readAsArrayBuffer()读取原始字节，拿到的已是 Safari 解码后吐出的 JPEG 数据流，不是原始文件字节 -
event.target.files[0].webkitRelativePath在 iOS 上始终为空，无法溯源原始路径或格式 - 通过
FormData.append('file', file)提交的，就是这个已被 Safari “加工过”的 Blob
唯一能接近无损的实操路径：绕过 Safari 图像处理链
不依赖 input type="file"，改用 iOS 原生分享扩展（Share Sheet）导出原始文件到你的服务端。这需要后端配合，但前端可控制：
- 网页提供一个按钮，文案写“分享原图到本页”，点击后触发
navigator.share({ files: [file] })（需 HTTPS + 用户手势） - 后端部署一个支持 Web Share Target 的 PWA（manifest.json 中声明
"share_target"） - 用户在 iOS Safari 中长按图片 → “分享” → 选择你的网页 → 系统直接传递原始文件（含 HEIC/RAW/EXIF）给你的 service worker
- service worker 接收
event.data.files，用fetch('/upload-raw', { method: 'POST', body: new FormData().append('file', file) })转发至后端 API
注意：navigator.share 在 iOS 16.4+ 才支持 files 字段，且必须是用户主动触发（不能 onload 自动调）。
开发时容易忽略的兼容陷阱
你以为加了 capture="user" 或 accept="image/heic,image/avif" 就能保真？其实完全无效：
-
accept属性在 iOS Safari 中仅影响文件选择器界面的过滤提示，不阻止用户手动切换类型，也不影响后续编码行为 -
capture强制调起相机，但拍完仍走同一套 ImageIO 压缩流程，输出仍是 JPEG - 试图用
canvas.toBlob(callback, 'image/heic', 1.0)—— Safari 不支持 HEIC 编码，会静默 fallback 到 JPEG - 用
URL.createObjectURL(file)显示预览图？显示的是压缩后版本，file.size也已变小
真正要传无损，别在 Safari 里硬刚图像管道。要么引导用户用「文件」App 打开网页链接后分享原始文件，要么接受现实：iOS Web 环境下，“无损上传”本质是个伪命题，能拿到 EXIF 和合理 JPEG 质量（>90%）已是当前上限。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
