常见失败原因在于原始文本含空格、换行、中文标点、隐形字符等干扰，需先清洗再匹配；单号前缀与长度差异大，应多分支组合；需结合图像质量过滤、节流处理、API校验等提升鲁棒性。
uni-app里用正则提取物流单号的常见失败原因
直接拿淘宝/菜鸟的单号规则去套，大概率匹配不到——不是正则写错了，是单号本身没“露出来”。用户截图、粘贴的文字里常混着空格、换行、中文括号、冒号（如“单号：SF123456789CN”），甚至带二维码识别后的乱码。正则得先做清洗，再匹配，不能指望原始文本干净。
- 别一上来就写
/SF\d{10,15}/，先用.replace(/[\s\u3000\r\n]+/g, '')去掉全角空格和换行 - 中文标点要显式替换，比如把
：、（、）全转成英文对应符号，或直接在正则里加 Unicode 范围：[\uFF1A\uFF08\uFF09] - 顺丰、中通、圆通等单号长度和前缀差异大，别只盯一个模式；用
|分支组合更稳妥，例如：/(SF|SFEX|ZTO|YTO)\w{10,18}/i
uni-app中onCameraFrame处理扫码画面时怎么稳定抓单号
不是所有帧都适合识别——模糊、反光、倾斜角度大的画面，OCR 结果错乱，正则反而会从错误文本里“凑出”假单号。关键不在正则多强，而在过滤低质量输入。
- uni-app 的
onCameraFrame每秒触发多次，但真正需要分析的帧应满足：亮度 > 80、清晰度（可用拉普拉斯方差粗略判断）> 100，否则跳过 - 别每帧都跑正则，用节流（如 300ms 一次）+ 缓存上一次成功结果，避免抖动输出
- 识别到疑似单号后，立刻用
uni.showToast显示并暂停后续识别，防止连续弹窗；用户确认前不自动提交
为什么用input粘贴文本时正则总漏掉单号
用户从淘宝App复制订单页，实际粘贴的是富文本（带样式、隐藏字符、不可见分隔符），event.detail.value 看似是纯文本，实则含零宽空格（\u200B）、软连字符（\u00AD）等干扰符。
- 粘贴后第一时间用
.replace(/[\u200B-\u200D\uFEFF\u00AD]/g, '')清除隐形控制字符 - 淘宝订单页常把单号拆成两行显示（如“SF123456” + 换行 + “789CN”），需合并相邻行再匹配，不能只按行切分
- 部分安卓机型剪贴板会额外注入“来源应用”信息（如“来自 淘宝”），建议用
.replace(/来自\s*[^\s]+/, '')预清理
正则匹配后怎么验证单号是否真实有效
匹配只是第一步，很多伪造单号（如 SF11111111111）格式合法但校验失败。真正在意的不是“像不像”，而是“能不能查”。
- 别自己实现复杂校验算法（如顺丰的末位校验），直接调用物流平台开放API（如快递鸟、菜鸟裹裹）做轻量查询，返回
ResultCode === 200才算通过 - 前端不做最终校验，仅作快速过滤；后端必须二次校验，防止绕过
- 单号前缀和长度只是线索，同一前缀可能跨公司（如 ZTO 早期属中通，后期也用于宅急送），以 API 返回的
LogisticCode和EName字段为准
真正难的不是写出能匹配的正则，而是让正则在用户随手一拍、一粘、一截的混乱现实里，每次都能拿到那个“对的字符串”。边界情况比想象中多，比如微信聊天记录里的单号被自动转成超链接、iOS 复制时带 URL scheme、小程序内嵌 WebView 的剪贴板权限限制……这些不会报错，但会让识别率断崖下跌。
