台风“紫檀”预警推送背后：高精度IP定位如何锁定受灾区域人群

原创

用户12496147

发布于 2026-08-27 14:08:49

360

8月26日凌晨3点25分，台风“紫檀”在广东徐闻第二次登陆；上午11点，又在吴川完成第三次登陆。同一时间，强台风“沙德尔”（14级，42米/秒）正位于东海，预计27日夜间到28日上午在浙江象山到福建连江一带沿海登陆。中央气象台一天连发台风、暴雨、山洪、地质灾害等六个预警。

你手机上收到的那条预警短信，早就不搞全省群发了。它只发给了台风影响范围内的人。

从群发到靶向，中间差了什么

甘肃去年做过一次实战推送：陇南武都区发布暴雨红色预警时，系统只向五马、枫相、洛塘三个乡镇的47012名用户发送，同区县其他乡镇不收，隔壁县市也不收。陕西气象部门今年8月刚完成靶向发布系统的采购，技术要求写得很细：基于基站电子围栏划定发布区域，区分常驻用户和漫游用户，用户位置模型每10分钟更新一次，红色预警要在40分钟内送达90%以上的目标人群。

这套逻辑拆开看就三步：圈定地理围栏，识别区域内的人，只向他们推送。基站定位解决了“这个人此刻在哪个网格”的问题，但对互联网产品来说还有另一条路。用户打开App、请求到达服务器的瞬间，IP地址已经在请求头里了。做一次ip地址精准位置查询，拿到用户所在区县，和台风影响区域清单做匹配，推送系统就知道这条预警该不该发给他。

对电商、出行这类没有基站数据可用的产品，这条路是唯一选择。台风天用户位置变化剧烈，人可能正从沿海往内陆转移，每次请求的IP都在变，查询必须做到城市级甚至区县级，粗到省份就没意义了。

移动网络的坑：跨城IP怎么办

这里有个绕不开的麻烦。手机4G/5G网络下，运营商普遍使用CGNAT技术，一个公网IP被数千用户共享，IP归属地注册地可能是运营商出口所在城市，不是用户实际位置。人在宁波，IP可能显示杭州。做ip地址精准位置查询时，这类偏差得心里有数。

实践中一般多信号一起用：IP归属地定大方向，浏览器时区、语言设置做二次确认，两者打架就降级处理。青海的预警体系用的是类似思路，气象预警区域数据和人口分布数据结合生成受众清单，单一信号不可靠就用多信号兜底。

代码怎么落地

以IP数据云的查询接口为例，拿到用户IP后判断是否落在台风影响区县清单内：

python
import requests
# 台风"沙德尔"预计登陆浙闽沿海，高风险区县清单
risk_zones = ["浙江宁波市象山县", "浙江台州市", "福建福州市连江县", "福建宁德市"]
def should_alert(ip, api_key):
 url = "https://api.ipdatacloud.com/v2/query"
 params = {"ip": ip, "key": api_key}
 resp = requests.get(url, params=params, timeout=2)
 data = resp.json()
 if data.get("code") == 200:
 info = data.get("data", {})
 location = f"{info.get('province')}{info.get('city')}{info.get('district', '')}"
 for zone in risk_zones:
 if zone in location:
 return {"ip": ip, "location": location, "alert": True}
 return {"ip": ip, "location": location, "alert": False}
# 只向命中高风险区域的用户推送预警
user_ips = ["113.x.x.x", "220.x.x.x", "36.x.x.x"]for ip in user_ips:
 result = should_alert(ip, "你的key")
 if result["alert"]:
 push_typhoon_warning(ip)

高精度ip地址查询的延迟要压在毫秒级。台风登陆前的黄金窗口就那几个小时，定位慢一秒，推送链路就多一秒延迟。青海把短信通道从150条/分钟扩到1700条/分钟，效率提升10倍多，为的就是链路上每一环都不拖后腿。