capture 是布尔属性，需配合 type="file" 和精确 accept 值（如 image/*）才能触发原生设备；iOS Safari 要求 input 静态存在于 DOM、用户手势直触且禁用桌面模式；Android 行为不一，微信 X5 基本不支持；应以 getUserMedia + MediaRecorder 为可靠替代方案。
capture 属性在 input[type="file"] 中的正确写法
直接写 capture 是无效的，必须配合 type="file" 和明确的 accept 类型才能触发原生相机或麦克风。浏览器不会仅凭 capture 就弹出设备选择，它只是个提示性属性，实际行为由 accept 决定。
-
accept="image/*"+capture→ 优先调起后置摄像头（iOS 强制，Android 视系统而定） -
accept="video/*"+capture→ 调起视频录制界面 -
accept="audio/*"+capture→ 调起录音界面（注意：部分 Android 浏览器仍会打开文件选择器而非直接录音） - 单独写
capture="user"或capture="environment"没用——这些值不被任何主流浏览器支持，capture是布尔属性，不接受字符串值
为什么 iOS Safari 点击没反应？
iOS Safari 对 capture 的限制最严：必须是用户手势直接触发（比如 onclick 里调 click() 不算），且不能在 iframe 或非主文档上下文中使用。更关键的是，它拒绝响应通过 JavaScript 动态插入的 input 元素上的 capture。
- 确保
input在页面加载时已存在于 DOM 中，不要用innerHTML或appendChild动态挂载 - 避免封装成组件后在
mounted或useEffect里才渲染 —— iOS 会静默忽略 -
accept必须精确：写accept="image/jpeg"可能失败，应改用accept="image/*" - 真机调试时禁用「请求桌面站点」，否则 Safari 会降级为文件选择器
Android 上 capture 行为不一致的原因
Android 没有统一标准，不同厂商、不同 WebView 内核（Chrome、Samsung Internet、微信 X5）对 capture 的实现差异极大。有些直接跳原生相机，有些弹出“选择应用”对话框，还有些干脆忽略 capture 回退到普通文件选择。
- 微信内置浏览器（X5）基本不支持
capture，即使写了也走文件选择器 - Chrome for Android 8.0+ 支持
accept="audio/*"+capture触发录音，但需 HTTPS 环境 - 若需稳定录音，别依赖
capture，改用navigator.mediaDevices.getUserMedia({ audio: true }) - 测试时务必用真机，模拟器无法反映真实 capture 行为
替代方案：当 capture 不工作时该怎么做
把 capture 当作可选优化，而不是功能核心。真正要保证可用性，得 fallback 到标准 Web API。
立即学习“前端免费学习笔记（深入）”；
- 图像采集：用
getUserMedia拿到MediaStream，再用canvas.captureStream()或HTMLCanvasElement.toBlob()保存 - 录音：用
MediaRecorderAPI，比input[type="file"]+capture更可控、支持暂停/继续/分段 - 上传前校验：拿到 Blob 后检查
type和size，避免用户误选大视频导致上传失败 - 注意权限：
getUserMedia需用户主动授权，首次调用会弹 Permission Prompt，不能自动触发
capture 的价值在于“少一步点击”，但它不是可靠入口。真正的难点从来不是怎么写这个属性，而是怎么优雅地降级到 MediaRecorder 或处理 X5 内核的静默失败。
