天气 API 怎么接进物流 ETA、出行提醒和运营预警

很多团队第一次评估天气接口时，往往把它当成一个低门槛的“信息展示能力”。页面上能显示晴天、多云、温度区间，似乎任务就完成了。但真正把天气数据接进业务系统后，大家会很快发现，天气 API 的价值并不在“展示”，而在于它能不能参与业务判断。物流到货时间怎么调、出行提醒何时推、线下门店是否要做临时值班调整，这些决策都需要依赖稳定、结构清晰、更新及时的天气数据。

在物流场景里，天气 API 最常见的用法是参与 ETA 估算。很多配送系统已经会考虑路况、距离、仓配节点和骑手密度，但如果忽略强降雨、大风、暴雪或高温天气，模型给出来的 ETA 往往偏乐观。结果就是用户看到的到达时间和实际体验存在明显落差，投诉会直接上来。比较稳妥的做法，是把天气字段作为 ETA 模型的一类输入，而不是在出错后再补一个兜底提醒。

先明确天气接口在业务里扮演什么角色

天气数据大致可以分成三类用途。第一类是信息展示，比如首页的天气卡片、行程页的天气提示、城市服务页的实时天气。第二类是流程控制，比如下雨时调整预计送达时间、预警时暂停部分区域的闪送服务、极端天气时关闭户外活动报名。第三类是运营分析，比如统计某区域在连续高温天的订单波动，或者评估天气变化对退单率、履约率的影响。不同目标对应的数据粒度完全不同，不能只拿一份“未来 7 天天气”就试图覆盖全部需求。

如果是信息展示，常见字段包括温度、体感温度、天气现象、风力、湿度和空气质量。用户只关心理解成本低的内容，字段要少而准。如果是 ETA 或调度系统，小时级降水概率、降水量、风速、能见度、预警等级通常更有价值。如果是运营策略，除了实时和预报数据，历史天气记录也常常有用，因为它有助于和订单、转化、取消率等指标做关联分析。

物流 ETA 为什么不能只看今天会不会下雨

物流系统里最常见的误区，是把天气判断简化成“下雨 = 延迟，不下雨 = 正常”。现实场景比这复杂得多。小雨和暴雨对履约效率的影响完全不是一个量级，强风、低温结冰、沙尘、暴雪和高温同样会改变运输和派送节奏。更关键的是，同样是下雨，不同城市、不同片区、不同配送方式的影响也不同。城市快送、同城即时配送、干线物流的容忍度差异很大，天气接口只是输入源，业务规则还需要结合自身服务模型来定。

一套更可落地的做法，是先定义内部天气风险等级。例如把天气风险分成正常、轻度影响、中度影响和严重影响四档，再基于气象字段去映射等级。之后，ETA 引擎、通知中心和调度后台都消费同一套风险等级，而不是各自临时判断。这样做的好处是，一旦业务方要调策略，只需要改一处规则。天气接口本身负责提供稳定数据，业务系统负责把数据转成动作。

出行提醒和通知系统要控制“提醒密度”

天气数据接入出行场景时，另一个常见问题是消息打扰。很多应用拿到预警就推一条，拿到降温再推一条，结果用户一天收到几次天气通知，最后干脆全部关掉。真正有效的提醒，不是“知道得越多越好”，而是“在正确的时间告诉用户对决策真正有影响的信息”。例如航班、火车、长途自驾、景区预约这些场景，天气提示应该绑定具体行程节点，而不是单独做成一个噪音模块。

这类系统的关键不是天气字段多，而是规则设计是否克制。比如出发前 12 小时提示目的地暴雨、出发前 2 小时提示道路积水预警、抵达后提示温差较大需要增衣，这类提醒通常比单纯推送“今日多云转阴”更有价值。换句话说，天气接口只是原料，通知系统要把它翻译成行动建议，用户才会觉得有用。

运营预警最怕的是字段看起来很多，实际没人用

很多团队给运营后台接天气接口时，会把能拿到的字段一口气都展示出来，结果页面信息很全，但没有人真正依赖它做决策。运营同学关心的是“我现在要不要调整排班”“要不要提前补货”“要不要修改活动文案”“某区域是否需要临时关闭服务”，而不是所有气象指标本身。天气数据必须被转成业务视角，才会变成可执行的预警信息。

实际落地时，建议把运营页拆成两层。第一层是少量核心指标，例如今日是否有预警、未来 24 小时是否有明显降水、温度波动是否超阈值。第二层才是详细气象数据，供需要的人展开查看。这样页面不会变成纯信息堆砌，也更容易让不同岗位形成统一判断。

选天气接口时，不要只看文档里写了多少字段

天气 API 的差异往往不在文档，而在更新及时性、字段稳定性和区域覆盖。对接前最好先做一轮真实对比：同一个城市跑几天小时级数据，看预报更新时间是否稳定，极端天气时字段是否完整，错误码是不是清晰，接口超时率是否可接受。很多项目上线后出现问题，不是因为天气数据完全错误，而是因为偶发空值、字段解释不一致、异常情况没有稳定约定，导致业务系统误判。

如果你的业务已经明确要把天气接进 ETA、提醒或运营规则，而不是仅仅展示给用户，那么从一开始就应该选一套可长期接入的天气接口，而不是为了省事随便找一个试用版先顶上。后续一旦接入链路变长，再切源的成本会明显上升。

华霆数联的天气查询服务适合这类需要将天气数据嵌入业务流程的场景。它不是只给一个城市当前温度，而是可以作为物流 ETA、出行通知和运营预警的上游数据源来使用。若你正在做天气数据接入评估，可以先看服务说明和返回字段，再决定是否接入到内部规则系统。

工具对接实操：从选型到上线

curl -X POST "https://ai.huating-ai.cn/api/691" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
  "city": "杭州",
  "type": "forecast"
}'

const API_KEY = process.env.HUATING_API_KEY;
const API_URL = "https://ai.huating-ai.cn/api/691";

if (!API_KEY) {
  throw new Error("请先设置环境变量 HUATING_API_KEY");
}

async function queryWeather(city, type = "forecast") {
  const payload = {
    city,
    type
  };

  const res = await fetch(API_URL, {
    method: "POST",
    headers: {
      "Authorization": `Bearer ${API_KEY}`,
      "Content-Type": "application/json"
    },
    body: JSON.stringify(payload)
  });

  if (!res.ok) {
    throw new Error(`HTTP ${res.status}`);
  }

  const data = await res.json();
  if (data.code && data.code !== 200) {
    throw new Error(data.message || "API 调用失败");
  }

  return data.data || data;
}

queryWeather("杭州").then(console.log).catch(console.error);