capture="user" 仅提示优先使用前置摄像头而非强制，实际由浏览器、系统和驱动决定；提高成功率需配合 accept="image/*" 或显式约束 { video: { facingMode: "user" } }。

capture="user" 为什么有时不调前置摄像头

因为 capture="user" 只是提示浏览器「优先使用前置摄像头」，不是强制指令。实际行为由浏览器、操作系统和设备驱动共同决定，尤其在桌面 Chrome 或某些 Android WebView 中，它可能被忽略或 fallback 到默认摄像头。

HTML 中如何提高前置摄像头触发成功率

单纯靠 capture="user" 不够，需配合更明确的约束条件：

• 必须用 <input type="file" accept="image/*" capture="user">，accept 缺失时部分 iOS Safari 会忽略 capture
• 在支持 MediaDevices 的场景下，显式请求前置设备：调用 navigator.mediaDevices.enumerateDevices() 找到 label 含 "front" 或 "user" 的 videoinput 设备，再传入 constraints
• 关键约束写法：{ video: { facingMode: "user" } } —— 这比 capture="user" 更可靠，且被 Chrome、Firefox、Safari（17.4+）支持
• 避免写成 { video: { facingMode: { ideal: "user" } } }：iOS Safari 对 ideal 支持不稳定，直接写字符串值更稳妥

facingMode: "user" 在 getUserMedia 中的实际表现

这是目前最接近「强制」的方案，但仍有边界情况：

anything-to-html

将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。

下载

• 如果设备只有一个摄像头（比如某些平板或旧笔记本），facingMode: "user" 会被静默忽略，返回唯一可用设备
• 部分 Android 厂商定制 ROM（如华为 EMUI、小米 MIUI）会屏蔽 facingMode 请求，始终返回后置——此时只能靠用户手动切换或提示引导
• 在 iframe 中调用需确保 allow="camera" 属性已声明，否则权限拒绝且无提示
• 示例代码片段：

  navigator.mediaDevices.getUserMedia({ video: { facingMode: "user" } })

  失败时 catch 到的错误通常是 OverconstrainedError 或 NotAllowedError，而非设备不存在

真机调试时容易被忽略的兼容细节

开发时在模拟器或桌面测试几乎没意义，真实限制都在终端侧：

立即学习“前端免费学习笔记（深入）”；

• iOS Safari 16.4 之前不支持 facingMode，只认 capture="user"，且仅限 <input>；16.4+ 才支持 JS 层约束
• 微信内置浏览器（X5 内核）完全忽略 facingMode，无论怎么写都走默认摄像头，无绕过方案
• Android Chrome 从 98 版本起要求页面为 HTTPS 且用户有交互（如点击）后才能激活摄像头，否则静默失败
• 不要依赖 MediaStreamTrack.getSettings().facingMode 判断是否生效——它返回的是实际启用的值，但某些机型即使选了 "user" 也返回 undefined

实际能稳定切到前置的组合就两套：表单用 capture="user" + accept；JS 用 getUserMedia + facingMode: "user"。其余都是妥协或兜底。