capture属性是HTML5中提示浏览器优先调用原生摄像头的布尔属性，仅在<input type="file">且accept="image/*"或video/*时生效；它非强制指令，实际行为受HTTPS、用户手势触发、iOS PWA限制及浏览器兼容性制约，常 fallback 至文件选择器。
capture 属性在 <input type="file"> 中的实际行为
移动端浏览器（尤其是 Safari 和 Chrome for iOS/Android）对 capture 的支持并不等同于“直接调用摄像头”，它只是一个提示性属性，告诉浏览器“用户大概率想拍张照或录个视频”。是否弹出摄像头、是否跳转原生相机界面、是否允许切换前后镜头，完全取决于浏览器实现和系统权限策略。
常见错误现象：capture 加了但点击后仍弹出文件选择器（含相册、iCloud 等选项），甚至直接报错 NotAllowedError —— 这不是代码写错了，而是缺少 HTTPS、未在用户手势触发上下文中调用、或页面未被添加到主屏幕（iOS Safari 对非 PWA 场景限制更严）。
-
capture必须与type="file"一起使用，单独加在其他标签上无效 - 仅对
accept="image/*"或accept="video/*"生效；accept="*"或未设accept时会被忽略 - iOS Safari 要求页面必须通过 HTTPS 提供，且不能在 iframe 中触发（除非 sandbox 允许）
为什么 capture="user" 和 capture="environment" 经常不生效
这两个值本意是建议浏览器优先使用前置/后置摄像头，但实际兼容性极差：Safari 目前完全忽略该值（无论 user 还是 environment 都默认打开前置）；Chrome Android 部分版本支持 capture="user"，但 capture="environment" 多数情况下 fallback 到前置或让用户手动切换。
真正起作用的是 accept 类型 + 用户操作路径，而不是 capture 值本身。例如：
立即学习“前端免费学习笔记（深入）”；
<input type="file" accept="image/*" capture="environment">
在多数安卓机上可能打开后置，但在 iPhone 上基本无效 —— 它依然走系统相册/相机统一入口，且默认前置。
- 不要依赖
capture="environment"实现“强制后置”，它不是强制指令 - 若需明确控制镜头，必须用
MediaDevices.getUserMedia()+<video>自建预览流 -
capture是 HTML5 表单级快捷方式，不是 WebRTC 替代品
在用户点击瞬间触发摄像头的最小可行条件
要让 <input type="file" capture> 在移动端点一下就进相机（而非先选来源），必须同时满足以下条件：
- 页面运行在 HTTPS 协议下（HTTP localhost 除外，但真机测试必须 HTTPS）
- 触发
click()必须发生在用户真实手势事件回调中（如button.addEventListener('click', ...)），不能由setTimeout或 Promise resolve 后调用 - input 元素不能被
display: none或visibility: hidden隐藏；可用position: absolute; left: -9999px移出视口但保持可交互 - iOS Safari 要求页面已添加到主屏幕（即“添加到主屏幕”后的 PWA 模式），否则即使满足以上也大概率 fallback 到文件选择器
一个典型可靠写法：
<button id="takePhoto">拍照</button><br><input type="file" id="cameraInput" accept="image/*" capture style="position: absolute; left: -9999px">
document.getElementById('takePhoto').addEventListener('click', () => {<br> document.getElementById('cameraInput').click();<br>});
替代方案：用 getUserMedia() 手动控制摄像头更可控
如果业务需要实时预览、镜像控制、分辨率设置、前后镜头切换、或避免跳转原生界面，capture 就不该是首选。此时应放弃表单方案，改用 MediaDevices.getUserMedia() + <video> + <canvas>。
关键点：
-
getUserMedia({ video: true, facingMode: "environment" })在支持设备上能真正请求后置镜头 - 必须在用户手势（如 click）中首次调用，否则会因权限策略被拒绝
- 需处理
NotAllowedError（用户拒权）、NotFoundError（无摄像头）、NotReadableError（被占用）等异常 - 安卓部分 WebView（如微信内置）不支持
facingMode，需 fallback 到枚举enumerateDevices()并手动匹配 label
简单判断是否该切方案：只要需求里出现“实时预览”“自定义按钮”“镜像开关”“多帧截图”，就别碰 capture 了。
真正难的不是写几行 getUserMedia()，而是处理不同机型、不同 WebView、不同系统版本下的设备枚举差异和权限兜底逻辑 —— 这些细节往往在真机连测阶段才暴露。
