capture="user" 仅提示浏览器优先使用前置摄像头，不强制生效；实际行为取决于HTTPS环境、设备能力、权限状态及浏览器实现，Chrome/Edge较积极，Safari则常降级为后置或相册。

capture="user" 在表单中到底触发什么行为 capture="user" 本身不“强制调用”前置摄像头，它只是向浏览器声明：**用户期望使用面向用户的摄像头（即通常的前置摄像头）**。实际是否启用、是否可用、是否真用前置，完全取决于浏览器实现、设备能力与当前权限状态。Chrome 和 Edge 在 <input type="file" accept="image/*" capture="user"> 场景下会优先拉起前置摄像头；Safari 则更保守——即使写了 capture="user"，iOS 上仍可能默认打开后置，或直接跳转系统相册（尤其在非 HTTPS 环境或非全屏 WebView 中）。

关键点在于：capture 是提示而非指令，浏览器有权忽略或降级处理。

为什么有时写了 capture="user" 却还是打开后置或相册 常见原因不是代码写错，而是环境或上下文不满足预期条件：

• 页面未通过 HTTPS 提供（Safari 和新版 Chrome 会禁用 capture，降级为普通文件选择）
• 运行在 iOS Safari 的非全屏模式（如嵌入 WKWebView 或 PWA 未添加 apple-mobile-web-app-capable）
• 用户此前拒绝过摄像头权限，且浏览器缓存了该决策（此时不会弹权限请求，直接 fallback）
• accept 值不匹配：例如写成 accept="image/jpeg" 而非 accept="image/*"，部分 Android 浏览器会忽略 capture
• 设备只有一颗摄像头（如某些平板），"user" 和 "environment" 实际指向同一硬件

验证方式：打开开发者工具 → Application → Clear storage → 清除权限数据，再重试；或用 navigator.mediaDevices.enumerateDevices() 查看是否真有 label 含 "front" 的 videoinput 设备。

如何提高 capture="user" 的实际命中率 这不是加个属性就能一劳永逸的事，得配合运行时判断和降级策略：

• 始终搭配 accept="image/*"（不要限定具体 MIME 类型），避免被 UA 拒绝解析 capture
• 在 change 事件前，用 MediaStreamTrack.getSettings() 检查实际使用的设备 ID 是否匹配已知前置设备（需先 enumerateDevices 缓存 deviceID）
• 对 iOS Safari，可尝试添加 webkit-playsinline + autoplay 的隐藏 <video> 并调用 getUserMedia({video: {facingMode: "user"}}) 预热权限（注意：这会触发权限弹窗，需用户交互后才允许）
• 服务端不要假设“拍了就是前置”——图像 EXIF 中的 Orientation 或镜像特征（如人脸朝向）才是更可靠的判断依据

示例降级逻辑：

input.addEventListener('change', async (e) => {
  if (!e.target.files.length) return;
  const file = e.target.files[0];
  // 若是直接拍照所得，type 通常为 'image/jpeg'，且 size 明显大于 50KB
  // 但不能仅凭此断定是前置——后置拍的也一样
});

capture="user" 和 getUserMedia({facingMode: "user"}) 的关系 二者目标一致，但作用层级不同：capture="user" 是 HTML 表单级声明，走的是文件选择器原生流程；getUserMedia 是 JS 媒体流 API，能精细控制轨道、分辨率、帧率，并实时预览。它们**不互斥，但也不自动同步**。

典型陷阱：给 <input capture="user"> 添加 click 事件并同时调用 getUserMedia，结果在部分 Android 机型上导致相机黑屏或崩溃（双通道争抢设备）。正确做法是二选一——要么纯表单流（轻量、兼容好），要么纯 JS 流（可控、可镜像矫正、可加滤镜），不要混用。

真正难的不是写对 capture="user"，而是当它没按预期工作时，你有没有快速定位是权限、协议、UA 还是硬件限制——这些因素在真机测试前几乎无法模拟。