移动端 input[type="file"] 点击失效是因浏览器系统层拦截，需同时满足用户真实点击、元素未隐藏且未被遮挡三个硬性条件；accept 和 capture 属性决定唤起何种系统界面，ios 与安卓解析逻辑差异大，必须真机测试验证。
移动端 input[type="file"] 不是“写对了就一定能用”，而是浏览器在系统层主动拦截——只要不满足三个硬性条件，点击就静默失效，连错误都不抛。
为什么真机上点不动 input[type="file"]
根本不是 JS 逻辑错，而是 iOS Safari 和多数安卓 WebView 强制要求：必须用户真实点击（不能 setTimeout(() => input.click(), 100)）、input 不能被 display: none 或 visibility: hidden 隐藏、也不能被其他元素遮挡（哪怕 opacity: 0 + pointer-events: none 在父层也会穿透失败）。
-
label包裹input时，若label加了z-index: -1，点击会穿透到下层，input实际没收到事件 - React/Vue 中用
ref拿到 DOM 后调用.click()，在 Android Chrome 80+ 会被静默拒绝 - iOS 微信内嵌 WebView 会无视
capture="user"，强制跳转拍照界面，哪怕你写了accept="image/*"
accept 和 capture 在 iOS/Android 上行为完全不同
这两个属性不是“锦上添花”，而是决定能否唤起正确系统界面的开关。iOS 和安卓对它们的解析逻辑差异极大，靠猜会踩坑。
- iOS Safari：漏写
accept="image/*"，相册根本不会弹；写accept="video/*"会直接进录像模式，要选相册里的视频得写accept="image/*,video/*" - Android：微信 X5 内核会忽略
capture="environment"，fallback 到通用文件选择器；accept=".pdf,.xlsx"比accept="application/pdf"更可靠，因为底层匹配依赖扩展名而非 MIME - iOS 14 及以下：
multiple对 PDF 等非图片类型基本无效；iOS 15+ 才真正支持文档类多选
拿到的 File 对象在移动端极不可信
你看到的 file.type 常是空字符串或 application/octet-stream，尤其从微信转发、邮件附件来的文件；file.size 是唯一可参考字段，但 iOS Safari 对超限文件（如 >100MB）会静默截断，file.size 还返回原始值，实际上传内容已损坏。
- 别用
file.name.split('.').pop()提取后缀——Windows 用户关了“显示扩展名”，file.name可能是report（实际是report.docx），后缀为空 -
URL.createObjectURL()在 iOS Safari 14.5+ 预览大图容易内存泄漏、滚动卡顿，改用<img src="blob:...">更稳 - 某些国产安卓 WebView（如 QQ 浏览器）对
multiple+accept组合支持极差，降级方案是去掉accept，纯靠后端校验 + 前端提示
HTML 层能做的最小必要设计
input[type="file"] 本身不参与切片、不控制上传逻辑，它的唯一任务是把用户选中的原始 File 实例交到 JS 手里。HTML 层只需确保这个交接不出错。
- 必须设
id或用框架ref，否则 JS 拿不到元素，例如：<input id="upload-input" type="file"> - 允许多选就加
multiple，但 JS 需遍历event.target.files数组，每个File单独调用slice() - 不要给
input赋value—— 浏览器禁止 JS 写入，会报错或被忽略 - 禁用默认表单提交，否则页面刷新导致切片中断；切片上传通常不用
<form enctype="multipart/form-data"></form>，但 fetch 时要让浏览器自动设Content-Type
真机测试不是可选项，是必选项。模拟器和 Chrome DevTools 的 Device Mode 完全无法覆盖 iOS Safari 的内存限制、微信 WebView 的 capture 强制跳转、QQ 浏览器对 multiple+accept 的丢弃等真实场景。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
