企业官网建设流程全解析

简介：一份面向前端初学者与职校教师的《响应式网页开发实战》第5章“HTML5地理定位”教学教案，围绕Geolocation API展开，系统讲解getCurrentPosition、watchPosition两种定位方法，梳理GPS、Wi-Fi、基站等多源位置数据获取原理，并覆盖定位失败时的错误回调处理。教案重点结合百度地图JavaScript API，演示如何将经纬度坐标转换为地图上的可视化标记，帮助读者快速掌握“获取位置—展示位置”的完整链路。内容采用任务驱动式编排，每课包含教学导航、重难点分析、任务描述与实施步骤，可直接用于课堂讲授或自学演练。资源为单个PDF文件，大小约239KB，排版紧凑，适合打印或投屏。已有90人浏览学习，适合作为移动端定位开发入门课、响应式网页课程实训环节的配套资料，也可用于考前速览或教案参考。

1. 为什么响应式网页开发里，HTML5地理定位总在真机上翻车

响应式网页开发这门课，讲到第5章 HTML5地理定位时，课堂气氛一般会从“写页面”转成“调玄学”。明明同一套代码，笔记本上能拿到坐标，手机上要么权限弹窗点了允许后没反应，要么定位点漂到隔壁大楼的快递柜上。这份教案要解决的，不是让你多背几个 API，而是把定位从“能拿到坐标”推进到“能稳定落进响应式页面”。它会讲清楚浏览器定位的三条数据链路、getCurrentPosition 和 watchPosition 的取舍、三个必调参数、权限与降级边界，再附上真机调试里最容易翻车的五个场景。适合做响应式站点、混合 App 内嵌页的前端开发者，也适合想把这一章讲明白的前端讲师。

2. 先看懂 geolocation API：三个接口与一次授权

2.1 浏览器是怎么知道你在哪的：GPS、WiFi、基站三选一

很多人以为调了 navigator.geolocation，浏览器就真的“知道”你在哪。实际不是。浏览器自己不会装卫星天线，它只是向底层设备要位置，而底层设备给出位置的来源通常是三种：GPS 模块、WiFi 指纹、基站三角定位。GPS 精度最高，能到几米，但室内基本没信号，冷启动要等好几秒；WiFi 定位靠的是 MAC 地址与公开位置库比对，商场、写字楼里反而比 GPS 更稳，精度几十米；基站定位最粗糙，按小区扇区估，几百米到几公里都有可能。

这段背景不是考背诵，它直接决定了你怎么调 enableHighAccuracy。这个参数字面意思是“启用高精度”，实际上更接近“尽量用 GPS”。你把 enableHighAccuracy 设成 true，浏览器会优先唤醒 GPS，但 iPhone 上省电模式、Android 上厂商省电策略都可能把 GPS 关掉，最后回落到 WiFi 或者基站。所以不要看到精度参数就以为位置一定准，它只是“优先级”，不是“保证”。

HTML5 新增表单标签、视频倍速控制这些刚学过的内容，属于把浏览器能力开放给页面；地理定位也一样，它是 BOM 层的 API，不是表单的一部分。理解这一点，你就不会把定位逻辑写在 form 提交里。真正决定精度上限的，永远是设备当前愿意给浏览器哪种数据源。

2.2 getCurrentPosition 与 watchPosition：一次性与持续定位

geolocation 对象上有三个方法，第 5 章的教案里最容易被忽略的就是这个“三”。getCurrentPosition 拉一次坐标就返回，适合“查天气”“找附近的店”这种场景；watchPosition 注册一个持续监听，位置变化就回调，适合导航、运动轨迹、共享位置这类需要连续更新的场景；clearWatch 负责取消监听，传进去的是 watchPosition 返回的 watchId。

选谁不选谁，先看耗电和频率。watchPosition 在手机浏览器里不是匀速回调，它是“发现位置变了才汇报”。但底层拿到一次 GPS 修复可能要几秒，期间设备高频搜索卫星，电量和流量都在烧。做页面的时候，能不用 watchPosition 就别用；非用不可，页面隐藏时立刻 clearWatch。很多前端工程师在响应式页面里挂了个 watchPosition，然后用户切后台再回来，发现位置停在半小时前，以为是 API 挂了——其实是浏览器为了省电暂停了回调，重新切回前台后才恢复。

另外一个容易漏掉的细节：getCurrentPosition 的回调一定是在页面生命周期里的某个异步时机触发，不要在页面 onload 里同步代码后面直接依赖坐标值。你拿不到坐标，不代表定位失败，可能是用户还没决定要不要允许权限。

2.3 拿坐标的最小代码：先跑通再谈精度

教学里我一般让学生先写最小 demo，不接任何业务逻辑，跑通了再往响应式页面里塞。

function getPos() { if (!navigator.geolocation) { console.error('当前浏览器不支持地理定位'); return; } navigator.geolocation.getCurrentPosition(showPos, showErr, { enableHighAccuracy: true, // 优先用 GPS，室内可能更慢 timeout: 10000, // 10 秒拿不到就触发错误回调 maximumAge: 60000 // 允许使用 1 分钟内缓存的旧坐标 }); } function showPos(pos) { const c = pos.coords; console.log('纬度', c.latitude); console.log('经度', c.longitude); console.log('精度(米)', c.accuracy); console.log('时间戳', pos.timestamp); } function showErr(err) { console.log('错误码', err.code); // 1 权限拒绝 2 不可用 3 超时 console.log('错误信息', err.message); }

这段代码里的四个字段是定位调试的地基。latitude 和 longitude 是 WGS84 坐标系，直接可用于网页地图；accuracy 表示坐标的“水平精度半径”，单位米，不是误差绝对值；timestamp 是坐标生成时间，不是回调时间；position 对象里还可能有 altitude、speed、heading，但桌面浏览器里经常是 null，千万别直接拿去算。

timeout 这个参数最容易拍脑袋。设成 3000，室内 WiFi 定位还没返回就先超时；设成 30000，用户拒绝权限时错误回调也要拖很久。我的经验是 8000 到 12000 之间，用户能感知到“在定位”，又不至于等太久。maximumAge 设成 0 代表必须拿新坐标，设成一个大值则可能拿到很老的位置。后面讲缓存时会专门说它。

下面是三个方法的对比，方便做课件或者快速决策：

3. 在响应式布局里接入定位：从坐标到可视区域的完整链路

3.1 移动端按压触发、桌面端页面加载触发：交互姿势不一样

把同一个定位按钮同时放到手机和桌面，看起来是响应式布局，实际交互逻辑完全不是一回事。桌面端浏览器权限弹窗相对温和，用户习惯页面一打开就被问“是否允许此网站获取位置”，所以很多桌面页在 load 事件里直接调 getCurrentPosition 是能跑的。在移动端你最好别这么干——竖屏页面刚加载，弹窗突然盖住半屏，多数用户的第一反应是拒绝。

我的做法是桌面端保留自动触发，移动端改成按压触发，或者至少等用户滚到定位卡片附近再请求。这不是 UI 风格问题，是权限通过率的取舍。一个很差但很常见的教训：移动端 headless 页面在首屏无交互直接弹权限框，拒绝率会明显变高。响应式开发里，交互姿势也要跟着断点变。

以 vw/vh 布局的位置卡片为例，用户在首页点一下“定位”，卡片先显示“正在获取位置”，拿到坐标后展示省市区，这个过程应该做到与地图供应商无关。第 5 章教案里如果只教“取经纬度”而不教“把经纬度变成人话”，那学生在真实项目里会卡在两难：直接给经纬度数字没人看得懂，对接地图 SDK 又绕不开密钥和配额。

3.2 三个必调参数：enableHighAccuracy、timeout、maximumAge 怎么设

前面说过这三个参数，这里给一份能直接抄的设定方案。enableHighAccuracy 在移动端设 true，桌面端可以设 false；如果业务只需要城市级别的位置，设 false 反而更快更省电。timeout 是“从发出请求到第一个坐标返回”的最长等待时间，我一般 from 8000 到 12000，如果超过 15 秒还没返回，基本是 GPS 冷启动加权限卡顿，用户早走了。maximumAge 允许浏览器复用缓存坐标，跑步打卡类页面设 0，天气类页面设 300000（5 分钟）不会有感知差异。

这里有一个“新手最容易理解偏”的点：maximumAge 是“允许接受多久之前的旧位置”，不代表“每隔多久获取一次”。所以它和“每 5 秒刷新坐标”是完全两件事。要持续刷新得用 watchPosition，或者自己 setInterval 包 getCurrentPosition。后者虽然土，但在低频刷新场景（每 30 秒）比 watchPosition 更可控，因为它是固定节拍的。

三个参数的推荐取值给一组参考表，真机实测时可以再微调：

3.3 把定位卡片融进 vw 布局：一段可复制的响应式接入代码

下面这段代码是我在教案第 5 章常用的版本。它不接地图 SDK，只演示“拿到坐标 → 显示状态 → 塞进响应式卡片”的完整链路。

<section class="location-card" id="locCard"> <button id="locBtn" type="button">定位</button> <p id="locStatus">尚未定位</p> <p id="locMeta"></p> </section>

.location-card { width: min(90vw, 420px); margin: 0 auto; padding: 2.4rem 1.6rem; border: 1px solid #ddd; border-radius: 1rem; background: #fafafa; } .location-card button { width: 100%; padding: 1.4rem 0; font-size: 1rem; } #locStatus { min-height: 1.6em; word-break: break-all; }

const btn = document.getElementById('locBtn'); const statusEl = document.getElementById('locStatus'); const metaEl = document.getElementById('locMeta'); btn.addEventListener('click', () => { if (!navigator.geolocation) { statusEl.textContent = '当前浏览器不支持定位'; return; } statusEl.textContent = '正在获取位置…'; navigator.geolocation.getCurrentPosition(success, error, { enableHighAccuracy: true, timeout: 10000, maximumAge: 0 }); }); function success(pos) { const lat = pos.coords.latitude.toFixed(5); const lng = pos.coords.longitude.toFixed(5); const acc = Math.round(pos.coords.accuracy); statusEl.textContent = `纬度 ${lat}，经度 ${lng}`; metaEl.textContent = `精度约 ${acc} 米`; } function error(err) { statusEl.textContent = err.code === 1 ? '用户拒绝了定位权限' : err.code === 3 ? '定位超时，请重试' : '暂时无法获取位置'; }

上面的代码有三个细节值得讲。第一，width 用 min(90vw, 420px) 而不是纯 100%，保证小屏有边距、大屏卡片不畸形，这是响应式布局里很实用的尺寸写法。第二，按钮点击后先写“正在获取位置…”，再等回调，避免用户反复点，如果你担心反复点，可以在 success/error 回调里给按钮状态加锁。第三，toFixed(5) 会截掉高精度小数，展示足够，但如果你要把坐标传给后端做范围匹配，不要用 toFixed 后的值，应该把完整的 coords.latitude 传走。

这里还会遇到“callback 没走”的情况。不是每个错误都会触发 error 回调，用户点掉权限弹窗不选、系统在低电量下挂起定位请求，都可能让回调永远不来。所以严谨一点要再加一个 setTimeout 兜底。这个兜底属于“定位 UI 防悬挂”的必修课，很多页面就是在这里少了根保险丝，导致 loading 转圈无限拉满。

4. 权限、降级与隐私：用户说“不允许”之后怎么办

4.1 HTTPS 与安全上下文：为什么预览地址拿不到定位

地理定位是浏览器的高权限 API，它被归在“安全上下文”的约束下。用 Chrome 打开一个 IP 地址的 HTTP 站点，navigator.geolocation 通常是 undefined，直接报“当前浏览器不支持地理定位”。不是老浏览器，而是浏览器故意不给。localhost 是本机回环，被当作可信地址放行，所以本地开发一切正常，一上内网测试机就凉。

这是响应式网页开发里最常见的误判之一。调试时先看两件事：页面地址是 https 还是 http，以及 navigator.geolocation 是否存在。如果是公司内网测试环境，没有 HTTPS 证书，可以在浏览器设置里把站点加入不安全来源的例外，但这是开发期方案，上不了生产。真正的解决路径是让测试环境挂合法证书或者用带 TLS 的隧道，没有别的后门。

还有一层是被忽略的“嵌套 iframe”限制。响应式页面喜欢用 iframe 嵌地图、嵌第三方组件，如果 iframe 的 src 不是安全上下文，或者没有配 Permissions-Policy 头，iframe 内部调 getCurrentPosition 会被父级策略挡住。控制台会给出明确的报错，但很多人误以为是自己代码写错，实际上是要在响应头里加允许声明，比如 Permissions-Policy: geolocation=(self "https://map.example.com")。这一条在混合 App 的 WebView 里尤其容易踩中。

4.2 用户拒绝授权后的降级链路

权限弹窗被拒绝，这是 100% 会发生的场景，教学设计里必须做降级。常见的降级链路有三层：第一层，页面提示用户“定位被拒绝”，并给一个引导按钮，点击后尝试再次调 getCurrentPosition；第二层，用 IP 归属地接口得到一个粗略的城市名，页面继续可用，只是定位精度变成城市级；第三层，让用户手输城市或从常用城市列表里选。

这三层不是随便设计的，每往下一层，业务承诺就要改一次。比如“找附近门店”，拒绝定位后还硬展示“附近”就是撒谎，应该改成“当前城市的门店”。代码上，error 回调的 code 是 1（PERMISSION_DENIED）时，不要反复空转调用 API，那会触发浏览器的“重复询问拦截”。最佳姿势是弹一个模态框告诉用户“为了帮你找附近门店，请允许定位”，同时给一个“手动选择城市”的按钮。

Chrome 里用户拒绝几次之后，地址栏右侧会出现一个带叉的小图标，那是把权限缓存住了。这时页面里的“重新授权”按钮并不能让弹窗再次出现，只能引导用户去浏览器设置或站点设置里改权限。移动端 Safari 类似，清掉站点数据之后权限才会重置。这是浏览器设计，不是 bug，别因为测试时点了几次拒绝就怀疑代码。

4.3 要不要缓存最后一次位置：maximumAge 与 localStorage 的权衡

很多后端同学会建议前端把最后一次坐标存到 localStorage，下次打开秒出定位。思路没错，但容易把坐标系和时效搞混。localStorage 存的是你自己炮制的缓存，maximumAge 管的是浏览器内部的定位缓存，两套机制是独立的。我把两类方案的边界写清楚，你按业务选：

我的建议是：不要拿 localStorage 里的坐标当“当前坐标”用，最多当“最近一次已知位置”。具体做法是存一个对象 { lat, lng, accuracy, timestamp }，读取时用 Date.now() - timestamp 判断新鲜度，超过 10 分钟的坐标直接废弃。这里面还要注意坐标坐标系，网页端一般拿的是 WGS84，如果后端要转 GCJ-02（国测局坐标）再落库，那是后端职责，前端不要自己套加密偏移，容易造成“页面显示和地图对不上”的乌龙。

还有一层隐私：用户定位数据属于敏感信息，教案里我会反复强调三条纪律。第一，只在用户触发定位动线后请求权限，不许开场三秒就弹；第二，拿到坐标后最小化使用，不做轨迹录像；第三，本地缓存必须可清、可主动销毁。这不只是合规姿势，也是申请应用商店审核时的底线。写进页面逻辑里的时间越早，后面改造成本越低。

5. 真机定位的五个典型翻车点与排查顺序

5.1 现象：模拟器一切正常，真机永远在转圈

模拟器里定位秒回，换到 Android 真机后 loading 无限转。原因通常是两个方向：一是测试环境不是 HTTPS，二是手机系统给浏览器的定位权限被关了。前者只影响网页，后者影响整个设备定位。Android 中浏览器应用需要同时具备“定位信息”和“地理位置”两类权限，很多国产 ROM 默认只给了前台权限、不给后台定位，导致页面在前台时也无法回调。

解决方式分步走：先在手机浏览器网页里开一个地图页，看能不能定位到自己的位置，如果地图也是转圈，说明是系统或者网络层面出问题；地图正常后再回到你的页面按 F12 远程调试，看控制台有没有 PERMISSION_DENIED。远程调试这一条是血泪经验，不要靠肉眼猜，直接 USB 连电脑，Chrome 上打开 chrome://inspect，看浏览器内页面的 console 和 network。

5.2 现象：拿到坐标了，但偏差三四百米

坐标成功返回，accuracy 显示几十米，但实际上人站在 A 路口，定位点落在 B 商场。这类偏差最容易被甩锅给前端，实际上多数是数据源降级。开启 enableHighAccuracy 后依然走到 WiFi 定位，周围 WiFi 数据库更新滞后，就会造成几百米的漂移。还有一种情况是笔记本在折叠状态下用 WiFi 定位，误差大得离谱。

排查顺序我一般是这样：第一步，打印 pos.coords.accuracy 和 pos.timestamp，看精度是否和你看到的偏差量级匹配；第二步，到户外开阔地重测，排除环境影响；第三步，在真机上对比原生地图 App 的定位结果，如果原生也不准，说明是设备或网络基础数据的问题，和页面代码无关。做定位功能，一定要在“室内、城郊、遮挡物多”三种环境跑一遍，只在工位测试没有任何意义。

5.3 现象：页面横向滚动后，定位卡片把布局撑破

这是一个纯响应式布局问题。定位卡片里如果放入很长的状态文案，比如“纬度 39.90420 经度 116.40740 精度约 12 米”，在 320px 宽的小屏上会顶破卡片边界，横向出现滚动条。原因不是定位 API，而是你没有给文本设置换行。坐标文案是连续数字串，浏览器不会自动在数字中间断行。

解决办法很简单，给状态元素加 word-break: break-all，或者 overflow-wrap: anywhere。同时建议把精度文案拆成两行显示，避免一个 p 标签里堆太多信息。这算定位开发里最不起眼但最常见的落地坑，课程里把它放在第 12 小节，每次讲完都有学生“哇”一声，因为大家都遇到过，只是没归因到 CSS。

5.4 现象：watchPosition 回调只触发一次

理论上 watchPosition 会在位置变化时触发回调，但真机上是“有时变了几百米也不回调，有时纹丝不动却回调”。原因在于浏览器对 watchPosition 的节流策略：Chrome 对后台标签页会冻结定时器，iOS Safari 在低电量模式下也会暂停 GPS 回调。这不算报错，只是你的页面已经不在前台活跃，浏览器不想为网页做“伪后台定位”。

解决办法有三个。第一，页面 visibilitychange 到 hidden 时 clearWatch，回到 visible 时重新注册；第二，业务需要后台定位时，正视浏览器限制，改用 Service Worker 或者原生壳能力，不要跟浏览器较劲；第三，高频业务不要只用 watchPosition 的节流，可以自建 30 秒轮询，用 getCurrentPosition 不停拉新坐标。我在共享位置小程序里就是这么做的，轮询拿到的坐标心跳更稳定，用户感知也更好。

5.5 现象：浏览器权限允许了，系统层又把定位关了

这个坑在 App 内嵌 WebView 里最常见。页面内调 getCurrentPosition，返回的是 code 2（POSITION_UNAVAILABLE），可浏览器权限明明是允许的。最后查到是宿主 App 的 AndroidManifest 没申请 ACCESS_FINE_LOCATION，或者 iOS 的 Info.plist 缺少 NSLocationWhenInUseUsageDescription，WebView 拿到的是“妈我没权限”的状态。

解决方式是让原生开发配合，确认宿主包声明了定位权限。如果是自己的调试用 App，可以在原生代码里手动申请 runtime permission，再 reload WebView。另外两个平台有个细节差异：Android 13 以上把定位权限分细定位和粗略定位，申请的若是粗略定位，精度会受限，即使网页把 enableHighAccuracy 设为 true 也没用；iOS 14 以上首次进页面时，权限弹窗有“精准定位”开关，用户如果关掉，返回的 accuracy 会放大到几百米甚至几公里。这类问题在代码层无解，只能加 UI 引导让用户重新开启。

6. 进阶：用 watchPosition 做距离追踪，顺便把调试面板做好

6.1 Haversine 公式：算两点的直线距离

拿到坐标后，下一件常做的事是算“走了多远”。不要直接对经纬度做减法，地球曲率在长距离下误差明显，要用 Haversine 公式。下面是适合前端的实现，不依赖第三方库。

function haversineMeters(lat1, lng1, lat2, lng2) { const R = 6371000; // 地球平均半径，单位米 const toRad = (d) => (d * Math.PI) / 180; const dLat = toRad(lat2 - lat1); const dLng = toRad(lng2 - lng1); const s = Math.sin(dLat / 2) * Math.sin(dLat / 2) + Math.cos(toRad(lat1)) * Math.cos(toRad(lat2)) * Math.sin(dLng / 2) * Math.sin(dLng / 2); return 2 * R * Math.asin(Math.sqrt(s)); }

调用时注意两点。第一，两个坐标都要是同一坐标系，如果一个是 WGS84、一个是 GCJ-02，算出的距离会整体偏移几百米；第二，accuracy 本身就有十几米到几十米的噪声，所以用 watchPosition 累加距离时，应该先过滤掉 acc > 50 的点，否则原地不动也能走出几十米。这个过滤逻辑叫“轨迹清洗”，做跑图、骑行类页面的必修课。

6.2 定位调试面板：把精度、时间戳和轨迹外露

我在教案里最后安排的内容，不是技术，而是调试习惯。定位是“黑匣子”，你不在页面上把数据外露，就只能靠 alert 和 console 猜。我要求学生在页面上放一个隐藏的调试面板，用一个小开关唤出，里面显示四行信息：当前坐标、精度、时间戳、连续定位次数。需要时再叠加 watchPosition 的坐标轨迹列表。

const trace = []; navigator.geolocation.watchPosition((pos) => { const c = pos.coords; trace.push({ lat: c.latitude, lng: c.longitude, t: Date.now() }); renderDebug({ lat: c.latitude, lng: c.longitude, acc: c.accuracy, ts: pos.timestamp, len: trace.length }); }, null, { enableHighAccuracy: true, timeout: 10000, maximumAge: 0 });

这个面板别放到生产环境的普通用户可见区域，用 localStorage 或 URL 参数里存一个 debug=1 来开启就好。原因是你给用户看精度数字只会增加焦虑，但它对你自己排查权限、漂移、回调频率问题帮助极大。定位开发里“多一屏调试数据”比“多写十个 console.log”更管用，因为坐标相关问题必须看实时变化的数值才能定位病灶。

最后说一个我自己的习惯：每次真机调试定位，我都会先清空站点数据再进页面，让权限弹窗重新出现一次，然后故意点一次拒绝，再跑一次允许，把两个分支都验证到位。拒绝分支做得越顺滑，上线的后悔药越少。这个习惯救过我很多次，也希望能帮到你。

本文还有配套的精品资源，点击获取