App端OCR必须通过原生层实现，JS层无法直接访问相机和AI能力；推荐使用uni-plugin-ocr等封装插件，注意权限配置、Android版本适配、结构化文本提取及表单状态解耦。
App端调用OCR识别文字必须走原生层，uni-app JS层无法直接访问相机+AI能力
uni-app 的 uni.chooseImage 或 uni.getSystemInfo 拿不到原始图像像素数据，更无法调用 iOS Vision / Android ML Kit 这类系统级 OCR；纯 JS 实现的 OCR（如 Tesseract.js）在 App 端性能极差、准确率低、不支持实时预览，实际不可用。
实操建议：
- 使用已封装好的原生插件，例如
uni-plugin-ocr（基于 iOS Vision + Android TextRecognition API）、或 DCloud 官方推荐的uni-ocr（需在 manifest.json 中配置原生插件） - 避免自己写
weex-module或uni-app native plugin，除非你熟悉 iOS Objective-C/Swift 和 Android Java/Kotlin 的 OCR 集成流程 - 插件调用前务必检查权限：
uni.authorize({scope: 'scope.camera'})，iOS 还需在info.plist加NSCameraUsageDescription
识别结果怎么映射到表单字段？别硬写正则，优先用结构化提取逻辑
OCR 返回的是文本块数组（textItems），每个含 text、bounds、confidence。直接对整段文本跑 /(姓名|Name)[:：]?\s*(\S+)/ 容易误匹配——比如“联系电话”被识别成“联系电活”，或身份证号跨行断裂。
实操建议：
- 按 y 坐标聚类分“行”，再按 x 坐标排序每行内的词块，还原阅读顺序
- 对关键字段（如“姓名”“身份证号”）做模糊关键词匹配 + 后续词块提取，用
String.prototype.includes()比正则更稳 - 身份证号优先用
/\d{17}[\dXx]/从所有文本中提取，再校验最后一位（Luhn 算法），比依赖位置更可靠 - 表单字段名和 OCR 关键词之间建个映射表，比如
{'name': ['姓名', 'Name', '客户姓名']}，方便后续多语言扩展
Android 上识别失败率高？重点查 targetSdkVersion 和相机权限粒度
Android 12+（targetSdkVersion >= 31）默认禁止后台启动 Activity，而部分 OCR 插件会跳转到系统相机页再回调，导致黑屏或静默失败；错误信息常见 ActivityNotFoundException 或 java.lang.SecurityException: Permission Denial。
实操建议：
- manifest.json 中确保
"android": { "targetSdkVersion": 30 }（暂不升级到 31+），或确认插件已适配 Android 12+ 的android:exported="true"声明 - 不要只申请
android.permission.CAMERA，还需显式申请android.permission.READ_MEDIA_IMAGES（Android 13+） - 真机测试务必用 release 包，debug 包可能因调试签名缺失某些系统能力调用权限
识别后自动填充但用户改了内容？得监听 input 变更并解耦状态
直接 this.form.name = ocrResult.name 后，用户手动修改表单，下次再识别就覆盖掉了——这不是“自动填充”，是“强制覆盖”。而且 Vue 的响应式更新在 onReady 阶段可能未就绪，导致赋值无效。
实操建议：
- 用
v-model绑定表单，识别成功后仅触发一次this.$nextTick(() => { this.form.name = ... }) - 加个标记位
isOcrFilled: { name: false, idCard: false }，每次填充只设true，用户输入后自动置false，避免二次干扰 - 如果表单有校验（如身份证号格式），填充后立刻调用
this.$refs.form.validateField('idCard')，别等提交时才报错
OCR 在 App 端不是“调个 API 就完事”，核心难点永远在：原生能力桥接是否稳定、文本结构还原是否鲁棒、权限和系统版本是否兜底。别指望一个插件解决所有场景，先跑通一张身份证识别，再扩展营业执照或银行卡。
