在很多业务里，用户上传的并不是详细地址，而是一组经纬度。比如外勤打卡、物流轨迹、设备定位、地图标注、风控分析、LBS 推荐、乡镇级数据统计等场景，系统真正需要的往往不是"坐标"，而是"这个点属于哪个国家、哪个省、哪个市、哪个县，以及更细的名称"。这正是逆地理编码要解决的问题。
https://geocode.com.cn 提供的就是这样一个简单直接、响应快速的逆地理编码服务。你只需要传入经纬度，就能得到对应的行政区划信息，适合对性能、稳定性和接口简洁度有明确要求的项目。
它能做什么
geocode.com.cn 目前聚焦一件事：经纬度反查行政区划。
调用方式非常直接：
text
GET https://geocode.com.cn/?lat=39.9042&lon=116.4074返回结果是一个紧凑数组，例如：
json
["CN","北京市","","东城区","Beijing"]数组字段顺序固定为：
cc：国家代码admin1：省admin2：市xian：县name：名称（数据源name列）
这种返回格式有一个很实际的好处：短、小、快。对于高频请求、批量查询、服务间调用、边缘节点转发、移动端接口压缩等场景，这种设计比冗长 JSON 对象更省流量，也更容易做高性能处理。
为什么值得用
1. 接口简单
没有复杂参数，没有多余层级，没有一堆可选字段。只做经纬度查询行政区划，接口足够清晰，接入成本低。
2. 返回结果紧凑
很多在线地理编码接口默认返回大对象，字段多、体积大、解析慢。geocode.com.cn 直接返回固定顺序数组，更适合程序直接消费。
3. 适合高并发场景
如果你的业务是轨迹分析、批量地址归属、定位纠偏、设备上报清洗、地图点位落区，接口吞吐和响应时间通常比"花哨功能"更重要。geocode.com.cn 的定位很明确，就是把逆地理编码这件事做得更轻、更快。
4. 可直达中国行政区划细粒度信息
很多场景并不满足于"省市"级别，而是还需要区县以及更细粒度的名称信息。例如：
- 外卖或配送系统判断服务范围
- 运营系统按乡镇做用户覆盖分析
- 风控系统识别定位归属地
- 本地生活服务做区域投放
- 设备管理平台做网格化展示
对这类需求来说，直接返回省、市、县和名称字段，会比只给城市名称更有实际价值。
适合哪些业务场景
- 地图应用：把用户坐标转成行政区划标签
- 物流平台：根据定位点判断省市县归属
- 外勤系统：对打卡位置做区域归档
- 物联网平台：为设备定位自动补全地区信息
- 数据分析：把轨迹点批量映射到行政区划维度
- 本地生活：按区县、街道做服务覆盖判断
- 政企项目：用于县乡级地理归属分析
如果你的系统每天要处理大量坐标点，而且更关心结果可用性和响应效率，那么这种专注型接口会比"大而全"的地图服务更实用。
接入成本低，调试也方便
你可以直接在浏览器里测试，也可以用 curl 调试：
bash
curl "https://geocode.com.cn/?lat=34.92889&lon=116.46528"对于后端服务、脚本、爬虫、ETL 任务、数据补全程序来说，这种标准 HTTP GET 接口非常容易集成。无论你用的是 Go、Python、Node.js、Java、PHP，接起来都很直接。
一个更适合程序消费的逆地理编码接口
很多地理服务产品更偏向"地图展示"，而 geocode.com.cn 更像一个"可直接嵌入业务系统的地理能力接口"。它不强调复杂 UI，不强调重页面交互，而是强调：
- 输入简单
- 返回直接
- 字段固定
- 响应高效
- 更适合系统对系统调用
如果你正在做需要"坐标转行政区划"的项目，无论是内部系统、商业平台，还是数据处理工具，都可以直接试试：
对于追求实用、性能和低接入成本的团队来说，这类专注型服务往往更能解决真实业务问题。