企业官网建设流程全解析

简介：这是一份面向Java后端开发者与小程序入门者的实战型项目源码，围绕小程序地图定位场景，演示如何用Java服务端配合前端完成位置服务。内容涉及GPS与网络定位、地理编码与反地理编码、路径规划、定位数据实时更新、隐私安全处理及前后端接口设计等关键环节，适合想打通地图定位链路的初中级开发者参考。资源包共38个文件，约314KB，以15个png界面截图与图标、6个js逻辑脚本、5个wxss样式、4个wxml页面结构及4个json配置为主，另含说明文档与开源协议，目录按pages、utils、image等模块划分，结构清晰便于按需查阅。目前已有155人学习下载。通过阅读源码，读者可理解地图定位小程序的整体组织方式，掌握定位接口调用、页面交互与样式布局的落地写法，并借鉴其错误处理与性能优化思路，快速搭建自己的定位类小程序原型。

1. 基于 Java 开发的小程序地图定位：从后端坐标到前端标记的完整链路

用户打开小程序，地图上立刻出现自己的位置和一个附近的门店标记，点一下还能看到距离和导航按钮。这个体验背后其实是一条跨端链路：微信小程序端负责采集经纬度、渲染地图组件，Java 后端负责坐标转换、距离计算和业务数据组装。很多团队第一次做的时候，前端能显示蓝点，后端却拿不到可用坐标，或者标记偏移几百米，问题往往出在坐标系没对齐、权限没配全、接口没做逆地理编码。这篇笔记就围绕「基于 Java 开发的小程序地图定位」这个方向，把小程序端wx.getLocation、map组件、Java 侧坐标纠偏、距离排序、缓存策略和常见翻车点一次讲透。适合正在做门店导航、打卡签到、配送范围判断、附近的人这类功能的开发者，新手能照着跑通最小闭环，熟手能直接拿去对照参数和边界。

2. 小程序端定位能力拆解：getLocation、map 组件与权限配置

2.1 三种定位精度怎么选：wgs84、gcj02、bd09 的实际差异

微信小程序wx.getLocation的type参数只有两个合法值：wgs84和gcj02。wgs84是 GPS 原始坐标系，gcj02是国测局加密后的坐标系，也就是常说的火星坐标。如果你直接把wgs84的经纬度丢到微信<map>组件上，标记会偏移几百米，因为微信地图底层用的是gcj02。百度地图的bd09又是在gcj02基础上二次偏移，小程序原生地图组件不认这个坐标系，必须转成gcj02才能正常显示。

我一般会这样选：只要是在微信生态内展示，统一用gcj02；如果后端还要对接第三方 GPS 设备或高精度轨迹，才在入库时保留wgs84，展示前再转。转换算法网上有现成的transform函数，但要注意它只适用于中国大陆范围，境外坐标不要做偏移，否则会引入新的误差。

// 小程序端获取 gcj02 坐标，直接可用于 map 组件 wx.getLocation({ type: 'gcj02', isHighAccuracy: true, // 开启高精度定位，iOS 上会额外请求一次 highAccuracyExpireTime: 4000, // 高精度定位超时时间，单位毫秒 success(res) { const { latitude, longitude, accuracy } = res // accuracy 是水平精度，单位米，大于 100 时建议提示用户到空旷处 console.log('定位结果', latitude, longitude, accuracy) }, fail(err) { // errMsg 常见值：getLocation:fail auth deny / system permission denied console.error('定位失败', err) } })

这段代码里isHighAccuracy和highAccuracyExpireTime是容易被忽略的参数。不开高精度时，安卓部分机型返回的是基站或 Wi-Fi 定位，误差可能到 500 米以上；开了之后系统会尝试 GPS，但耗时更长，所以超时时间要设一个合理值，我通常给 3000 到 5000 毫秒。accuracy字段一定要读，它是判断这次定位能不能用的关键，超过 100 米就别直接拿来算配送范围了。

2.2 app.json 里必须声明的权限与隐私协议

从 2022 年开始，微信对地理位置接口收紧了权限校验。如果app.json里没有声明requiredPrivateInfos，wx.getLocation会直接失败，报getLocation:fail the api need to be declared in the requiredPrivateInfos field in app.json。这个坑我见过太多次，尤其是老项目升级基础库之后突然定位不可用。

{ "requiredPrivateInfos": [ "getLocation", "chooseLocation", "choosePoi" ], "permission": { "scope.userLocation": { "desc": "你的位置信息将用于展示附近门店和计算距离" } } }

requiredPrivateInfos里按实际用到的接口填，不要多写，否则审核时会被问用途。permission里的desc会出现在系统授权弹窗上，写清楚业务用途，通过率更高。另外，如果小程序涉及隐私协议，还要在app.json里配置__usePrivacyCheck__，并在用户首次触发定位前调用wx.requirePrivacyAuthorize，否则新版本基础库会拦截。

2.3 map 组件标记渲染：markers、polyline 与 callout 的参数边界

拿到坐标之后，<map>组件的markers数组是展示核心。每个 marker 的id必须是数字，latitude和longitude必填，iconPath支持本地路径和网络路径，但网络图片需要先下载到本地临时文件，否则部分安卓机型不显示。callout用来做气泡，display: 'ALWAYS'会常驻显示，适合展示门店名和距离。

Page({ data: { latitude: 39.908, longitude: 116.397, markers: [] }, onLoad() { this.loadNearbyStores() }, loadNearbyStores() { wx.request({ url: 'https://your-java-api.com/api/stores/nearby', data: { lat: this.data.latitude, lng: this.data.longitude, radius: 3000 }, success: (res) => { const markers = res.data.list.map((item, index) => ({ id: index + 1, latitude: item.lat, longitude: item.lng, width: 32, height: 32, iconPath: '/assets/store-pin.png', callout: { content: `${item.name} ${item.distance}m`, display: 'ALWAYS', padding: 6, borderRadius: 4, fontSize: 12 } })) this.setData({ markers }) } }) } })

这里有个性能边界：markers超过 200 个之后，低端安卓机渲染会明显卡顿。常见做法是按缩放级别做聚合，或者只返回视野范围内的点。polyline用来画路线，点数量超过 1000 时建议后端抽稀，否则小程序端会掉帧。

3. Java 后端坐标处理：纠偏、距离计算与逆地理编码

3.1 wgs84 转 gcj02 的 Java 实现与边界判断

后端拿到的坐标可能来自小程序gcj02，也可能来自硬件wgs84。如果数据库里混存两种坐标系，距离计算就会出错。我一般会在入库时统一转成gcj02，转换函数用经典的transformLat和transformLng公式，注意outOfChina判断，境外坐标直接返回原值。

public class CoordTransform { private static final double PI = 3.1415926535897932384626; private static final double A = 6378245.0; private static final double EE = 0.00669342162296594323; public static boolean outOfChina(double lat, double lng) { return lng < 72.004 || lng > 137.8347 || lat < 0.8293 || lat > 55.8271; } public static double[] wgs84ToGcj02(double lat, double lng) { if (outOfChina(lat, lng)) { return new double[]{lat, lng}; } double dLat = transformLat(lng - 105.0, lat - 35.0); double dLng = transformLng(lng - 105.0, lat - 35.0); double radLat = lat / 180.0 * PI; double magic = Math.sin(radLat); magic = 1 - EE * magic * magic; double 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 new double[]{lat + dLat, lng + dLng}; } private static double transformLat(double x, double y) { double ret = -100.0 + 2.0 * x + 3.0 * y + 0.2 * y * y + 0.1 * x * y + 0.2 * Math.sqrt(Math.abs(x)); ret += (20.0 * Math.sin(6.0 * x * PI) + 20.0 * Math.sin(2.0 * x * PI)) * 2.0 / 3.0; ret += (20.0 * Math.sin(y * PI) + 40.0 * Math.sin(y / 3.0 * PI)) * 2.0 / 3.0; ret += (160.0 * Math.sin(y / 12.0 * PI) + 320 * Math.sin(y * PI / 30.0)) * 2.0 / 3.0; return ret; } private static double transformLng(double x, double y) { double ret = 300.0 + x + 2.0 * y + 0.1 * x * x + 0.1 * x * y + 0.1 * Math.sqrt(Math.abs(x)); ret += (20.0 * Math.sin(6.0 * x * PI) + 20.0 * Math.sin(2.0 * x * PI)) * 2.0 / 3.0; ret += (20.0 * Math.sin(x * PI) + 40.0 * Math.sin(x / 3.0 * PI)) * 2.0 / 3.0; ret += (150.0 * Math.sin(x / 12.0 * PI) + 300.0 * Math.sin(x / 30.0 * PI)) * 2.0 / 3.0; return ret; } }

这段代码的outOfChina判断很关键，少了它，境外坐标会被错误偏移。A是克拉索夫斯基椭球长半轴，EE是第一偏心率平方，这两个常数不要改。转换精度在米级，足够门店导航用，但如果做测绘级应用，需要更复杂的七参数转换。

3.2 Haversine 距离计算与 SQL 层排序优化

算距离最常用的是 Haversine 公式，Java 里直接实现就行。但如果在数据库里对全表逐行算距离，数据量上万之后会非常慢。我一般会先用一个矩形范围过滤，再用 Haversine 精算。

public class GeoUtils { private static final double EARTH_RADIUS = 6371000; // 地球平均半径，单位米 public static double haversine(double lat1, double lng1, double lat2, double lng2) { double dLat = Math.toRadians(lat2 - lat1); double dLng = Math.toRadians(lng2 - lng1); double a = Math.sin(dLat / 2) * Math.sin(dLat / 2) + Math.cos(Math.toRadians(lat1)) * Math.cos(Math.toRadians(lat2)) * Math.sin(dLng / 2) * Math.sin(dLng / 2); double c = 2 * Math.atan2(Math.sqrt(a), Math.sqrt(1 - a)); return EARTH_RADIUS * c; } }

对应的 SQL 先用经纬度范围缩小候选集，lat和lng字段建联合索引：

SELECT id, name, lat, lng, (6371000 * ACOS( COS(RADIANS(#{lat})) * COS(RADIANS(lat)) * COS(RADIANS(lng) - RADIANS(#{lng})) + SIN(RADIANS(#{lat})) * SIN(RADIANS(lat)) )) AS distance FROM store WHERE lat BETWEEN #{minLat} AND #{maxLat} AND lng BETWEEN #{minLng} AND #{maxLng} HAVING distance < #{radius} ORDER BY distance ASC LIMIT 50;

minLat、maxLat这些边界值由后端根据半径和纬度算出，纬度越高，经度跨度越大，公式是lngRange = radius / (111320 * cos(lat))。这样能把扫描行数从全表降到几千行以内。注意HAVING在 MySQL 里可以用别名，但部分数据库不支持，换成子查询更稳。

3.3 逆地理编码：把经纬度变成「XX路XX号」

用户看到的不能只是经纬度，需要地址。逆地理编码一般走第三方服务，Java 侧封装一个带缓存的方法，避免每次定位都请求外部接口。

@Service public class GeocoderService { @Cacheable(value = "geocode", key = "#lat + ',' + #lng") public String reverse(double lat, double lng) { // 调用地图开放平台逆地理编码接口 // 注意：不同平台坐标系要求不同，传入前确认是否需要 gcj02 String url = String.format("https://restapi.amap.com/v3/geocode/regeo?location=%f,%f&key=%s", lng, lat, apiKey); // 解析 JSON，取 regeocode.formatted_address return parseAddress(url); } }

缓存 key 用经纬度拼接，精度保留 6 位小数，大约 0.1 米，足够复用。缓存时间我一般设 24 小时，因为地址不会频繁变。注意高德、腾讯等平台的接口对坐标系要求不同，传错会返回错误地址，这个坑后面会细说。

4. 前后端联调与数据一致性：接口设计、缓存与并发

4.1 附近门店接口的请求参数与返回结构

接口设计要一次定清楚，避免前端反复改。我常用的请求参数是lat、lng、radius、page、size，返回里带distance和address。

返回结构里list每项包含id、name、lat、lng、distance、address。distance由后端算好，前端不再重复计算，避免两端精度不一致。

4.2 Redis GEO 与本地缓存的取舍

如果门店数据量大、查询频繁，可以用 Redis 的 GEO 结构。GEOADD入库，GEORADIUS查询，性能比 SQL 好一个量级。但 Redis GEO 底层是 geohash，精度约 0.6 米，对门店导航足够。缺点是数据同步需要额外维护，门店增删改时要同时更新 Redis 和数据库。

// Redis GEO 写入 redisTemplate.opsForGeo().add("store:geo", new Point(lng, lat), storeId); // 查询附近 3 公里 Circle circle = new Circle(new Point(lng, lat), new Distance(3000, Metrics.METRIC)); GeoResults<RedisGeoCommands.GeoLocation<String>> results = redisTemplate.opsForGeo().radius("store:geo", circle);

如果门店数量在几千以内，我建议直接用 SQL，少一个中间件少一份一致性负担。超过几万再上 Redis GEO，并且要做好缓存击穿和雪崩的兜底。

4.3 定位数据的一致性：坐标系、精度与时间戳

一致性有三个维度：坐标系一致、精度标记一致、时间戳有效。坐标系前面说了，统一gcj02。精度标记是指每次定位都记录accuracy，后端在算距离时如果accuracy大于 200 米，可以降权或提示用户重新定位。时间戳是指定位结果超过 30 秒就视为过期，尤其是配送场景，用户可能已经移动了。

public class LocationDTO { private double lat; private double lng; private double accuracy; private long timestamp; public boolean isExpired() { return System.currentTimeMillis() - timestamp > 30_000; } public boolean isReliable() { return accuracy > 0 && accuracy < 200; } }

这两个方法在业务层调用，过期或不可靠的定位直接返回错误码，让前端重新获取，不要拿旧数据硬算。

5. 地图定位避坑排查：坐标偏移、权限拒绝与真机差异

5.1 标记偏移几百米：坐标系混用的典型现象

现象：小程序地图上蓝点位置正确，但门店标记整体偏移，方向不固定，有时偏东有时偏北。原因：门店数据入库时用的是wgs84，小程序地图用gcj02，两者差 300 到 500 米。解决：入库前统一转gcj02，或者查询时在 Java 侧转换。检查方法是拿一个已知地标的经纬度，分别用两种坐标系渲染，看哪个和实际重合。

5.2 getLocation 报 auth deny：权限声明与用户拒绝的区分

现象：调用wx.getLocation直接失败，errMsg是getLocation:fail auth deny。原因有两种：一是app.json没配requiredPrivateInfos，二是用户之前拒绝过授权。解决：先检查配置，再调用wx.getSetting看scope.userLocation是否为 false。如果是用户拒绝，引导用户去wx.openSetting重新开启，不要反复弹窗，否则会被微信判定为骚扰。

5.3 安卓正常 iOS 偏移：高精度定位的机型差异

现象：同一地点，安卓机定位准，iPhone 偏几十米。原因：iOS 的isHighAccuracy行为不同，部分系统版本下高精度定位会返回缓存值。解决：在success里判断accuracy，大于 50 米时延迟 1 秒重新调用一次，或者提示用户「正在校准」。另外 iOS 的highAccuracyExpireTime不要设太短，建议 5000 毫秒以上。

5.4 逆地理编码返回错误地址：坐标系传反了

现象：经纬度明明在北京，逆地理编码返回的却是河北某地。原因：高德接口要求gcj02，如果传了wgs84，偏移后落到了错误区域。解决：调用前确认坐标系，必要时先转gcj02。另外注意经纬度顺序，高德是「经度,纬度」，百度是「纬度,经度」，传反了也会出错。

5.5 真机调试正常，体验版定位失败

现象：开发者工具里定位正常，体验版或正式版报错。原因：体验版和正式版走的是线上域名，如果request合法域名没配，接口请求失败，定位数据拿不到。解决：在小程序后台配置request合法域名，并且确保 HTTPS 证书有效。另外体验版需要把体验成员加入白名单，否则权限接口可能被限制。

6. 进阶技巧：用地理围栏做打卡签到与配送范围判断

地理围栏是地图定位里最实用的进阶能力。核心思路是：给定一个中心点和半径，判断用户当前坐标是否在范围内。Java 侧用 Haversine 算距离，小于半径即命中。但实际业务里，围栏往往不是圆形，而是多边形，比如园区边界、配送区域。这时候要用射线法判断点是否在多边形内。

public class GeoFence { // 射线法：判断点是否在多边形内 public static boolean contains(double lat, double lng, List<double[]> polygon) { int crossings = 0; for (int i = 0; i < polygon.size(); i++) { double[] p1 = polygon.get(i); double[] p2 = polygon.get((i + 1) % polygon.size()); if (((p1[0] > lat) != (p2[0] > lat)) && (lng < (p2[1] - p1[1]) * (lat - p1[0]) / (p2[0] - p1[0]) + p1[1])) { crossings++; } } return crossings % 2 == 1; } }

polygon是经纬度点列表，按顺时针或逆时针排列。射线法对简单多边形有效，自相交多边形需要先做分割。性能上，一个多边形几十个点，单次判断微秒级，完全够用。

打卡签到场景还要考虑「漂移」：用户站在围栏边缘，GPS 抖动会导致一会儿在内一会儿在外。我的做法是加一个缓冲带，比如围栏半径 100 米，实际判断用 80 米，留 20 米容差。另外记录打卡时的accuracy，超过 100 米直接拒绝，让用户重新定位。

配送范围判断则相反，要宽松一点，因为用户可能就在边界上。我一般用「中心点 + 半径」做初筛，再用多边形精判，两层都通过才放行。这样既快又准。

验证方法很简单：在开发者工具里用「模拟位置」功能，把坐标设到围栏内外各测一次，看接口返回是否符合预期。真机上再拿两个手机，一个在范围内一个在范围外，对比结果。我踩过的最大坑是忘了把围栏数据也转成gcj02，结果整个园区偏移，用户明明在门口却打不了卡。从那以后，我在所有坐标入库的地方都加了一行日志，打印原始坐标和转换后坐标，方便回溯。

希望帮到你。

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