快递单号匹配失败主因是原始数据未清洗，需入库前统一转大小写、去首尾空格及中间空白符，并建函数索引或存规范化值；正则仅初筛，关键校验须调用官方api；多单号场景优先用set去重；查无记录时应先判断lastupdatetime再决定是否轮询。
快递单号里混了空格或字母大小写，contains 查不到怎么办
字符串匹配失败，不是逻辑错，是原始数据没清洗。物流单号常被用户手输、OCR识别或从邮件粘贴进来，"SF123456789CN" 和 "sf123456789cn" 在 Java 或 Python 默认比较下就是两个不同字符串。
实操建议：
- 入库前统一转大写或小写，比如 Java 用
trackingNumber.toUpperCase()，Python 用tracking_number.upper() - 去首尾空格必须做，
trim()（Java）或strip()（Python）不能省；中间空格要视业务而定——顺丰单号不含空格，中通可能带分隔符，得先replaceAll("\s+", "")清掉所有空白符 - 别在查询时才做转换，否则索引失效：MySQL 对
UPPER(column)字段无法走普通 B-Tree 索引，应建函数索引或存规范化值
校验快递单号格式，光靠正则不够
正则能拦住明显乱输的单号，但拦不住“合法但无效”的号。比如圆通单号规则是 10–12 位数字，"1234567890" 符合正则，但未必真实存在；更麻烦的是，不同公司校验逻辑差异大：顺丰要校验末位校验码，EMS 用 Luhn 变种，京东用自定义加权算法。
实操建议：
- 基础层用正则初筛：
^SF\d{10,12}$（顺丰）、^YT\d{10,12}$（圆通），但仅作前端提示或日志告警 - 关键校验必须调用官方 API 或 SDK，比如用顺丰
sf-api-validate接口查单号结构有效性，而非自己实现校验码逻辑——他们改算法你不知道 - 对历史单号做批量校验时，避免单次请求一个号，用聚合接口（如中通
/batch/query）或本地缓存已知有效前缀（如申通常用STO+ 8 位数字）加速过滤
查“同一订单多个物流单号”，用 Set 去重比 List 安全
一个电商订单可能拆成多包裹发货，返回多个单号。如果用 List<string></string> 存，重复添加、顺序错乱、遍历时漏判都可能发生；更隐蔽的问题是，JSON 反序列化时若字段类型声明为 List，但接口实际返回对象数组（含额外字段），会静默失败或丢数据。
实操建议：
- 内部处理优先用
Set<string></string>（Java）或set()（Python），天然防重复，且contains平均 O(1)，比遍历List快 - 与外部系统交互时，明确约定字段类型：API 文档写死
"tracking_numbers": ["SF123...", "YT456..."]，后端反序列化用Set类型接收（Jackson 注解@JsonDeserialize(as = LinkedHashSet.class)） - 注意
HashSet不保序，如需按添加顺序迭代，改用LinkedHashSet；Python 中dict.fromkeys(...).keys()是 3.7+ 保序替代方案
查不到物流记录，别急着重试——先看 lastUpdateTime 时间戳
很多系统一查无结果就立刻轮询，反而触发风控限流。实际上，快递单号生成后，物流信息往往延迟 15–30 分钟才写入公网接口；更常见的是，单号已揽收但还没扫出第一条轨迹，status 字段为空或为 "not_found"，但 lastUpdateTime 是 2 小时前，说明根本没新数据进来了。
实操建议：
- 每次查询响应必读
lastUpdateTime或update_time字段，时间差超过 1 小时就停轮询，避免空跑 - 服务端缓存应带 TTL，但 TTL 不能简单设固定值——刚下单的单号缓存 5 分钟，24 小时未更新的单号缓存可延长到 2 小时，用滑动窗口控制
- 客户端展示时，别只显示“暂无物流”，补一句“最后更新于
2024-04-05T14:22:01Z”，用户自己能判断是否该等
单号校验和集合查询看着简单，真正卡住人的永远是边界：OCR 识别错一位、API 返回字段名大小写不一致、缓存没随状态变更失效。这些地方不写死逻辑，就得靠日志里那条真实的 lastUpdateTime 值说话。
