<input type="file"> 是唯一原生可靠支持图片选择的 HTML 元素，核心功能为触发选择、读取文件、预览显示；accept="image/*" 仅作 UI 过滤，必须结合 file.type.startsWith('image/') 等二次校验，且预览应优先使用 URL.createObjectURL() 避免内存泄漏。
input type="file" 是唯一可靠、原生支持图片选择的 HTML 元素，其他所谓“图片选择器”都是基于它封装的 UI 层。别被“gallery 组件”“保姆级教程”误导——核心就三件事：触发选择、读取文件、显示预览。
为什么不用自定义点击事件模拟 click() 调用 input
很多人试图用 div 或 button 拦截点击、再手动调用隐藏 input 的 click() 方法，这看似灵活，但实际踩坑不断：
- 移动端 Safari（iOS 16+）会静默拒绝非用户直接触发的
click()，页面没反应，控制台也不报错 - Chrome 120+ 对
input.click()的调用链做了更严格判定，如果上层事件不是pointerdown或touchstart直接触发，可能被拦截 - 无障碍（a11y）支持极差：屏幕阅读器无法识别“可点击但无语义”的按钮，
label关联才是正确解法
正确做法是用 <label for="xxx"> 包裹按钮，for 指向 id 一致的 input，这样既保留语义，又无需 JS 触发。
accept="image/*" 不等于只传图片，必须二次校验 file.type
accept 只是浏览器 UI 层过滤，用户仍可通过修改文件后缀、拖拽或开发者工具绕过。比如选中一个 .txt 文件但重命名为 test.jpg，file.type 会是空字符串或 text/plain，而非 image/jpeg。
- 判断逻辑应为：
file.type.startsWith('image/')，而不是=== 'image/jpeg'—— PNG、WebP、AVIF 都要兼容 - 对
file.type === ''的情况，可 fallback 到检查文件头（如前 4 字节是否为FF D8 FF），但多数场景只需提示“请选择有效图片”即可 - 移动端 Android Chrome 常把 HEIC 格式识别为
application/octet-stream，需额外判断扩展名.heic或.heif
预览大图时别直接用 FileReader.readAsDataURL()
readAsDataURL() 会把整个文件转成 base64 字符串塞进内存，选中一张 10MB 的 PNG，JS 堆内存立刻多出 ~13MB（base64 膨胀约 33%），滚动卡顿、GC 频繁，低端安卓机极易 OOM。
立即学习“前端免费学习笔记（深入）”；
- 优先用
URL.createObjectURL(file)，返回一个临时 blob URL，不复制二进制数据，内存占用几乎为零 - 记得在不需要时调用
URL.revokeObjectURL(url)，否则 blob 引用一直存在，造成内存泄漏 -
createObjectURL在 iOS Safari 上对某些 WebP/HEIC 支持不稳定，此时再 fallback 到FileReader - 如果后续还要上传，服务端通常不认 blob URL，所以 preview 和 upload 用两套路径：preview 用 blob URL，upload 仍传原始
File对象
多图选择时 files 是 FileList，不是数组
event.target.files 返回的是只读的 FileList 类数组对象，不能直接用 map、filter 等数组方法，强行展开（[...files]）在旧版 Safari（≤15.6）会崩溃。
- 安全遍历方式是
for (let i = 0; i - 需要数组能力时，用
Array.from(files)，它在所有现代浏览器中都稳定 - 注意
FileList没有forEach，写files.forEach(...)会直接报TypeError - 如果用了
multiple，别假设用户一定选了多张——files.length可能为 0（取消选择）或 1（单选），逻辑要兜底
input type="file" 在 iOS 微信、Android QQ、鸿蒙系统浏览器里都不掉链子。每个平台对 accept、capture、webkitdirectory 的支持程度和 bug 表现都不同，上线前务必真机覆盖测试。 
