uni-app无法直接调用微信“附近的人”接口，需后端基于gcj-02坐标系+球面距离公式（如st_distance_sphere）实现地理检索，并确保前后端坐标系统一、数据库加spatial索引、分页用游标、缓存定位结果。
微信小程序原生能力限制：uni-app 无法直接调用「附近的人」接口
uni-app 编译到微信小程序时，uni.getLocation 只能获取用户当前坐标，微信官方没有开放类似「附近的人」的聚合检索接口（如按距离搜索用户列表）。所谓“附近的人”，本质是后端基于用户上报的经纬度 + 地理围栏/球面距离计算（如 Haversine 公式）实现的，前端只负责采集和展示。
常见错误现象：uni.getLocation 成功但地图上没数据、搜索无结果、距离排序错乱——问题几乎都出在后端未做地理索引或前端传参精度不足。
- 必须调用
uni.getLocation({ type: 'gcj02' })，微信返回的是国测局加密坐标（GCJ-02），不能用wgs84，否则与腾讯地图 SDK 坐标系不一致，距离偏差可达 500 米以上 - 用户需主动授权
scope.userLocation，iOS 微信需额外配置permission字段在manifest.json中，否则首次调用静默失败 - 不要依赖
uni.getSystemInfo的locationEnabled判断定位开关，它只反映系统级开关，不反映微信内权限状态；应以uni.getLocation的fail回调 + 错误码1002（用户拒绝）为准
后端必须支持地理距离排序：避免用 MySQL ORDER BY ABS() 硬算
前端把 latitude 和 longitude 传给后端后，后端若用简单勾股定理或 ABS(lat - ?) + ABS(lng - ?) 排序，会在高纬度地区严重失真（比如哈尔滨和广州同经度差 1°，实际距离相差近一倍）。
正确做法是后端使用球面距离公式，并配合数据库地理索引：
- MySQL 5.7+ 必须用
ST_Distance_Sphere函数，字段类型为POINT，且该列需加SPATIAL索引，否则百万级数据查询超时 - 示例 SQL：
SELECT id, name, ST_Distance_Sphere(point, POINT(?, ?)) AS distance FROM users WHERE ST_Distance_Sphere(point, POINT(?, ?)) - 如果用 MongoDB，必须确保
2dsphere索引已建在位置字段上，查询用$geoWithin+$centerSphere，而非$near（后者不支持指定最大距离）
uni-app 地图组件渲染附近用户点位：别直接用 cover-view 做气泡
在 <map></map> 组件上叠加用户头像标记，很多人用 cover-view 定位，结果在 iOS 微信中频繁闪烁或偏移。这是因为 cover-view 基于屏幕像素定位，而地图缩放时经纬度转屏幕坐标是动态的。
正确路径是全部交给地图 SDK 渲染：
- 使用
mapContext.getCenterLocation()获取当前视野中心，再通过后端接口拉取该区域内的用户（带latitude/longitude） - 调用
mapContext.addMarkers()添加标记，markers数组中每个项的iconPath必须是本地绝对路径（如/static/icon-user.png），不能是网络地址或 base64 - 点击标记触发
markertap事件后，再用uni.showActionSheet或自定义弹窗展示详情，不要在cover-view里放复杂交互
性能与体验关键点：防抖 + 分页 + 缓存坐标
用户拖动地图或频繁缩放时，如果每次 regionchange 都立刻请求后端，极易触发频率限制或白屏。真实场景中，没人会盯着地图连续拖动 3 秒以上。
- 对
regionchange事件加 800ms 防抖，且仅当新视野中心与上次请求中心距离 > 300 米时才发起新请求（用 Haversine 粗略算） - 后端接口必须支持
page和pagesize，前端记录last_marker_id做分页游标，避免 offset 深度分页性能崩塌 - 用户关闭页面前，用
uni.setStorageSync('last_location', { lat, lng, ts })缓存最后一次有效坐标，下次进入时先展示缓存点位，再静默拉新数据，减少白屏感
最易被忽略的是坐标系混用：前端传 GCJ-02，后端存 WGS-84，再用腾讯地图 JS SDK 渲染——三者坐标系不统一，标记全飘到海里去了。从采集、传输、存储到渲染，全程盯死 gcj02 这一个标准。
