企业官网建设流程全解析

移动端H5开发做了这么多年，拍照功能是我见过问得最多、踩坑最深的一个模块。商城上传商品图、社区发帖配图、后台系统提交身份证、企业内部小程序做巡检记录，十有八九的H5页面最后都要跟摄像头打交道。技术群里经常有人问“H5到底能不能调起相机”，这个问题看着基础，但真做起来就会发现：同样的代码，iOS和Android表现不一样，微信内置浏览器跟系统浏览器表现不一样，有的手机直接打开相册而不是相机，有的手机拍完照片旋转了90度，还有权限弹窗、图片压缩、上传失败等一系列连锁问题，任何一个环节没处理干净，需求方就会觉得是你能力不行。

这篇文章我把这几年做H5拍照功能用过的方案、验证过的细节、踩过的坑完整梳理一遍。从最基础的input file原生文件选择器，到getUserMedia自绘相机，再到App内嵌WebView时的桥接方案，每种方案我都会说清楚适用场景、实现要点、性能表现和隐藏风险，并且附上可直接参考的代码和实践经验。无论你是刚接触移动端H5的新人，还是正在被某个奇怪兼容性问题折磨的老手，这篇内容都能帮你少走不少弯路。

1. 选方案前先看清楚：H5拍照到底在拍什么

1.1 场景决定方案，不是方案决定场景

很多人一上来就问“用哪个API”，这是被技术视角限制了。H5拍照看起来是个单一动作，但在真实业务里，“拍”只是前半场，后面还跟着裁切、压缩、上传、回显、重拍、多图、压缩质量这些任务。不同业务场景对拍照体验的要求完全不一样，方案选择自然也就不一样。

我归纳下来，H5拍照需求大致能分成这么几类：

• 轻量随手拍：比如社区评论配图、工单回传照片，用户对拍摄界面要求不高，能拍清楚就行，用系统相机都可以接受。
• 身份类证件照：比如实名认证、合同签署，这类照片有明确的画面范围要求，最好能限制拍摄区域，同时调用的是后置摄像头，还要避免用户从相册传旧图。
• 现场记录：比如保险事故现场、物流签收回单，这类场景往往在户外，光线不稳定，用户单手操作，网络环境也不好，对拍摄启动速度和图片压缩要求很高。
• App内嵌业务：比如原生App的某个频道页用WebView承载，这时H5直接调getUserMedia或input file可能受制于WebView的权限策略，必须走原生桥接。

场景直接影响方案：如果只是配图，input file就够；如果有画面构图要求，就得上getUserMedia自绘相机；如果跑在App内嵌WebView里，就得先搞清楚容器给了多少能力。方案没有绝对的好坏，只有适不适合当前场景。

1.2 H5能调用摄像头的能力边界要摸清

做方案选型之前，先把H5在移动端能调用的摄像头相关能力摸清楚。目前主流的其实就三条路：

第一是input file。这是HTML标准能力，不需要申请摄像头权限，也不需要HTTPS，只要用户点击，浏览器就会根据accept和capture属性的组合，弹出相机或相册。这个方案最稳，兼容性最好，几乎所有移动端浏览器都支持。

第二是getUserMedia。这是WebRTC的核心API，能拿到实时视频流，配合video标签和canvas，可以自己绘制取景界面、实现拍照逻辑。这个方案灵活度最高，但限制也最多：必须跑在HTTPS环境下（本地localhost除外），需要用户授权摄像头权限，且在WebView里能否使用取决于容器的配置。

第三条是WebView桥接。如果H5页面嵌在原生App里，且容器屏蔽了上述两条路，那就只能通过JSBridge调用原生相机，拍完照片之后原生把图片路径或base64回传给H5。这个方案不受前端自身限制，但依赖宿主App的配合。

选择方案的核心逻辑就是：能用简单方案就绝不复杂化，复杂的方案必须有一个足够强的理由支撑，比如强构图需求或者极致流畅的取景体验。

1.3 一张表看懂主流方案的选型对比

我先在开头就给出选型结论便于你对照。下面这张表不是网上抄来的，是我在几个实际项目里逐项验证过的经验值，不同机型可能略有出入，但大方向不会变。

看完这张表，你可以根据自己项目的真实约束去划掉不适合的方案。如果还不能确定，继续往下看每种方案的细节，心里会更有底。

2. 方案一：input file 原生文件选择器——80%场景的默认解

2.1 为什么先把它拎出来说

input file是我在大多数业务场景里首选的方案。原因很简单：它能让H5页面在不需要任何权限申请的前提下，直接唤起系统相机或者相册。用户拍完照，拿到的是一个文件对象，后续的压缩、上传全部由前端自己控制。对不熟悉这个能力的人来说可能觉得有些“土”，但真正做过生产项目的人会明白，稳定压倒一切。

我印象最深的是一个物流签收项目。司机在户外把回单拍下来上传到系统里，环境嘈杂、光线刺眼，还经常单手操作。最初产品经理希望做一个“看起来高级”的页面内取景框，但我坚决拒绝了，原因就是没人能保证户外强光下getUserMedia的自绘取景UI一定清晰、流畅。最后用了input file加capture="environment"，点击按钮直接唤起系统相机，司机拍完自动返回页面。上线两年多，这条路的客诉率最低。

另外，input file对SEO和可访问性也比较友好。它是一个标准表单控件，结构简单，不存在JS执行被拦截导致整个功能失效的风险。页面构建的时候，这个方案可以作为兜底功能永远保留。

2.2 capture 参数到底该不该加

很多人对capture参数的理解有三个常见误区：加了这个参数才是拍照，不加就只能选相册；加了capture="user"就是前置摄像头；iOS和Android行为必然一致。实际做下来，这三个理解都不完全对。

capture参数是可选的，它告诉浏览器“优先唤起相机的意图”。在iOS的Safari和部分Android浏览器里，加capture="environment"会直接打开后置摄像头拍摄界面；不加的话，系统一般会弹出底部ActionSheet，让用户在“拍照”“相册”之间自己选。Android的碎片化在这里特别明显，部分国产ROM机型即使加了capture也照样弹相册，这个没法通过前端代码强行解决，只能靠真机适配。

关于前后摄像头：capture="user"理论上表示请求前置摄像头，capture="environment"表示后置。但在实际测试中，大部分Android浏览器会忽略这个区分，统一打开默认后置摄像头，iOS倒是会认真对待。所以如果你要的是自拍场景，capture="user"在iOS上可靠，在Android上就得做好“用户拿到后置相机”的心理准备。

还有一种做法是有意不加capture，让用户自己在底部菜单里选“拍照”或“相册上传”。这种做法适合对图片来源不敏感的场景，好处是用户体验主动权更大，但坏处是有些用户并不知道可以拍照，导致上传的照片质量参差不齐。如果业务强依赖照片的实时性，比如现场验收记录，那capture必须加。

2.3 实战封装一个通用拍照入口

基于上面的分析，我在项目里通常封装一个简单的公共组件，核心代码大概长这样：

<input type="file" accept="image/*" capture="environment" id="cameraInput" style="display:none" /> <button id="takePhotoBtn">拍照上传</button>

const input = document.getElementById('cameraInput'); const btn = document.getElementById('takePhotoBtn'); btn.addEventListener('click', () => { // 重置value，保证同一文件也能触发change事件 input.value = ''; input.click(); }); input.addEventListener('change', (e) => { const file = e.target.files[0]; if (!file) return; // 这里拿到的是原始文件，建议后续统一走压缩逻辑 handleFile(file); });

这里有几个容易被忽略的细节，我一一说明。

第一，input的value必须在每次点击前手动清除，否则用户连续拍摄两次同一张照片时可能不触发change事件。第二，我给input加了display:none，用户点击的是自定义按钮，视觉上更统一，但如果需要无障碍支持，建议用label绑定input而不是完全隐藏。第三，accept="image/*"不写全可能漏掉一些HEIC格式图片，但写全了像accept="image/jpeg,image/png,image/heic"这种又容易在某些Android浏览器下导致无法唤起相机，所以我的实践是保持image/*不变，后续在压缩判断里去兼容HEIC。

如果你遇到“点击按钮没反应”的问题，先排查是不是input被父元素遮挡或者z-index出了问题，这个小坑我踩过不止一次。

3. 方案二：getUserMedia 自绘相机——可控但藏着不少坑

3.1 getUserMedia 必须知道的几个前提

当业务需要自定义取景界面、构图框、焦距控制，或者希望用户拍完直接预览并重新拍摄而不离开当前页面时，input file就不够用了，这时候要上getUserMedia。

getUserMedia的使用有几个硬性前提，我先把最关键的三个说出来：

第一，必须是安全上下文。HTTPS是必须的，本地调试的时候localhost可以例外，但你在真机上用局域网IP访问HTTP页面时，这个API大概率用不了。这是个很折腾人的问题——你在电脑Chrome里调试一切正常，手机一访问就白屏报错，先排查这个。

第二，必须经过用户授权。浏览器会弹权限框，用户拒绝之后navigator.mediaDevices.getUserMedia会抛错，需要写降级逻辑。而且一旦用户选择了“总是拒绝”，普通网页后续想再弹权限框就难了，这种情况下只能引导用户去浏览器设置里手动打开权限。

第三，WebView环境不确定。微信内置浏览器的表现跟系统浏览器有差异，某些Android版本的WebView甚至压根不支持这个API。真要做，必须在目标容器里先做能力检测。

能力检测代码很简单，但很关键，我通常放在进入拍照页的最前面：

if (!navigator.mediaDevices || !navigator.mediaDevices.getUserMedia) { // 降级到input file方案 fallbackToInputFile(); return; }

不要等到用户点“开始拍照”的时候才检测，那时候报错已经晚了，用户会觉得功能坏了。

3.2 视频流、Canvas 和拍照核心流程

核心拍照流程分四步：拿流、铺画面、截一帧、停止流。每步都有自己的讲究。

第一步，获取视频流。用下面的约束参数可以获得后置摄像头，并尽量选择清晰一些的画面：

async function startCamera() { const stream = await navigator.mediaDevices.getUserMedia({ video: { facingMode: { ideal: 'environment' }, width: { ideal: 1280 }, height: { ideal: 720 } }, audio: false }); videoElem.srcObject = stream; await videoElem.play(); return stream; }

facingMode这里我用的是ideal而不是exact，因为exact强制要求精确匹配，在部分设备上会导致直接黑屏或获取失败，ideal是“尽可能满足”的意思，兼容性更好。width和height用ideal同理。

第二步，把视频流铺到video标签上。这一步看起来简单，但需要处理好画面的展示比例。我一般用CSS的object-fit: cover让video填满容器且不变形，但要注意，这样做的后果是用户在取景框里看到的画面和最终的canvas截取画面会不一致——canvas截取的是video元素内部的原始分辨率帧，不是CSS展示后的尺寸。如果画面上叠加了构图线，构图位置和实际照片内容可能对不上，这是自绘相机最容易踩的“视觉陷阱”。

第三步，拍一帧。核心操作是canvas.drawImage(video, 0, 0, width, height)。这里有个常见疑问：直接取video.videoWidth和video.videoHeight作为画布尺寸好，还是固定一个尺寸好？我建议直接取原始分辨率，这能最大程度保留画面细节。但如果你拍完还要做封面裁剪这种UI，可以先取一个固定宽高做预览，真正保存时再按原图比例绘制。

function captureFrame(video) { const canvas = document.createElement('canvas'); const w = video.videoWidth; const h = video.videoHeight; canvas.width = w; canvas.height = h; const ctx = canvas.getContext('2d'); ctx.drawImage(video, 0, 0, w, h); return new Promise((resolve) => { canvas.toBlob((blob) => resolve(blob), 'image/jpeg', 0.8); }); }

这里要特别说明：canvas.toBlob是异步的，和toDataURL不同，它输出的是Blob对象，后续直接丢进FormData就能上传，内存占用也更小。我强烈建议用toBlob而不是toDataURL，尤其在大图上，后者很容易把内存吃满。

第四步，停止视频流。这一步很多人会忘。拍照完成或者用户离开页面时，如果不手动停止流，摄像头指示灯会一直亮着，既费电，也会在iOS上导致状态栏出现红点，用户观感很差。停止方法：

function stopStream(stream) { stream.getTracks().forEach((track) => track.stop()); }

3.3 真机调试最容易翻的三个车

getUserMedia方案我真正做下来，遇到的坑比input file多得多，这里挑三个最有代表性的说。

第一个坑是“权限已授权但画面黑屏”。最典型的场景是华为、小米的部分机型，用户明明点了允许，video标签却一片黑。排查到最后，原因大多是WebView的摄像头权限没有在宿主App里配置。如果页面跑在原生WebView里，光有网页的getUserMedia权限还不够，还得在原生工程里声明摄像头权限。这个问题在混合开发项目里尤其容易碰到，前端排查半天，最后问题在原生配置上。

第二个坑是“第一次能打开，第二次打不开”。常见于离开页面时没停流，或权限请求被浏览器拦截。修复方式就是前面说的，页面卸载前一定要stopStream，并且把videoElem.srcObject置为空。

第三个坑是“取景画面卡顿、延迟明显”。这通常不是网速问题，而是把分辨率设置太高了。4K甚至是1080P的视频流在部分千元机上实时渲染会有明显延迟，导致用户按快门时拍到的画面滞后。解决办法是把resolution控制到720P级别，或者用帧率约束frameRate: { ideal: 30 }，保证体验流畅比画面精细更重要。

4. 方案三：图片压缩与上传——拍照只是前半场

4.1 为什么压缩这步无论如何不能省

很多人觉得拍照功能的核心是调起摄像头，拍完直接上传就完事了。真正上线后你会发现，99%的问题都出在图片本身太大上。现在的手机拍一张照片动辄3MB到8MB，有的开启了HEIC格式之后更大。直接上传会有两个后果：一是用户流量消耗大，弱网环境下传几分钟都不动，最后等不及就关页面了；二是服务器要处理大体积图片，存储和带宽成本都水涨船高。

对于这个问题的处理，我的经验是在前端做一次彻底的压缩。目标很明确：压缩后的图片宽度控制在1920像素以内，质量控制在0.7到0.8之间，单个文件大小压到500KB以下。这个标准既能保证图片在手机端浏览时足够清晰，又能让上传速度显著提升。

但这里有个前提必须说清楚：压缩是有损的，如果业务对照片要求极高，比如公安备案、保险定损这种需要留作证据的图，前端压缩不能压得太狠，甚至应该考虑保留原图，只在上传时做异步分片。我一般建议产品经理对图片用途做个分级，普通业务图压缩上传，高保真业务图原图或轻度压缩。

4.2 压缩参数到底怎么定：目标宽度与质量值

图像压缩的原理不复杂，核心就是canvas重绘。先把原图画到canvas上，再按目标尺寸导出，导出时的质量参数决定压缩率。

我的建议是不要“一刀切”式地固定宽度，而是根据图片原始尺寸等比例缩放。比如原图是4000x3000，目标宽度1920，就等比例算出目标高度1440。这样能保证画面不变形，也不会把用户原本清晰的图压到没法看。

前端判断原始尺寸需要先用Image对象加载一遍原图，拿到宽高后再绘制。代码大概是这样：

function compressImage(file, maxWidth = 1920, quality = 0.75) { return new Promise((resolve, reject) => { const reader = new FileReader(); reader.onload = (e) => { const img = new Image(); img.onload = () => { const scale = Math.min(1, maxWidth / img.width); const w = Math.round(img.width * scale); const h = Math.round(img.height * scale); const canvas = document.createElement('canvas'); canvas.width = w; canvas.height = h; const ctx = canvas.getContext('2d'); ctx.drawImage(img, 0, 0, w, h); canvas.toBlob( (blob) => resolve(blob), 'image/jpeg', scale === 1 ? 0.9 : quality ); }; img.onerror = reject; img.src = e.target.result; }; reader.onerror = reject; reader.readAsDataURL(file); }); }

注意一个细节：如果原图本身比maxWidth还小，scale会取Math.min(1, ...)的1，此时不应该用低质量参数把它再次压糊，我代码里已经用scale === 1时quality提到0.9来处理。另外，canvas导出格式我固定用image/jpeg，这能规避png格式体积过大问题，但代价是透明背景会变黑，如果你处理的是含有透明区域的截图，就不能这样做。

4.3 FormData提交与上传进度的处理

压缩完成后的Blob对象，直接丢进FormData就能上传，这是最兼容的姿势：

async function uploadPhoto(blob, fileName) { const formData = new FormData(); // 这个filename在部分后端解析时很关键，不要省略 formData.append('file', blob, fileName || 'photo.jpg'); formData.append('bizType', 'common_photo'); const xhr = new XMLHttpRequest(); xhr.open('POST', '/api/upload', true); xhr.upload.onprogress = (e) => { if (e.lengthComputable) { const percent = Math.round((e.loaded / e.total) * 100); updateProgressBar(percent); } }; xhr.onload = () => { if (xhr.status === 200) { // 解析返回的图片URL const res = JSON.parse(xhr.responseText); handleUploadSuccess(res.url); } }; xhr.send(formData); }

这里特意用XMLHttpRequest而不是fetch，是因为XMLHttpRequest的upload.onprogress事件更成熟，兼容性更好，能方便地实现上传进度条。如果后端接口支持Base64格式，也可以直接把dataURL发上去，但Base64会比同内容的Blob大约多出30%的体积，我一般只在接口已经定型无法改动时才用。

5. 方案四：App内嵌H5的桥接方案——绕不开WebView时怎么办

5.1 什么时候必须走桥接

前面说过，移动端H5并不总是跑在浏览器里，很多场景其实是嵌在原生App的WebView里的。在WebView环境里，getUserMedia能不能用，取决于宿主的WebView配置；input file能不能唤出相机，也取决于WebView有没有开放文件选择能力。

我之前做过一个企业服务类App的内嵌H5页面，功能是提交销售拜访记录，需要现场拍照留证。Android端WebView默认配置下，input file点击后没有反应，典型表现是按钮点了没弹系统相机，控制台也没有任何报错。后来排查发现是WebView没有设置WebChromeClient的onShowFileChooser回调。这类问题你作为H5开发人员很难通过前端代码解决，必须跟原生同事联调。

当WebView把input file的能力“阉割”了，或者业务希望拍照完直接上传到App自有存储路径时，就必须走桥接方案。基本原则是：H5负责页面交互，原生负责调相机，通过JSBridge做好通信。

5.2 JSBridge最小协议怎么设计

桥接方案里，通信协议设计不好会很难维护。我建议遵循“最小协议”原则，只暴露必要的方法。

一个常用协议设计大致如下：

H5调用原生：

// 调起相机拍照 window.NativeBridge.takePhoto({ source: 'camera', // camera / gallery maxSize: 1920, quality: 0.8, success(res) { // res.uri 是本地文件路径或临时URL // res.base64 可选，有的实现直接回传base64 }, cancel() { // 用户取消 }, fail(err) { // 调用失败 } });

原生调用H5：

// 拍照完成后的回调 window.NativeBridge.onPhotoTaken({ uri: 'file:///....', width: 1920, height: 1080, size: 352123 });

这里有两个实践细节。第一，所有方法名和参数名建议在开发初期就跟原生同事用接口文档固定下来，避免后续反复改。第二，由于原生回调是异步的，建议给每次调用追加一个requestId，原生回调时原样带回，H5侧通过requestId匹配当前是哪一个调用，这样能避免多次拍照时回调串台。

实际情况中，App内部用的桥接库可能是自定义的，也可能是基于某些开源库封装过的。不管你拿到的是哪个库，核心就只有三件事：H5主动调原生、原生回调到H5、双方约定好数据结构。

5.3 桥接的通信安全与异常处理

桥接方案最容易被忽视的是安全与异常处理，但这两条恰恰在线上最容易出问题。

通信安全方面，至少要约定一个合法的来源校验。H5的页面地址和原生调用环境要固定在同一App内，防止别的页面伪造请求。具体到JSBrige协议里，每次调用最好带上一个token或签名，原生侧校验通过才执行。这个安全校验看着麻烦，但能挡掉许多基础的恶意调用。

异常处理方面，原生拍照后如果返回了本地临时文件路径，H5侧得考虑这个文件什么时候会失效。很多App会在拍照完成后立即清理临时目录，如果你把uri保存到本地稍后再用，很可能拿到一个打不开的路径。稳妥的做法是，原生回调返回后H5立刻通过img标签去加载并渲染出来，或者干脆让原生直接返回base64，省去文件生命周期管理的麻烦。

另外，桥接调用一定要设定超时时间。真实场景里用户可能拍完照片迟迟不点确认，或者原生相机崩溃，如果H5一直傻等回调，用户就会觉得“卡死了”。我的做法是：调用拍照后，15秒内没收到成功或取消回调，就主动弹出重新拍摄或返回的提示。

桥接方案虽然实现起来比前两种麻烦，但在App内嵌场景中几乎是绕不开的路径。它对H5开发者提出了更高要求：不仅懂前端，还要能跟原生同事顺畅沟通，把协议定义清楚。

6. 常见问题与避坑清单——把这些记下来能省一整天

6.1 问题速查表

把我在实战中遇到的高频问题整理成一张速查表，建议收藏以后排查时对照使用。

6.2 iOS 无法唤起相机的真相

iOS上“无法唤起相机”的情况，我排查过几次，最后的原因基本落在两类：一是页面不在安全上下文里，比如输入的是http地址，Safari对getUserMedia的权限管理很严格，这种情况下摄像头API根本拿不到；二是input file触发的照片选择菜单里只有相册选项，没有“拍照”选项，这通常发生在iPad或某些特殊设置下，因为iPad对“相机”上下文的理解跟iPhone有差异，系统相机调用被限制。

如果用户反馈iOS拍不了照，第一件事是先确认是不是在微信里。微信内置浏览器对input file的支持相对成熟，但有时会弹出“选择图片”菜单而不是直接唤起相机，这其实是微信自己在“拍摄”和“从手机相册选择”之间做了转换，并不是H5代码出错了。如果产品经理对这个交互有要求，只能引导用户在Safari中打开页面，或者接入微信JSSDK的wx.chooseImage接口，后者是微信生态内的标准做法。

另外还要提醒一个iOS的老问题：用户拍完照片后图片方向会被记录在EXIF里，而浏览器img标签和canvas在绘制时不一定能自动识别这个方向。于是就会出现“拍的时候是正的，上传后却是横的”的奇葩问题。这种情况需要读取EXIF方向角，手动旋转canvas。常用的库是exif-js，核心处理逻辑是：读取Orientation值，canvas按对应角度旋转后再画图。这块代码不复杂，但容易漏判。

6.3 Android 弹出相册而不是相机

Android的碎片化是H5开发绕不过去的一座山。很多机型上，capture="environment"只是一个建议，系统弹窗直接给你相册列表而不是相机界面。这不是代码写错了，是Android系统风格和厂商rom的实现差异。

面对这种情况，我的态度是：不要试图跟前端代码硬刚，该接受就接受。只要用户能最终选到照片，功能就算完成。真正要较真的场景是必须现场拍照的业务，比如“不允许上传历史照片”的验证类需求，这时前端方案在Android上根本靠不住，必须走原生App的桥接拍照或者引入第三方SDK。如果硬要在H5里实现这个限制，我只能说准备好在用户的差评里反思人生。

另外Android上有个常见的隐藏问题：从相机拍完照片返回页面时，页面可能被系统杀掉重建，onchange事件丢失，导致看起来“拍完照片没有任何反应”。遇到这种情况，可以在页面可见性变化时主动检查input.files，或者用sessionStorage做断点续传，确保拍照返回后能恢复现场。

6.4 HTTPS 和本地联调的那些坑

HTTPS问题在开发阶段最容易让人抓狂。我见过很多人用http的局域网IP地址在手机上联调，结果页面能打开，getUserMedia却一直报错。原因就是前面提到的安全上下文限制。我的建议是：开发阶段直接使用本地HTTPS代理或者用工具生成临时HTTPS证书，让手机访问HTTPS的局域网地址，提前规避权限验证问题。

如果你用的是Chrome DevTools模拟移动端，也要注意，模拟环境下的摄像头调用表现跟真实手机完全不同，摄像头能力在开发工具里可以说基本不可用。所以我一般建议：摄像头相关功能，从第一天起就要真机联调。省掉这一步，后面上线前集中联调的时间成本会翻倍。

还有个细节，如果页面部署在CDN或对象存储上，要确保域名上有HTTPS证书，并且不要用某些会拦截媒体流请求的防火墙或安全策略，否则页面资源能加载，摄像头流却拿不到。

6.5 内存与性能优化：拍照卡顿的隐形元凶

拍照功能的性能问题往往比功能本身更难排查。最常见的幕后黑手是内存暴涨。当用户拍了一张大图，前端要把它读成DataURL，再画到Canvas上，再导成Blob，过程中内存峰值可能达到图片体积的5到10倍。如果页面本身还承载了很多其他模块，很容易在低端机上直接白屏或崩溃。

针对这个问题，我总结了几条比较有效的优化手段：

第一，读取图片时不直接用原始文件，而是先做图片格式的初步判断，HEIC这类格式在部分浏览器里根本无法解码，需要提前转为JPEG，或者提示用户换格式。第二，尽量用URL.createObjectURL代替FileReader.readAsDataURL来预览，前者是浏览器内部的文件引用，内存开销比后者小很多。第三，压缩过程分两段：先压低分辨率，再导出JPEG，不要尝试一次完成所有操作。

我在一个社区项目里实测过，同样的原图，做了以上优化之后，拍照到上传的整体耗时从平均6秒降到了2秒左右，低端机上卡顿的概率大幅下降。拍照看起来是个小功能，但优化空间一点都不小。

最后再分享一个真实的小技巧

做H5拍照功能做到后期，我自己形成了一个习惯：不管当前方案选的是什么，永远保留一条input file的降级路径。getUserMedia失败时、WebView桥接没配置时、甚至原生App出了bug时，只要还有input file这条路，用户至少能拍照上传，业务不至于完全中断。这就像家里的备用钥匙，大多数时候用不上，但真到需要的时候，你会庆幸当初留了一手。

另外，如果产品迭代快，拍照模块改动频繁，建议把“拍照、压缩、上传”这三段逻辑拆成独立模块，分别测试。拍照只管拿文件，压缩只管出Blob，上传只管发请求，每段都能单独mock。这样后期无论是换摄像头方案，还是换上传协议，都不至于牵一发动全身。

H5拍照这件事，看起来简单，实际上是一个横跨浏览器兼容性、权限策略、图像处理、网络上传的综合性工程。希望这篇文章能帮你把方案选明白、把坑提前填平。如果看完还有具体的兼容性问题想交流，欢迎在评论区带上机型和场景，我们细聊。