capture属性仅为浏览器向操作系统发出的提示，非硬件指令，不直接调用camera hal或mediarecorder api，其生效依赖https、静态dom、用户手势及accept="image/*"等严格条件，跨平台行为差异大，实际控制需依赖getusermedia。
capture 属性不是硬件指令，而是浏览器向 OS 的提示
它不直接调用 Camera HAL 或 MediaRecorder API，而是由浏览器解析后，通过系统 Intent（Android）或 UIImagePickerController（iOS）传递一个“建议采集类型”的参数。最终是否走摄像头、走相册、甚至弹出选择框，完全由 OS 原生组件决定——capture 本身没有权限、不触发设备初始化、也不参与帧采集。
这意味着：即使你写了 capture="environment"，Android 上某些厂商 ROM（如华为 EMUI、小米 MIUI）可能仍会先弹“用哪个应用打开”，而 iOS Safari 则直接忽略该值，只把 accept="image/*" 当作“允许拍照”，再交由系统 UI 统一呈现「拍摄」和「从相册选取」两个选项。
为什么真机上 capture 常静默失效
失效不是 bug，是浏览器主动降级的结果。以下任一条件不满足，capture 就会被跳过：
-
https://缺失（HTTP 页面在 iOS 16.4+ 和 Chrome 90+ 中直接禁用媒体设备访问） -
input元素未在页面初始 HTML 中存在（iOS Safari 拒绝动态插入的带capture的input） - 触发
.click()不在用户手势上下文内（例如在setTimeout、Promise.then或scroll回调里调用） -
accept值太窄或含参数（如accept="image/jpeg"在 iOS 上被拒，必须用accept="image/*"） - WebView 内核不支持（微信 X5、QQ 浏览器、部分 Android 系统 WebView 直接忽略
capture）
capture="user" 和 capture="environment" 的实际效果差异
这两个是 W3C 唯一认可的字符串值，但跨平台表现极不一致：
-
capture="user"：iOS Safari 默认行为，Android 多数认；但无法保证前置——部分三星设备仍开后置 -
capture="environment"：Android Chrome 84+ 支持较好，iOS Safari 16.4+ 才开始识别（且仅 HTTPS 下生效） - 不写值（
capture）：iOS 等价于capture="user"，Android 行为因版本而异，旧版可能完全不响应 -
capture="camera"：非标准值，已被 Chrome 和 Safari 废弃，写等于白写
真正可控的替代方案是 getUserMedia
如果业务需要实时预览、镜头切换、自定义 UI 或连续拍摄，capture 必须放弃。用 navigator.mediaDevices.getUserMedia() 才能拿到原始视频流：
- 它绕过系统文件选择器，直接请求硬件访问权限
- 可精确指定
{ video: { facingMode: "environment" } }控制前后置 - 需手动处理权限拒绝、设备不可用、HTTPS 限制等边界情况
- 微信内置浏览器（iOS WKWebView）支持度尚可，但 Android X5 WebView 对
getUserMedia支持残缺，需 fallback 到input+capture
硬件层适配这件事，从来不是靠一个 HTML 属性就能解决的——它卡在浏览器实现、OS 组件、WebView 内核、权限模型四层之间，漏掉任何一层，capture 都只是个安静的装饰符。
