可大概率唤起安卓后置摄像头；iOS 16+ 支持 capture="user" 强制前置，旧版仅识别无值 capture；微信X5内核支持不稳定，需降级提示用户手动切换；通过 change 事件读取 e.target.files[0] 获取 File 对象，用 FileReader 转 base64 或 Blob 上传；务必压缩图片（canvas.toBlob + 等比缩放至宽≤1200px），但后端须兼容未压缩图；禁用传统 form 提交，改用 FormData 手动 fetch 上传，并防重复提交。
input type="file" 怎么触发手机摄像头
直接用 <input type="file" accept="image/*" capture="environment">，不加 capture 属性，很多安卓机默认弹相册；加了才大概率唤起后置摄像头。iOS 16+ 支持 capture="user" 强制前置，但老版本只认 capture（无值）或忽略。
-
accept="image/*"必须写，否则部分浏览器不识别为图片采集场景 -
capture="environment"是关键，不是所有机型都严格遵守，但比不写靠谱得多 - 不要依赖
multiple和拍照同时上传多张——单次调用摄像头一般只产出一张图 - 微信内置浏览器（X5内核）对
capture支持不稳定，可降级为纯accept="image/*"+ 提示用户手动切摄像头
拍完照片怎么读取到 JS 里处理
监听 input 的 change 事件，从 e.target.files[0] 拿 File 对象，再用 FileReader 转成 base64 或 blob URL。别直接读 input.value——那是路径字符串，且现代浏览器为空。
-
File对象有name、type、size，可用于校验是否真传了图、是不是太大 -
FileReader.readAsDataURL()适合小图预览，大图（比如 4MB）可能卡顿甚至内存溢出 - 更稳妥的做法是
FileReader.readAsArrayBuffer()+ 后端接收二进制流，或转成Blob用fetch直传 - 注意：iOS Safari 拍照后
File的lastModified可能不准，别拿它做唯一性判断
上传前要不要压缩图片
要，尤其面向移动端。原图动辄 2–5MB，上传慢、失败率高、还吃用户流量。但压缩逻辑不能只靠前端，得留后路——后端必须能处理未压缩图，否则 iOS 用户禁用 JS 就直接废了。
- 用
canvas.toBlob()压缩最可控，指定quality=0.8，类型设为"image/jpeg"（PNG 不支持 quality） - 别用
canvas.toDataURL()再转 blob——base64 解码浪费 CPU，且可能超内存 - 压缩前建议先等比缩放：按宽度 1200px 为上限，避免 canvas 渲染超限（Safari 对 canvas 尺寸有限制）
- Android 部分厂商浏览器（如华为、小米）的 canvas 实现有偏色 bug，压缩后颜色可能失真，需实机测试
form submit 时怎么防止重复提交或丢失文件
别用传统 <form></form> 提交带 input[type=file] 的表单。文件控件在 submit 过程中容易被清空，尤其页面跳转或刷新后。应该用 JS 拦截 submit，构造 FormData 手动发请求。
立即学习“前端免费学习笔记（深入）”；
-
event.preventDefault()必须加，否则页面跳走，JS 上传逻辑没机会执行 -
FormData.append("file", file)里的file就是前面e.target.files[0]拿到的那个对象 - 上传中禁用提交按钮，但记得用
button.disabled = true，而不是移除 click 事件——否则错误重试时按钮无法恢复 - 网络差时，用户可能反复点按钮，用节流或加 loading 状态锁住，避免并发多个相同请求
真正麻烦的不是调起摄像头，而是不同机型对 capture 的实现差异、iOS Safari 的 canvas 限制、还有微信里各种“我以为它支持”的坑。实测比查文档管用。
