sublime text 仅是文本编辑器，无法运行物流查询系统；实时同步依赖外部python/node.js服务，其作用限于编辑源码、查看配置、搜索日志。
Sublime Text 本身不支持运行物流查询系统，也不能直接联动多接口或实时同步状态——它只是个文本编辑器，不是运行环境。
为什么不能在 Sublime 里直接开发物流查询“系统”
常见误解是把编辑器当 IDE 或后端服务。Sublime Text 没有内置 HTTP 客户端、无进程管理、不提供定时轮询、无法持久化状态、也不支持 WebSocket 或长连接。所谓“实时同步”，实际依赖外部程序（如 Python 脚本、Node.js 服务）完成请求、解析、存储和推送。
你在 Sublime 里能做的，仅限于：
– 编辑 query.py 或 express-api.js 源码
– 查看 config.json 配置多个快递公司 API 的 base_url 和 app_key
– 快速搜索日志中的 "401 Unauthorized" 或 "tracking_number not found" 错误
真正起作用的其实是配套脚本：用 Python 做多接口切换
物流查询必须兼容顺丰、中通、圆通等不同接口规范（参数名、签名方式、返回结构差异大）。硬编码调用某一家会卡死整个流程。
- 用字典映射不同服务商：
PROVIDERS = {"sf": SFClient, "zto": ZTOClient, "yto": YTOClient} - 根据单号前缀自动路由：
if tracking_no.startswith("SF"):→ 走SFClient - 失败时降级重试另一家：
fallback_provider = "zto" if current == "sf" else "yto" - 注意中通返回的
data.list是数组，而顺丰返回的data.traces是对象，解析前必须先isinstance(data.get("list"), list)
状态实时同步靠的是外部机制，不是 Sublime
用户看到的“已签收”“派件中”刷新，背后通常是：
– 后端用 APScheduler 每 3 分钟轮询一次 /api/v1/track?no=SF123456789
– 前端通过 EventSource 订阅 /stream?tracking_no=SF123456789
– 状态变更时写入 sqlite3 表 tracking_history，并触发 UPDATE 通知
Sublime 唯一能帮上忙的，是打开 logs/tracking_worker.log 实时监控轮询是否卡在 requests.exceptions.Timeout，或发现某家接口突然开始返回 "code": 50012（圆通的“查得太频繁”错误码）。
别忽略时间与缓存带来的隐性问题
快递状态不是线性更新的，同一单号在不同接口返回的时间戳可能差 10 分钟；缓存策略不当会导致前端看到过期的“运输中”，而实际已签收。
- 所有响应必须带
ETag或X-Last-Update头，避免重复拉取 - 本地缓存用
shelve或diskcache，不要用内存 dict —— 重启就丢 - 时间比对要用 UTC：
datetime.fromisoformat("2024-06-12T14:22:03+08:00").astimezone(timezone.utc) - 测试时手动改系统时间会导致
time.time()和接口返回时间错位，务必关掉 NTP 同步再调试
真正难的从来不是写几行请求代码，而是处理各家接口文档没写的边界：比如韵达把“客户拒收”归类为 status: "signfail"，而申通写成 status: "refuse"，字段名不统一，连枚举值都要人工对齐。
