H5拍照功能全解析：从input到getUserMedia的选型与坑位

做移动端 H5 拍照功能很多人一开始以为难点在“怎么调起相机”真上手之后才发现完全不是这么回事。难点在于同一套代码在不同的系统、不同的浏览器、不同的 WebView 里的行为可能完全不一样而且用户拍出来的原图动不动就七八兆直接上传会把服务器和流量一起搞崩。我这两年做过若干个带拍照上传的 H5 项目从最原始的 file input 到 getUserMedia 再到微信 JS-SDK基本把能踩的坑都踩了一遍。这篇就把我实际用到的几种方案、每种方案背后的取舍逻辑、以及我在真机上调试时常遇到的那些问题一次性说清楚。1. 先理清H5 拍照到底有几条技术路径要在移动端 H5 页面里实现拍照目前能用的路径大致有四条。第一条是利用原生表单能力也就是input typefile acceptimage/*让浏览器自己拉起相机或相册。这是最基础、最兼容的方案iOS 和 Android 都支持微信和各类 WebView 里也能用唯一的问题是你对“相机界面”没有任何控制权打开后是系统相机还是相册选择器取决于浏览器和用户操作。第二条是调用navigator.mediaDevices.getUserMedia直接获取摄像头视频流然后渲染到页面里的video标签上再通过canvas把当前帧“截”成照片。这条路径能做完全自定义的相机界面比如自拍倒计时、扫码框、滤镜预览但必须满足 HTTPS 或 localhost 的安全上下文要求而且对跑在 WebView 里的 H5 来说权限配置没那么透明经常出现“独立浏览器能打开、塞进 App 就打不开”的情况。第三条是针对微信这类超级 App 内置浏览器。通过微信 JS-SDK 的wx.chooseImage、wx.chooseMedia、wx.getLocalImgData这些接口去调用系统拍照能力。它是 H5 和微信之间的一座桥不用自己维护视频流和权限但前提是你要有公众号或服务号的配置权限并且要做签名。第四条是混合 App 里的桥接方案。H5 跑在 Android WebView 或 WKWebView 里通过 JS 调用原生暴露的方法让原生拉起系统相机拍完再回调给 H5。这条路径体验最好但依赖原生同学配合严格来说已经不是纯 H5 的范畴。在实际项目里我经常不是只选一条路而是把基础方案和增强方案组合起来。比如优先用 input 做个保底同时尝试 getUserMedia如果失败就回退到 input。这样做的好处很明显——用户任何时候都能把照片拿到手只是体验层级有差异。2. 基础方案input 标签的调用边界与行为差异2.1 最简写法一行 HTML 拉起相机直接用表单元素是最快上手的方案input typefile acceptimage/* idcameraInput /这段代码放到移动端浏览器里用户点一下就会看到一个选择弹层上面有拍照、相册之类的选项。不需要申请摄像头权限不需要处理视频流浏览器已经把最复杂的事情做完了。拿到文件之后用change事件接收const input document.getElementById(cameraInput); input.addEventListener(change, function (e) { const file e.target.files[0]; if (!file) return; const url URL.createObjectURL(file); const img new Image(); img.onload function () { // 在这里拿到图片尺寸、做预览或压缩 URL.revokeObjectURL(url); }; img.src url; });这里有个容易被忽略的点URL.createObjectURL创建的对象 URL 要在图片加载完成后手动revokeObjectURL否则单张问题不大连续拍多张就会感觉页面越来越卡其实就是内存一直被占着没释放。如果你嫌原生的input太丑想完全自定义按钮样式常见做法是用label包一个透明或者隐藏的 input。但要注意iOS Safari 对display: none的 input 有时会触发不了选择器我一般把它做成position: absolute; opacity: 0; width: 1px; height: 1px;这种“看不见但还能点”的状态兼容性更好。2.2 capture 属性到底该不该加input里还有个容易被误解的属性叫capture。加上之后 HTML 长这样input typefile acceptimage/* captureenvironment /captureenvironment表示优先调用后置摄像头captureuser则优先前置摄像头。但这个属性在 iOS 和 Android 上的表现差异很大。iOS Safari 里加上 capture 之后点击会直接进入相机不再出现“拍照还是相册”的选择弹层。Android 各家浏览器则不一致Chrome 通常会弹出让用户选择是相机还是相册的弹窗有些国产厂商的系统浏览器看到 capture 就直接进系统相机也有部分实现完全忽略这个属性。我的使用经验是如果业务场景是“允许用户从相册里选一张旧图上传”不要加 capture因为一旦加了iOS 用户想选相册就会被强制推进相机界面还得手动退出体验很割裂。如果场景是“必须现场拍摄”例如活体检测、行驶证拍照那加上 capture 会比较直接至少能减少用户选错入口的概率。还需要提醒产品的点iOS 上用户第一次点 input 打开相机时系统会弹权限询问框。如果用户拒绝了下一次再点很可能相机直接打不开而且页面内无法再次触发系统弹窗只能去系统设置里重新打开。这个链路最好在 UI 上给出提示文案比如“请在设置中允许访问相机”否则用户会以为功能坏了。2.3 拿到 File 对象之后别急着上传用 input 拿到 File 对象后最忌讳的就是直接把整个文件丢给上传接口。手机旗舰机拍出来的一张照片在 3~10 MB 之间都是常态甲方要求上传的图片不超过 1 MB 的更是常见。所以这个方案的关键在于“拍完了还要压缩”而压缩的流程我在后面的图像处理部分会说。这里先给个原则File 对象本身是只读的你不能直接改它需要把它变成图片再重新生成新的 Blob 或 File。转换工具主要靠Image加canvas.toBlob。如果遇到的是 IE 那种老古董环境可能不支持toBlob那就只能用toDataURL了但移动端基本没必要考虑 IE放心用toBlob。3. 进阶方案getUserMedia 接管相机后的可控性3.1 跑通 getUserMedia 的三个前提如果产品要的不只是“拿到一张图”而是自定义的拍照界面、扫码界面、实时滤镜那 input 肯定不够用这时候就要上getUserMedia。第一个前提是安全上下文。getUserMedia只允许在 HTTPS 或 localhost 环境下调用。你拿公司内网 IP 地址在真机上测是不行的即使你在页面上看到了按钮调用时也报getUserMedia is not defined或者直接被拒。所以开发阶段一定要配好 HTTPS 证书或者用一些工具把本地服务暴露成 HTTPS 访问。第二个前提是用户授权。浏览器不会自动给网页摄像头权限用户必须点击页面上的按钮后才会触发授权弹窗也就是说不能在页面一进来就自动请求摄像头那样大概率会被拦截。这个授权请求最好绑在一次明确的用户手势上例如一个写着“开始拍摄”的按钮。第三个前提是环境支持。简单判断可以直接检查navigator.mediaDevices?.getUserMedia是否存在。但是注意这个方法在 HTTPS 下的存在概率高不代表实际可用WebView 里经常出现方法存在但调用后拿不到流或直接 reject 的情况所以在真正调用时还要做好 catch 和降级。3.2 完整拍照链路从媒体流到 canvas 定格一个标准的用户点击拍摄流程是这样的点击按钮后获取视频流把流绑定到 video 元素上用户看到实时画面后点击快门我用 canvas 把 video 当前帧画出来再导出成 Blob 文件。核心代码async function openCamera(videoEl) { const stream await navigator.mediaDevices.getUserMedia({ video: { facingMode: { ideal: environment }, width: { ideal: 1920 }, height: { ideal: 1080 } }, audio: false }); videoEl.srcObject stream; videoEl.setAttribute(playsinline, ); videoEl.muted true; await videoEl.play(); } function takePhoto(videoEl) { const canvas document.createElement(canvas); canvas.width videoEl.videoWidth; canvas.height videoEl.videoHeight; const ctx canvas.getContext(2d); ctx.drawImage(videoEl, 0, 0, canvas.width, canvas.height); return new Promise((resolve) { canvas.toBlob((blob) { resolve(blob); }, image/jpeg, 0.85); }); }这里有个很重要的细节iOS Safari 里如果 video 标签不加playsinline属性摄像头画面一播放就会被强行全屏你的自定义按钮全部被盖住。所以必须有playsinline。另外视频流默认不带声音但建议显式设置videoEl.muted true防止某些浏览器因为音频轨冲突闹幺蛾子。facingMode的取值建议用{ ideal: environment }而不要用{ exact: environment }。exact的意思是必须后置摄像头如果没有或者不支持就直接报错。ideal是优先级找不到后置则回退到默认摄像头更稳。3.3 前后置切换、分辨率与流释放让用户在相机界面切换前置和后置是getUserMedia方案里另一个高频需求。实现思路很简单再次调用 getUserMedia把新的流绑定到 video 上同时把旧的 flow 停掉。注意不要直接设置facingMode后指望原来的流自动变必须重新请求。async function switchCamera(videoEl, currentFacing) { const nextFacing currentFacing environment ? user : environment; const stream videoEl.srcObject; if (stream) { stream.getTracks().forEach((track) track.stop()); } const newStream await navigator.mediaDevices.getUserMedia({ video: { facingMode: { ideal: nextFacing } }, audio: false }); videoEl.srcObject newStream; await videoEl.play(); return nextFacing; }流释放这一点特别容易漏。如果你只拉流不停止手机状态栏会一直显示摄像头图标非常恐怖。页面关闭或者用户离开拍摄页时必须把每一条 track 都 stop 掉。之后要做的事是把canvas.toBlob返回的 Blob 再转为 File方便统一用 FormData 上传。如果 product 要求图片不超过多少 KB可以在 toBlob 前先做一次缩放这个我在下一节展开。4. 拍照后的图像处理压缩、方向矫正与格式统一4.1 EXIF 方向问题为什么 iPhone 拍照会“横”很多前端第一次遇到这个问题都会懵用户用 iPhone 拍了一张竖着的照片在img标签里预览是正的但传到 canvas 里再导出就变成横的了。根本原因在于照片文件里有一个 EXIF 方向标记iOS 拍出的照片 orientation 往往是 6代表着“需要旋转 90 度才能正确显示”。浏览器在渲染img标签时通常会自动读 EXIF 并转正但在canvas.drawImage()里不会它只会把原始像素画进去。所以你要么在画之前手动把 canvas 旋转一下要么借助现成的 exif-js 先读出 orientation。我当时是直接用 exif-js 处理import EXIF from exif-js; function fixOrientation(img) { return new Promise((resolve) { EXIF.getData(img, function () { const orientation EXIF.getTag(this, Orientation) || 1; resolve(orientation); }); }); }拿到 orientation 之后在绘制 canvas 前根据方向值去旋转画布。简单原则值为 3旋转 180 度值为 6旋转 90 度并交换宽高值为 8旋转 -90 度并交换宽高其他情况正常绘制处理完再去 toBlob导出的照片方向和用户看到的一致。否则后端拿到图后会发来一张横的身份证产品验收入口直接 GG。4.2 等比压缩与画质取舍不管走 input 还是 getUserMedia我最后都会把图片压缩到宽度不超过 1920、质量在 0.75~0.85 之间。原因很简单现在手机拍出来的原始分辨率可能到 4000 多像素宽画到 canvas 后一个像素占 4 字节算一下就是 4000 x 3000 x 4接近 50 MB移动端设备很容易在这一刻内存飙高低端机甚至直接白屏闪退。压缩的过程就是先按目标宽高等比缩放再画到 canvas 上最后 toBlobfunction compressImage(image, maxWidth 1920, quality 0.8) { const scale Math.min(1, maxWidth / image.width); const width Math.round(image.width * scale); const height Math.round(image.height * scale); const canvas document.createElement(canvas); canvas.width width; canvas.height height; const ctx canvas.getContext(2d); ctx.drawImage(image, 0, 0, width, height); return new Promise((resolve) { canvas.toBlob(resolve, image/jpeg, quality); }); }这里用Math.min(1, ...)是为了防止把本身很小、模模糊糊的图片给放大了那没有任何意义。quality值降到 0.8 左右在手机上目测基本没有清晰度损失值再低可能就出现明显的马赛克了。还有一点经验canvas.toBlob优先于canvas.toDataURL。toDataURL会把图片转成 base64 字符串base64 体积比 Blob 大三分之一左右而且字符串在内存里更占空间生产环境中用 base64 上传的大图很容易把用户手机内存耗光。只有某些平台通道比如微信的getLocalImgData才不得不拿 base64那是另一回事。4.3 格式统一JPEG、WebP 与 HEIC 的现实问题图片格式也是拍照功能里一个经常被忽略的坑。iPhone 默认开启了“高效格式”后拍出来的照片是 HEIC这个格式在 Android 上、在部分 Windows 服务端上都不一定支持。如果你走的是 input 方案acceptimage/*会让用户从相册里选到 HEIC但img根本解不出来后续 canvas 也没办法处理。最实在的解题思路是如果业务有强格式要求优先用getUserMedia方案因为它输出的内容完全经过 canvas只能导出浏览器支持的格式我用image/jpeg输出后拿到的一定是 JPEG不会出现 HEIC 的惊喜。如果必须走 input 方案可以在拿到 File 后检查文件名后缀或 MIME 类型发现是 HEIC 的时候提示用户“请选择普通格式照片”或者后端支持额外处理 HEIC 解码否则就只能靠产品方去引导了。至于 WebP它在移动端浏览器的兼容性已经很好但上传到老旧的服务端、图片处理管道可能不支持。为了减少联动成本我一般直接输出 JPEG质量和体积平衡得不错省得跟后端扯皮。5. 微信与 WebView 环境下的平台能力5.1 微信 JS-SDK 的拍照调用微信内置浏览器的 H5 页面如果只做普通文件上传input[typefile]本身就能用。但微信的 input 经常有几个问题iOS 上拉起相册慢、相册返回后页面被重绘、某些版本呼出键盘后页面错位。想要更可控就要接微信 JS-SDK用平台提供的wx.chooseImage或新版本的wx.chooseMedia拍照选图。JS-SDK 最大的前置成本是签名。你需要先在微信公众平台配置 JS 安全域名再在后端生成签名串前端引入官方 js-sdk 后wx.config配置一遍。签名不对所有前端 API 都会报错这是新手最容易卡住的地方。配置完成后调用方式很接近直觉import wx from weixin-js-sdk; wx.ready(() { wx.chooseImage({ count: 1, sizeType: [compressed], sourceType: [camera, album], success: (res) { const localId res.localIds[0]; wx.getLocalImgData({ localId: localId, success: (result) { // result.localData 是 base64 } }); } }); });这里的localId比较特殊。在 iOS 上可以直接把它当图片地址塞到img.src里显示但在 Android 上是老版本微信的一个死结很多旧设备把 localId 作为地址会显示不出来。保险的做法是统一走wx.getLocalImgData拿 base64 再显示或上传。我在接微信拍照的时候还会注意一件事getLocalImgData返回的 base64 体积很大尤其选了原图之后直接塞进 FormData 上传会让内存和网络双双吃紧。所以拿到 base64 后我会先用atob转成二进制数组再包装成 Blob 对象最后做一次 canvas 压缩再上传这样质量和体积都能控制住。5.2 WebView 中 getUserMedia 的不稳定根源很多做混合 App 的团队问我为什么同一个 H5 页面在 Chrome 里能调起摄像头塞进 App 的 WebView 里就不行了。答案其实不复杂。Android WebView 的媒体权限不是一个默认开启的能力原生工程需要在WebChromeClient里实现onPermissionRequest并且有对应的 Android 摄像头运行时权限H5 的 getUserMedia 才有机会拿到流。iOS 的 WKWebView 相对好一些但也要注意 Info.plist 里的相机权限描述和 WKWebView 的媒体捕获配置。最怕的是某些第三方的壳、小程序容器可能没有把这些配置透传出来H5 端怎么努力都没有办法。所以在业务上如果你能确定页面只跑在自家 App 里与其纠结 getUserMedia 能不能通不如直接走原生桥接体验会稳定很多。如果 H5 要同时支持 App 内和外部浏览器访问那就做成一个能力检测能跑 getUserMedia 就优先用它失败了回退到 input 选照片至少保证功能不挂。5.3 混合 App 桥接方案的设计思路所谓桥接就是前端通过一个约定好的全局方法调用原生相机原生拍完后再把结果传给前端。比如在 Android 里原生暴露一个window.AndroidCamera.takePhoto()JS 这边调用它然后原生把拍好的照片路径或 base64 内容回传到window.onNativeCameraResult。iOS 通常走window.webkit.messageHandlers.camera.postMessage()。设计这种桥的时候我最担心的是回调时序用户拍完照、原生把结果传回来中间可能经过了几秒甚至更久如果前端页面恰好发生刷新或跳转回调就丢了。所以要做好回调注册表的维护比如一个全局的 promise 队列前端调用前注册一个 callback ID原生返回时带上同样的 callback ID前端再根据 ID 找到对应的 resolve 去执行。这套思路不复杂但能省掉很多线上偶发问题。6. 核心坑位记录与内存性能优化6.1 大图解码与内存峰值我用一个表格把平时最常踩的坑整理一下看着更直观坑位现象我现在的处理方式原图直接 drawImage 到 canvas低端机卡顿、白屏先按最大宽度 1920 缩放再绘制toDataURL 保存照片内存峰值高、上传慢统一用 toBlob拿 HEIC 照片当普通图片处理图片显示不出来用 getUserMedia 输出 JPEG 或提示用户getUserMedia 后不停止轨道摄像头指示灯常亮、耗电离开页面或拍照完成就 stop 所有 track页面在 iframe 里调用摄像头权限策略直接拦截父页面给 iframe 加allowcamera连续拍照后内存持续上涨页面越来越卡每次用完后 revokeObjectURL并主动把 canvas 宽高清零第一条值得多说两句。原图非常大我生成 canvas 时如果直接取原始尺寸等于一次就申请 50 MB 左右的内存再加上浏览器内部的绘制缓存压力非常大。所以我设计拍照链路时会在drawImage之前就算好目标宽高不让 canvas 去背原图的锅。6.2 权限拒绝、后台切换与页面生命周期权限拒绝是 H5 拍照里绕不开的问题。用户拒绝摄像头权限后页面内的getUserMedia一定报错。这时候不能只弹个“error”了事要给用户一个清晰的引导告诉他怎么在系统设置里重新打开权限。同时做好降级比如提示“如果不能拍照也可以从相册选择图片”然后把 input 方案弹出来。还有一个很容易被忽略的场景用户在自定义相机页面点击 Home 键切去微信聊天再切回来视频流可能已经断了但前端以为还活着。我每次在visibilitychange事件里做一次状态检测如果视频流失效或者 video 的 readyState 异常就自动重新拉流。页面卸载时也要清理现场window.addEventListener(pagehide, () { if (stream) { stream.getTracks().forEach((track) track.stop()); } });尤其单页应用里做路由切换别只记住页面隐藏全部 track 都还在后台烧电过了几分钟用户手机发烫就来找你麻烦了。6.3 测试兼容性必须真机验证拍照功能是真机特强相关的能力模拟器里表现再好都不能说明问题。我自己的测试矩阵至少包含这么几类最新版 iOS Safari、较老版本的 iOS Safari、Android Chrome、微信内置浏览器 X5 内核、自家 App 的 WebView再加几台千元安卓机。没有条件全测就让公司群里的同事各自用手机点一遍收集日志。调试时很容易犯一个错把video.srcObject绑定后立刻调用video.play()发现有时候黑屏。本质是源还没有加载完成建议监听一下video的loadedmetadata事件后再 play或者直接await video.play()并加上 try-catch因为 iOS 上 autoplay 策略很严格用户没有交互时直接 play 会被拒绝。7. 选型逻辑按业务场景判断该用哪种方案7.1 按场景选方案的推荐清单如果只看功能简单程度大部分需求其实用不到 getUserMedia。我给你一个我现在做技术评审时刻在脑子里的选择逻辑业务场景推荐方案理由用户上传头像、评论配图input canvas 压缩路径短、兼容好、开发成本低实时相机预览、滤镜、扫码getUserMedia需要深度控制画面在公众号/微信传播页里拍照微信 JS-SDK微信能力集成更稳签名好不死磕自家 App 内嵌 H5原生桥接权限链路由原生掌握最可靠既要真机拍照又要选相册旧图input 不写 capture让用户可以自由选择来源必须用后置摄像头现场拍摄input 加 capture 或 getUserMedia 固定环境摄像头减少用户误操作这表不复杂但每次我都能用它快速否定掉“过度设计”的方案。比如有人一上来就说要用 getUserMedia 做头像上传我问一句“用户需要预览吗需要滤镜吗”不需要就老老实实用 input。功能和成本对齐是工程落地的基本功。7.2 最稳妥的组合与个人经验我现在做项目基本不会只用单一方案。最常见的一个组合是input 作为基础能力getUserMedia 作为增强能力两者同时存在页面里。页面初始化的时候先检测navigator.mediaDevices?.getUserMedia能用就给用户展示自定义相机界面不能用或者调用失败就自动切成 input 上传。用户永远有“从相册选一张”的退路产品永远有“自定义界面”的体验两边都不吃亏。另一个心得是照片上传前前端一定要做统一的 Blob 输出和压缩并且把原始文件信息作为调试日志上报。拍照这个链路涉及的终端太多线上真的什么异常都可能冒出来。没有日志用户一反馈你可能要花半天去猜是系统的问题、WebView 的问题还是图片格式的问题有日志一次问题定位可能只要几分钟。最后聊一个绝大多数教程不会提的细节所有相机相关能力都要在用户点击回调之后再去触发不要在页面加载、滚动等非交互事件里自动申请权限。否则 iOS 和 Android 都会判定为“非用户手势发起”权限弹窗大概率起不来。拍照是一个必须时刻把“用户体验”放在第一位的功能而用户体验往往就是从这些系统约束里抠出来的。