uni.chooseVideo在App端仅支持选择视频，不支持录制；录制必须用uni.createCameraContext，并通过uni.compressVideo压缩，其bitRate建议1000000～3000000，resolution设"720p"更优。
uni-app 的 uni.chooseVideo 在 App 端不支持录制，必须用 uni.createCameraContext
App 端（iOS/Android）无法通过 uni.chooseVideo 调起带录制功能的系统相册面板——它在 App 平台只支持「选择已有视频」，点击录制会静默失败或直接跳过。真正能调起摄像头并控制录制的，只有 uni.createCameraContext，且仅在 App 和小程序端可用（H5 不支持）。注意：camera 组件必须设置 device-position 和 flash 属性才可能正常初始化，否则 startRecord 会报错 camera context not ready。
App 端录制后如何压缩？不能依赖前端 JS 解码，得走原生层
Web 端可用 ffmpeg.wasm 或 MediaRecorder 做轻量压缩，但 App 端（尤其 iOS）对 MediaRecorder 支持极差，且 JS 解码大视频极易卡死或内存溢出。正确路径是：录制完立刻调用 uni.compressVideo（仅 App 支持），它底层调用原生 SDK（AVFoundation / MediaCodec），可控性强、速度快、不崩溃。
-
uni.compressVideo的bitRate推荐设为1000000～3000000（1～3 Mbps），低于 800000 容易糊；resolution设"720p"比"1080p"体积小 40%+，画质损失可接受 - 别在
success回调里再读取压缩后文件——tempFilePath是本地沙盒路径，直接传给上传接口即可；若手动uni.getFileInfo反而多一次 IO - Android 旧机型（如 Android 6）可能不支持
uni.compressVideo，需兜底：捕获fail后降级为不压缩，或提示用户升级系统
camera 组件参数和 CameraContext 方法的坑点清单
App 端 camera 行为和微信小程序差异大，很多参数实际无效或触发异常：
-
mode="video"必须显式设置，否则即使调用startRecord也会无反应（iOS 尤其严格） -
frame-size属性在 App 端被忽略，分辨率由原生 SDK 自动匹配，想控画质只能靠后续压缩 -
startRecord的duration参数在 Android 上常失效，建议用setTimeout主动调stopRecord，并监听onStopRecord回调确认结束 - 连续调用两次
startRecord不会覆盖前一次，而是抛错recording is already in progress，务必加状态锁（如isRecording = true）
真机调试时视频路径权限和生命周期问题
App 端录制生成的临时路径（如 _www/.../xxx.mp4）不是标准 file://，而是 file:///var/mobile/Containers/Data/Application/.../tmp/xxx.mp4 这类沙盒路径。常见翻车点：
- 用
uni.uploadFile上传时，filePath必须原样传入，不能拼接file://前缀，否则安卓报错file not found - App 切后台再切回前台，
camera组件可能黑屏或失焦，需监听onHide/onShow，在onShow中调用resumePreview（如果存在该方法）或重新创建cameraContext - iOS 15+ 对后台录制限制更严，若用户按 Home 键，
onStopRecord可能延迟数秒才触发，甚至丢失最后一段画面——业务上应避免引导用户边录边切后台
压缩和录制逻辑耦合度高，别把压缩塞进组件的 onStopRecord 里同步执行；先拿到原始路径，再异步调 uni.compressVideo，留出错误重试空间。
