capture属性仅是向浏览器提示优先调起摄像头或相册的弱建议，实际行为取决于浏览器和系统策略；iOS Safari完全忽略其值，Android Chrome部分支持；必须配合accept使用，否则极易失效。
capture属性在input[type="file"]中的实际作用
capture 不是独立功能开关，它只是给浏览器一个提示：优先调起原生摄像头或相册。是否生效、调起哪个、能否多选，完全取决于浏览器实现和系统权限策略。Chrome for Android 通常响应 capture="environment"，iOS Safari 则基本忽略所有 capture 值，直接弹出系统选择器（拍照/视频/相册）。
常见错误现象：capture="user" 在 iOS 上不强制前置摄像头；capture 单独写不带值，在部分旧版 Android 中可能被忽略；设了 capture 但没加 accept，用户仍可能选到非媒体文件。
实操建议：
-
accept必须明确限定类型，比如accept="image/*"或accept="video/*"，否则capture失效概率极高 - 移动端真机测试必不可少，模拟器无法触发真实摄像头流
- 不要依赖
capture实现“仅拍照”，它不提供控制权，只提供建议
不同 capture 值在各平台的行为差异
capture 合法值只有 "user"、"environment" 和空字符串（即 capture），没有 "camera" 或 "photo" 这类写法。
典型表现：
-
capture="user"：Android Chrome 倾向调起前置摄像头；iOS Safari 无视该值，仍弹系统选择器 -
capture="environment"：Android Chrome 可能调起后置摄像头；iOS Safari 同样无视 -
capture（无值）：部分 Android 浏览器等同于capture="user"，但行为不稳定
关键点：iOS 所有版本均不按 capture 值区分前后置，也不跳过相册选项。所谓“调起摄像头”其实是用户在系统弹窗里手动点了“拍摄”——这不是 capture 控制的，而是系统 UI 的默认逻辑。
立即学习“前端免费学习笔记（深入）”；
为什么加了 capture 还是打开相册？
这不是 bug，是预期行为。只要 accept 包含 image/*，且设备支持拍照，系统弹窗就会同时提供“拍照”和“从相册选取”两个入口。这是 iOS 和新版 Android 的统一设计，capture 无法禁用相册选项。
如果你需要真正绕过相册、直连摄像头，必须放弃 input[type="file"]，改用 MediaDevices.getUserMedia() + canvas 捕获帧。但这带来新问题：
- 需要显式请求
camera权限，用户可能拒绝 - 无法直接获取照片 EXIF（如方向、时间），需手动解析
- 安卓某些 WebView（如微信内嵌）对
getUserMedia支持不全或需 HTTPS
推荐写法与兼容性兜底策略
最稳妥的写法是组合使用，兼顾可访问性和降级能力：
<input type="file"
accept="image/*"
capture="environment"
onchange="handleFile(this.files)">
但必须配套做两件事：
- 监听
change事件后检查files[0].type，过滤掉非图像类型（比如用户硬选了 PDF） - 在
handleFile中判断是否为拍摄所得：可通过files[0].webkitRelativePath是否为空、或files[0].name是否含时间戳特征粗略推测，但不可靠 - 若业务强依赖“现场拍摄”，应在 UI 层明确提示“请使用上方‘拍照’按钮”，并在按钮点击时尝试
getUserMedia，失败则 fallback 到 file input
capture 是个弱提示，不是开关。它的价值在于减少一次点击，而不是保证行为一致。真正要稳控流程，得跳出这个属性，用更底层的 API 配合业务逻辑来兜底。 
