capture="user" 仅提示优先使用前置摄像头而非强制，实际由浏览器、系统和驱动决定；提高成功率需配合 accept="image/*" 或显式约束 { video: { facingmode: "user" } }。
capture="user" 为什么有时不调前置摄像头
因为 capture="user" 只是提示浏览器「优先使用前置摄像头」，不是强制指令。实际行为由浏览器、操作系统和设备驱动共同决定，尤其在桌面 Chrome 或某些 Android WebView 中，它可能被忽略或 fallback 到默认摄像头。
HTML 中如何提高前置摄像头触发成功率
单纯靠 capture="user" 不够，需配合更明确的约束条件：
html-to-pptx-converter
下载
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
- 必须用
<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 中的实际表现
这是目前最接近「强制」的方案，但仍有边界情况：
- 如果设备只有一个摄像头（比如某些平板或旧笔记本），
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"。其余都是妥协或兜底。前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
