定位当前城市并获取天气信息，这个需求看起来简单到几乎不值一提——调个定位接口，再调个天气接口，拼起来不就完了？但我前后做过四五个涉及定位加天气的小项目，从移动端页面到桌面小工具都试过，真正落地时踩的坑远比想象中多。定位不准导致天气查错城市、用户拒绝授权后整个功能直接瘫痪、不同平台坐标系不统一导致返回的位置偏移几百米、天气接口返回的数据结构跟文档写的完全对不上……这些问题在Demo阶段根本暴露不出来，只有真正跑在用户设备上才会一个个冒出来。

这篇文章面向的是有一定前端或全栈基础、想把这个功能做扎实的开发者。我会从定位方案选型、坐标系处理、天气数据获取与解析、异常兜底策略几个维度，把整个链路拆开讲清楚。不管你是做移动端H5、小程序还是桌面端应用，核心思路是通用的，区别只在于具体API的调用方式。读完你至少能搞清楚三件事：怎么拿到靠谱的定位、怎么把定位转成天气查询需要的格式、以及当定位或天气接口出问题时怎么让功能不至于完全不可用。

1. 定位方案的选择远比你想的复杂

很多人一上来就想着用浏览器自带的Geolocation API，觉得一行代码就能拿到经纬度。确实，navigator.geolocation.getCurrentPosition用起来很简单，但实际项目中它的局限性非常明显。我先把几种常见定位方案摆出来对比一下，你就知道为什么不能无脑选一个了。

1.1 浏览器定位、IP定位与系统定位的适用边界

浏览器Geolocation API的底层实现其实取决于设备本身：手机浏览器会调用GPS或基站定位，桌面浏览器则通常依赖WiFi定位或IP定位。这意味着同一个API在不同设备上的精度差异极大——手机上可能精确到10米，桌面上可能偏差好几公里。而且这个API必须运行在HTTPS环境下，HTTP页面直接不可用，这一点在本地开发时经常被忽略。

IP定位是另一种常见方案，通过请求服务端接口，由服务端根据请求来源IP判断大致城市。它的优点是无需用户授权、不依赖设备硬件，缺点是精度只能到城市级别，而且如果用户用了代理或CDN，IP定位可能完全跑偏。我实测过几次，IP定位在城市级别的准确率大概在80%到90%之间，剩下的情况要么定位到相邻城市，要么直接定位到运营商机房所在的城市。

系统级定位（比如移动端原生App里的定位SDK）精度最高，但需要原生权限配合，纯Web场景用不了。所以选型逻辑很清晰：如果你做的是移动端H5且用户会开GPS，优先用浏览器Geolocation；如果只是想要一个大概的城市名，IP定位足够且体验更好（无需弹授权框）；如果两者都想兼顾，那就做降级策略——先尝试浏览器定位，失败或超时后自动回退到IP定位。

1.2 用户拒绝授权后的降级链路设计

这是最容易被忽视的场景。用户第一次打开页面，浏览器弹出定位授权请求，用户点了"拒绝"，然后呢？很多项目的做法是直接显示"定位失败"，整个天气功能就废了。正确的做法是设计一条完整的降级链路。

我的做法是这样的：第一优先级是浏览器Geolocation，设置5到8秒的超时时间；如果超时或被拒绝，第二优先级走IP定位接口；如果IP定位也失败（比如网络异常），第三优先级是读取本地缓存的上次定位城市；如果连缓存都没有，最后兜底给一个默认城市（比如根据页面语言或时区推断一个大致的城市）。这条链路确保任何情况下用户都能看到天气信息，只是精度不同而已。

注意：浏览器Geolocation的授权状态可以通过navigator.permissions.query({name: 'geolocation'})提前查询，这样你可以在用户点击"获取天气"按钮之前就知道授权状态，避免不必要的等待。但这个API在部分旧版浏览器上不支持，需要做兼容判断。

1.3 超时设置与精度参数的实战调优

Geolocation API的第三个参数是一个配置对象，包含enableHighAccuracy、timeout和maximumAge三个字段。这三个参数的设置直接影响用户体验，我逐个说。

enableHighAccuracy设为true时会强制使用GPS等高精度定位方式，代价是定位时间更长、耗电更多。在移动端H5场景下，如果你只是要定位到城市级别，完全没必要开高精度，设为false反而更快。我一般只在需要精确到街道的场景才开true。

timeout是超时时间，单位毫秒。设太短了定位还没完成就超时了，设太长了用户等得不耐烦。我的经验值是：高精度模式下设8000到10000毫秒，非高精度模式下设5000毫秒左右。这个值需要根据你的用户网络环境调整，如果用户主要在弱网环境下使用，适当放宽。

maximumAge表示接受的最大缓存时间，单位也是毫秒。设为0表示每次都重新定位，设为Infinity表示永远用缓存。实际项目中我一般设为5到10分钟，这样短时间内重复调用不会每次都触发定位，既省电又快。

const geoOptions = { enableHighAccuracy: false, timeout: 6000, maximumAge: 5 * 60 * 1000 }; navigator.geolocation.getCurrentPosition( (position) => { const { latitude, longitude, accuracy } = position.coords; console.log(`定位成功: ${latitude}, ${longitude}, 精度: ${accuracy}米`); }, (error) => { console.error(`定位失败: ${error.code} - ${error.message}`); }, geoOptions );

上面代码里的accuracy字段值得关注，它表示定位结果的精度半径（米）。如果这个值特别大（比如超过5000米），说明定位结果很不可靠，你可以选择忽略这次结果，走降级链路。

2. 坐标系不统一是定位偏移的元凶

拿到经纬度之后，很多人的第一反应是直接拿这个坐标去查天气。但这里有个隐藏问题：不同定位方式返回的坐标系可能不一样。如果你用浏览器Geolocation拿到的坐标去调某些国内地图服务，会发现位置偏了几百米甚至上千米。这不是bug，是坐标系标准不同导致的。

2.1 WGS84、GCJ02与BD09的关系梳理

目前常见的坐标系有三种。WGS84是国际标准，GPS设备原始输出的就是这套坐标，浏览器Geolocation API返回的也是WGS84。GCJ02是国内地图服务常用的加密坐标系，在WGS84基础上做了偏移处理。BD09则是在GCJ02基础上又做了一次偏移，是某地图服务专用的。

这三者之间的转换不是简单的线性偏移，而是有一套复杂的加密算法。好消息是，如果你只是做城市级别的天气查询，坐标系差异通常不会导致城市判断错误——几百米的偏移在城市尺度上可以忽略。但如果你需要根据定位结果反查具体区域名称（比如"某城市某区某街道"），那就必须做坐标系转换，否则反查出来的地址可能是隔壁街道的。

2.2 坐标转换的代码实现与精度验证

WGS84转GCJ02的算法是公开的，核心逻辑是一组三角函数计算。我直接给一个经过验证的实现：

const PI = Math.PI; const A = 6378245.0; const EE = 0.00669342162296594323; function outOfChina(lng, lat) { return lng < 72.004 || lng > 137.8347 || lat < 0.8293 || lat > 55.8271; } function transformLat(lng, lat) { let ret = -100.0 + 2.0 * lng + 3.0 * lat + 0.2 * lat * lat + 0.1 * lng * lat + 0.2 * Math.sqrt(Math.abs(lng)); ret += (20.0 * Math.sin(6.0 * lng * PI) + 20.0 * Math.sin(2.0 * lng * PI)) * 2.0 / 3.0; ret += (20.0 * Math.sin(lat * PI) + 40.0 * Math.sin(lat / 3.0 * PI)) * 2.0 / 3.0; ret += (160.0 * Math.sin(lat / 12.0 * PI) + 320 * Math.sin(lat * PI / 30.0)) * 2.0 / 3.0; return ret; } function transformLng(lng, lat) { let ret = 300.0 + lng + 2.0 * lat + 0.1 * lng * lng + 0.1 * lng * lat + 0.1 * Math.sqrt(Math.abs(lng)); ret += (20.0 * Math.sin(6.0 * lng * PI) + 20.0 * Math.sin(2.0 * lng * PI)) * 2.0 / 3.0; ret += (20.0 * Math.sin(lng * PI) + 40.0 * Math.sin(lng / 3.0 * PI)) * 2.0 / 3.0; ret += (150.0 * Math.sin(lng / 12.0 * PI) + 300.0 * Math.sin(lng / 30.0 * PI)) * 2.0 / 3.0; return ret; } function wgs84ToGcj02(lng, lat) { if (outOfChina(lng, lat)) return [lng, lat]; let dLat = transformLat(lng - 105.0, lat - 35.0); let dLng = transformLng(lng - 105.0, lat - 35.0); const radLat = lat / 180.0 * PI; let magic = Math.sin(radLat); magic = 1 - EE * magic * magic; const sqrtMagic = Math.sqrt(magic); dLat = (dLat * 180.0) / ((A * (1 - EE)) / (magic * sqrtMagic) * PI); dLng = (dLng * 180.0) / (A / sqrtMagic * Math.cos(radLat) * PI); return [lng + dLng, lat + dLat]; }

这段代码我用了很多次，转换精度在米级别，完全够用。验证方法也很简单：拿一个已知地标的WGS84坐标转成GCJ02，然后在地图上标注，看是否落在正确位置。我一般会选两三个不同城市的坐标做交叉验证，确保算法没有边界问题。

2.3 什么时候可以跳过坐标转换

如果你的链路是"定位→拿城市名→查天气"，中间不涉及地图标注和地址反查，那坐标转换其实可以跳过。因为天气查询接口通常接受城市名或城市编码作为参数，你只需要把经纬度反查成城市名就行了，而反查服务本身会处理坐标系问题。

但如果你用的是"定位→拿经纬度→直接调天气接口（传经纬度）"这种链路，就要注意天气服务商要求的是哪种坐标系。有些服务商明确要求传GCJ02坐标，你传WGS84进去，虽然大部分情况下还是能返回正确城市的天气，但在城市边界区域可能返回隔壁城市的天气。这种边界case很难测试，但用户投诉的时候你就知道痛了。

3. 天气数据的获取、解析与缓存策略

定位搞定之后，天气数据的获取看起来就简单了——调接口、拿数据、渲染页面。但实际做下来，数据解析和缓存这两块有很多细节值得说。

3.1 免费天气接口的选型对比与踩坑记录

市面上的天气接口大致分两类：一类是免费额度有限的商业API，另一类是开源社区维护的免费接口。商业API的优点是数据稳定、文档清晰、有SLA保障，缺点是免费额度用完后要付费。开源接口的优点是免费，缺点是稳定性没保障，说不定哪天就挂了。

我早期用过几个开源天气接口，踩过的坑包括：接口突然返回HTML而不是JSON（说明服务挂了或者被重定向了）、数据更新延迟好几个小时、字段名悄悄改了导致解析报错。后来我学乖了，不管用哪个接口，都要做三件事：第一，对返回数据做严格的格式校验，字段缺失或类型不对时走兜底逻辑；第二，加一层缓存，接口挂了就用缓存数据；第三，准备一个备用接口，主接口连续失败N次后自动切换。

选型的时候重点看几个指标：更新频率（至少每小时更新一次）、数据字段是否满足需求（温度、天气现象、风力、湿度、空气质量等）、是否有城市编码对照表、免费额度是否够用。我一般会同时接入两个接口做互备，主接口优先，失败时切备用。

3.2 从经纬度到城市名的反查方案

拿到经纬度后，需要反查成城市名才能查天气（除非天气接口直接支持经纬度查询）。反查方案有两种：一是调用地图服务商的反地理编码接口，二是用离线的城市坐标数据库做最近邻匹配。

在线反查的优点是准确、能拿到详细地址，缺点是需要网络请求、有调用次数限制。离线匹配的优点是快、无限制，缺点是精度有限（只能匹配到最近的城市中心点，边界区域可能匹配错）。我的做法是：优先用在线反查，失败时降级到离线匹配。

离线匹配的实现思路很简单：准备一份城市中心点坐标表，计算用户坐标到每个城市中心点的距离，取最近的那个。距离计算用Haversine公式：

function haversine(lat1, lng1, lat2, lng2) { const R = 6371; const dLat = (lat2 - lat1) * PI / 180; const dLng = (lng2 - lng1) * PI / 180; const a = Math.sin(dLat / 2) ** 2 + Math.cos(lat1 * PI / 180) * Math.cos(lat2 * PI / 180) * Math.sin(dLng / 2) ** 2; return R * 2 * Math.atan2(Math.sqrt(a), Math.sqrt(1 - a)); }

这份城市坐标表不需要很全，覆盖主要城市就行，大概几百条数据，压缩后也就几十KB，完全可以打包进前端代码里。

3.3 缓存层设计：减少接口调用与提升响应速度

天气数据不需要实时到秒级，通常每小时更新一次就够了。所以缓存策略很明确：按城市维度缓存，有效期设为30到60分钟。缓存可以放在三个地方：内存（当前会话有效）、localStorage（跨会话有效）、Service Worker（离线可用）。

我的做法是内存缓存加localStorage双层缓存。内存缓存用于当前页面会话内的快速读取，localStorage用于跨会话的持久化。读取逻辑是：先查内存，命中则直接返回；未命中则查localStorage，检查是否过期；未过期则返回并写入内存；已过期则发起网络请求，成功后更新两层缓存。

const CACHE_KEY_PREFIX = 'weather_'; const CACHE_TTL = 30 * 60 * 1000; function getCachedWeather(city) { const key = CACHE_KEY_PREFIX + city; const raw = localStorage.getItem(key); if (!raw) return null; try { const { data, timestamp } = JSON.parse(raw); if (Date.now() - timestamp > CACHE_TTL) { localStorage.removeItem(key); return null; } return data; } catch (e) { localStorage.removeItem(key); return null; } } function setCachedWeather(city, data) { const key = CACHE_KEY_PREFIX + city; localStorage.setItem(key, JSON.stringify({ data, timestamp: Date.now() })); }

注意：localStorage有容量限制（通常5MB左右），如果缓存的城市太多可能写满。建议加一个清理逻辑，定期删除过期缓存，或者限制最多缓存N个城市。

4. 异常兜底与用户体验的细节打磨

功能能跑通只是第一步，真正决定用户体验的是异常情况下的表现。定位失败、天气接口超时、数据格式异常——这些情况在实际使用中出现的频率远比开发者想象的高。

4.1 定位失败时的用户引导与手动切换

定位失败后，除了自动降级到IP定位，还应该给用户一个手动选择城市的入口。这个入口不需要很显眼，但一定要有。我的做法是在天气卡片下方放一个"切换城市"的链接，点击后弹出一个城市搜索框，用户可以手动输入城市名。

手动选择的城市应该被记住，下次打开时优先使用手动选择的城市而不是自动定位。这需要在localStorage里存一个"用户偏好城市"的标记，自动定位只在用户没有手动选择过城市时才生效。这个逻辑看似简单，但很多项目都忽略了，导致用户每次打开都要重新定位，体验很差。

另外，定位过程中要有明确的加载状态提示。不要只显示一个转圈图标，最好配上文字说明"正在获取您的位置…"，让用户知道系统在做什么。如果定位时间超过3秒，可以追加提示"定位较慢，您可以手动选择城市"，给用户一个退出的选项。

4.2 天气接口超时与数据异常的容错处理

天气接口的异常分几种情况：网络超时、返回非200状态码、返回数据格式不符合预期、返回数据字段缺失。每种情况的处理方式不同。

网络超时和状态码异常比较好处理，直接走重试逻辑或切换到备用接口。数据格式异常和字段缺失比较隐蔽，需要做防御性解析。我的做法是写一个数据校验函数，对每个必需字段做类型和范围检查，任何字段不合法就认为整条数据不可用，走缓存或兜底。

function validateWeatherData(data) { if (!data || typeof data !== 'object') return false; const required = ['temperature', 'weather', 'windSpeed', 'humidity']; for (const field of required) { if (data[field] === undefined || data[field] === null) return false; } if (typeof data.temperature !== 'number' || data.temperature < -100 || data.temperature > 100) { return false; } if (typeof data.humidity !== 'number' || data.humidity < 0 || data.humidity > 100) { return false; } return true; }

这个校验函数看起来有点啰嗦，但它能拦住90%以上的脏数据问题。我遇到过接口返回温度值为null、湿度为字符串"N/A"、风力为负数等各种奇葩情况，有了校验函数之后，这些问题都能被优雅地处理掉。

4.3 加载状态、错误提示与重试机制的设计

加载状态的设计原则是：让用户始终知道当前发生了什么。我一般分三种状态：加载中、加载成功、加载失败。加载中显示骨架屏或加载动画，加载成功显示数据，加载失败显示错误提示和重试按钮。

重试机制要注意避免无限重试。我的做法是最多重试2次，每次间隔递增（第一次1秒，第二次3秒），两次都失败就显示错误提示，让用户手动点击重试。同时要区分可重试错误和不可重试错误——网络超时可以重试，但如果是接口返回了明确的错误码（比如"城市不存在"），重试也没用，应该直接提示用户。

错误提示的文案也很重要。不要显示"Error 500"这种技术性描述，要用人话告诉用户发生了什么以及可以怎么做。比如"天气信息暂时获取不到，请检查网络后重试"就比"请求失败"好得多。如果是因为定位失败导致的，提示"无法获取您的位置，您可以手动选择城市"并附上切换城市的入口。

4.4 离线场景下的数据可用性保障

用户在地铁、电梯等弱网环境下打开页面时，网络请求可能直接失败。这时候如果之前缓存过天气数据，应该直接展示缓存数据，并标注"数据更新时间：XX分钟前"。如果连缓存都没有，就显示一个友好的空状态页面，而不是白屏或报错。

Service Worker可以实现真正的离线可用，但接入成本较高，适合对离线体验有要求的项目。如果不想引入Service Worker，至少要做好localStorage缓存和网络状态检测。navigator.onLine可以检测当前是否在线，结合online和offline事件可以实时响应网络状态变化。

window.addEventListener('offline', () => { showOfflineBanner('当前网络不可用，显示的是缓存数据'); }); window.addEventListener('online', () => { hideOfflineBanner(); refreshWeather(); });

这套机制加上之后，用户在弱网环境下的体验会好很多。我实测过，在地铁里打开页面，有缓存的情况下几乎秒开，没有缓存才会显示加载失败。

5. 从Demo到生产：那些只有上线后才知道的事

前面讲的都是技术层面的东西，这一节我想聊聊实际部署和运营中遇到的一些问题，这些经验在开发阶段很难获得，但对项目的长期稳定运行至关重要。

5.1 不同设备和浏览器的兼容性差异

浏览器Geolocation API在不同设备上的表现差异很大。我在测试中发现，某些安卓设备上enableHighAccuracy: true会导致定位超时，改成false就正常了。某些iOS设备上首次调用定位会弹两次授权框（一次是浏览器的，一次是系统的），用户容易困惑。桌面端Chrome的定位精度普遍较差，经常定位到城市边缘甚至隔壁城市。

应对策略是：针对不同平台做差异化配置。移动端可以适当放宽超时时间，桌面端优先使用IP定位而不是浏览器定位。同时要做好UA检测，对不同浏览器做针对性处理。这些兼容性问题没有统一的解决方案，只能通过大量测试积累经验。

5.2 接口调用频率控制与成本优化

如果你用的是商业天气API，调用次数直接关系到成本。一个日活一万的应用，如果每个用户每次打开都调一次天气接口，一天就是几万次调用。通过合理的缓存策略，这个数字可以降低到几千次甚至几百次。

我的优化经验是：第一，缓存时间设为30到60分钟，同一城市在缓存期内只调一次接口；第二，多个用户查询同一城市时共享缓存（如果缓存放在服务端的话）；第三，非活跃用户不主动刷新天气，只在用户主动打开页面时才检查是否需要更新。这三条加起来，接口调用量能降低90%以上。

另外要注意接口的QPS限制。有些免费接口限制每秒最多调用N次，如果你的应用并发量较大，需要在服务端做请求队列和限流，避免触发接口的频率限制导致被封。

5.3 用户隐私与定位权限的合规处理

定位信息属于个人敏感信息，在采集和使用时需要特别注意合规问题。首先，必须在用户明确同意后才能获取定位，不能默认开启。其次，要明确告知用户定位信息的用途（比如"用于获取您所在城市的天气"），不能含糊其辞。第三，定位信息用完即弃，不要长期存储用户的精确坐标。

在技术实现上，建议只存储城市级别的定位结果，不存储精确经纬度。如果业务确实需要存储经纬度，应该做脱敏处理（比如降低精度到小数点后两位）。同时要提供关闭定位的选项，让用户可以手动选择城市而不必授权定位。

注意：不同平台对定位权限的合规要求不同，移动端App和小程序有各自的规范，Web端相对宽松但也有基本要求。上线前务必仔细阅读目标平台的隐私政策规范，避免因合规问题被下架或处罚。

5.4 监控与日志：定位成功率与接口可用性追踪

上线之后你需要知道定位成功率和天气接口的可用性，否则出了问题只能等用户投诉。我的做法是在关键节点打点上报：定位开始、定位成功（附带精度和耗时）、定位失败（附带错误码）、天气接口请求开始、请求成功（附带耗时）、请求失败（附带状态码）。

这些数据上报到服务端后，可以做几个关键指标的监控看板：定位成功率（目标95%以上）、平均定位耗时（目标3秒以内）、天气接口成功率（目标99%以上）、缓存命中率（目标80%以上）。任何一个指标异常时触发告警，这样就能在用户大规模投诉之前发现问题。

日志上报要注意不要采集用户的精确坐标，只上报城市级别和成功/失败状态即可。同时要控制上报频率，避免日志量过大导致存储成本飙升。

这套定位加天气的功能，我从最初觉得"这有什么难的"到后来踩了无数坑才做稳定，前后经历了大概两三个月的时间。最深的体会是：越是看起来简单的功能，越需要在异常处理和边界情况上下功夫。用户不会因为你正常流程跑得顺畅而夸奖你，但一定会因为定位不准或天气查不到而骂你。把降级链路做完整、把缓存做扎实、把错误提示写清楚，这个功能才算真正做好了。