移动端 input[type="file"] 失效主因是浏览器安全策略：必须用户真实点击、未隐藏且无遮挡；accept/capture 属性在 ios/android 行为差异大；file 对象的 type 不可靠，size 在 ios 可能虚报；真机测试不可替代。
为什么移动端点击 input[type="file"] 没反应
根本不是代码写错了，而是浏览器主动拒绝触发——iOS Safari 和多数安卓 WebView 要求 input 必须满足三个硬性条件：用户真实点击（非 JS 异步调用）、未被 display: none 或 visibility: hidden 隐藏、且不能被其他元素遮挡（包括 opacity: 0 但父层有 pointer-events: none）。
常见失效场景：setTimeout(() => input.click(), 100) 在 Android Chrome 80+ 会静默忽略；label 包裹了 input 但 label 自身加了 z-index: -1，导致点击穿透失效。
accept 和 capture 在 iOS/Android 上行为不一致
这两个属性不是“可选优化”，而是决定能否唤起正确系统界面的关键开关：
- iOS Safari：漏写
accept="image/*"，连相册都不会弹；写accept="video/*"会强制打开录像界面，要相册视频得用accept="image/*,video/*" - Android：部分 WebView（如微信 X5）会直接忽略
capture="environment"，只 fallback 到文件选择器；accept=".pdf,.xlsx"比accept="application/pdf"更可靠，因为系统匹配逻辑依赖扩展名 - iOS 14 及以下：
multiple对非图片类型（如 PDF）基本无效；iOS 15+ 才真正支持文档类多选
移动端文件对象的 type 和 size 不可信程度远超 PC
你拿到的 File 对象在移动端更“虚”：
-
file.type经常为空字符串或application/octet-stream，尤其拖拽上传或从微信转发过来的文件 -
file.size是唯一可信字段，但 iOS Safari 对超限文件（如 >100MB）会静默截断，file.size返回的仍是原始值，实际上传内容已损坏 - 别用
file.name.split('.').pop()提取后缀——Windows 用户关了“显示扩展名”，file.name可能是report（实际是report.docx），此时后缀为空
真机测试绕不开的三个坑
模拟器和桌面 Chrome 的 Device Mode 完全无法覆盖这些场景：
- iOS Safari 14.5+ 调用
URL.createObjectURL()预览大图，内存泄漏明显，页面滚动卡顿；改用<img src="blob:...">更稳 - 某些国产安卓 WebView（如 QQ 浏览器）对
multiple+accept组合支持极差，降级方案是去掉accept，纯靠后端校验 + 前端提示 - 微信内嵌 WebView 会拦截
capture="user"，强制跳转拍照，哪怕你写了accept="image/*"也没用；必须准备 fallback 按钮：“从相册选择”
input 标签就想通吃所有机型，是移动端文件上传失败最常被低估的根源。前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
