
> 本文是「小i约球诞生记」系列文章之一。  
> 小i约球是一个微信小程序，主要帮乒乓球、羽毛球、台球、网球爱好者找到附近合适的球友。本文从一个具体技术或产品问题切入，记录约球小程序从 0 到 1 过程中的设计取舍。

## 前言

做“附近球友”这个功能时，我一开始以为 LBS 很简单。

拿到用户经纬度，查附近的人，按距离排一下，就结束了。

但真正放到约球场景里，会发现 LBS 不是一个单点能力，而是一组能力的组合：

- 小程序怎么拿定位
- 用户怎么选择常用约球地点
- 数据库存什么坐标格式
- 附近查询交给谁做
- 地图怎么展示点位
- 列表和地图是不是同一套数据
- 距离、球类、场景筛选怎么组合

## 可选方案

做这个功能时，大概有几种方案。

## 方案一：只存文本地址

最简单的方式是只让用户填写地址，比如“海淀区西二旗附近”“某某羽毛球馆”。

优点是实现非常简单。

缺点也很明显：

- 不能准确算距离
- 不能做地图点位
- 不能按半径查询
- 地址文本不统一，后期很难清洗
- 同一个地点可能有很多种写法

这个方案只适合非常早期的人工运营，不适合真正做附近匹配。

## 方案二：前端拿经纬度，后端普通字段存储

第二种方式是用小程序拿到经纬度，然后存在普通字段里：

```js
{
  latitude: 39.9,
  longitude: 116.3
}
```

这个方案比纯文本好很多，至少可以自己算距离，也可以在地图上显示点位。

但如果后端只是普通字段，附近查询就比较麻烦。你要么全量拉出来自己算，要么自己做经纬度范围过滤，再二次计算距离。

用户量小的时候能跑，数据量稍微大一点就会很难受。

## 方案三：使用云开发数据库 Geo 能力

小i约球最后选择的是这个方案。

用户选点或定位后，普通地址信息继续保留，同时额外存一个数据库 GeoPoint：

```js
const location = db.Geo.Point(longitude, latitude)
```

这样数据库里同时有两类字段：

- `address`：用于展示地点名称、详细地址、原始经纬度
- `location`：用于数据库地理位置查询

这种设计的好处是比较均衡。

展示层可以拿 `address`，查询层可以拿 `location`。前端不用自己全量算距离，后端也不用额外接一个地图服务。

对一个微信小程序 + 云开发项目来说，这是最顺手的方案。

## 为什么没有一开始接外部地图服务

外部地图服务当然也能做 LBS，比如地点检索、路线规划、行政区划、POI、逆地址解析等。

但小i约球第一阶段没有把它作为核心依赖。

原因是第一阶段需要解决的问题并不复杂：

- 用户选择一个约球地点
- 系统存下坐标
- 查询附近球友
- 地图展示点位

这些能力小程序和云开发已经能覆盖。

如果一开始就接外部地图服务，会多出不少成本：

- key 管理
- 请求配额
- 域名配置
- 坐标系处理
- 接口封装
- 失败兜底

所以我的选择是：第一阶段尽量用微信生态已有能力，等需要更复杂的 POI、路线、行政区、地理围栏时，再考虑接入外部地图服务。

## 小程序端：定位和选点是两件事

这里是很容易混淆的地方。

小程序里至少有两个和位置相关的能力：

- `getLocation`
- `chooseLocation`

它们解决的问题不一样。

`getLocation` 解决的是“用户现在在哪里”。

比如首页打开时，可以拿当前定位作为默认中心点，用来展示附近球友。

`chooseLocation` 解决的是“用户想把约球名片放在哪里”。

这个位置不一定是当前定位。一个用户可能现在在公司，但想发布家附近的羽毛球约球名片；也可能人在家里，但想发布常去球馆的乒乓球名片。

所以在小i约球里，这两个能力不能混用：

- 首页默认定位：用 `getLocation`
- 发布约球名片：用 `chooseLocation`

这是产品场景决定的，不只是技术接口差异。

## 小程序权限：定位不是无条件可用

小程序定位能力还涉及权限配置。

在 `app.json` 里，需要声明相关用途，比如：

```json
{
  "permission": {
    "scope.userLocation": {
      "desc": "用于查找附近球友和球馆"
    }
  },
  "requiredPrivateInfos": [
    "chooseLocation",
    "getLocation"
  ]
}
```

这里有两个现实问题。

第一，用户可能拒绝授权。

所以首页不能把定位当成绝对前提。定位失败时，要么用历史位置，要么展示默认城市或默认数据，要么引导用户开启定位。

第二，不同定位能力的审核和精度不一样。

低精度定位获取门槛低，但偏差可能比较大。对资讯类应用影响不大，但对约球这种线下场景，偏差几公里就很明显。这里的重点是：定位能力不能只看“能不能拿到”，还要看精度是否符合线下见面的场景。

## 云开发 Geo 能力适合做什么

云开发数据库的 Geo 能力，最适合做“给定一个点，查附近的数据”。

在小i约球里，它主要用在三个场景。

## 1. 查附近球友名片

用户打开首页时，根据用户位置查附近的约球名片。

这里除了地理位置，还要叠加业务条件：

- 不看自己的名片
- 按球类筛选
- 过滤无效数据
- 只查普通约球名片

这说明真实查询不会只有 `geoNear`，一定是“地理条件 + 业务条件”的组合。

## 2. 发布名片时找潜在匹配对象

用户发布新名片后，也可以反向查询附近已有球友。

这和首页查询方向不同。

首页查询是：我在哪里，附近有什么。  
发布匹配是：我发了一个新点，附近谁可能对它感兴趣。

同样是 Geo 查询，但产品含义不同。

## 3. 查附近本地群

本地群也可以看作一种地理对象。

一个群如果对应某个街道、球馆或区域，就可以给它存一个位置。用户查附近群时，也可以用 Geo 能力做半径查询。

这说明位置能力最好设计成底层能力，而不是只服务某一个页面。

## 小程序 map 组件能做什么

小程序自带 `map` 组件，已经能满足第一阶段需求。

最核心的几个能力是：

- 设置中心点 `longitude` / `latitude`
- 设置缩放级别 `scale`
- 传入 `markers`
- 监听 marker 点击
- 监听地图视野变化

小i约球首页地图大概就是这种结构：

```xml
<map
  longitude="{{user.location.longitude || 116.397428}}"
  latitude="{{user.location.latitude || 39.90923}}"
  markers="{{allMarkers}}"
  bindmarkertap="onMarkerTap"
  bindregionchange="onRegionChange"
  scale="13"
/>
```

这已经能完成基础的附近球友地图：

- 用户当前位置作为中心点
- 附近球友作为 marker
- 点击 marker 进入详情
- 缩放地图时调整 marker 展示方式

对第一阶段来说，不需要自己接一套 Web 地图库。

## map 组件的限制

不过小程序 `map` 组件也不是没有限制。

最典型的是 marker 展示。

普通 marker 只能传图标、位置、大小等属性。如果你想实现更复杂的效果，比如：

- 用用户头像作为 marker
- 不同球类不同图标
- 教练、陪练、球馆、群聊带不同角标
- 缩放级别高时显示角标，缩放级别低时隐藏角标

就需要自己做更多处理。

## 坐标系和精度问题

小程序里常见坐标类型是 `gcj02`。

如果你的数据全部来自微信小程序的定位和选点，内部保持一致就好。

真正容易出问题的是这些情况：

- 外部地图服务返回的是另一种坐标系
- 后台导入的数据来自不同来源
- 用户定位是低精度
- 地址文本和经纬度不一致

小i约球第一阶段尽量避免引入多套坐标来源，就是为了降低这类问题。

但即便如此，定位精度仍然会影响体验。低精度定位可能偏几公里，这对“附近球友”来说不是小问题。这个问题会在后面的 Location 接口踩坑里展开。

## 半径怎么选

附近查询一定要面对一个问题：多远算附近？

这个值不是纯技术问题。

对线下运动来说，半径和城市密度、运动类型、用户习惯都有关系。

比如：

- 乒乓球可能更依赖固定球馆
- 羽毛球对场馆和时间更敏感
- 台球用户可能愿意走远一点
- 一线城市直线 5km 和实际通勤 5km 不是一回事

第一阶段可以先用一个相对保守的范围，比如 10km。它不一定完美，但足够验证产品闭环。

后面更合理的方式，是把半径做成可配置：

- 用户自己选择活动范围
- 不同城市使用不同默认半径
- 不同球类使用不同默认半径
- 根据数据密度动态扩大或缩小范围

## 总结

LBS 选型不能脱离业务场景。

如果只是做一个地图展示，可能一个 `map` 组件就够了。  
如果只是存一个地址，文本字段也能应付。  
但如果要做“附近球友匹配”，就必须把定位、选点、Geo 存储、附近查询、地图点位和权限降级一起考虑。

小i约球第一阶段选择了微信小程序能力 + 云开发 Geo 能力 + 小程序 map 组件。

这套方案的核心价值不是最强，而是足够贴合早期产品：成本低、集成顺、验证快。

---

本文属于「小i约球诞生记」系列。


本文是「小i约球诞生记」系列文章之一。   小i约球是一个微信小程序，主要帮乒乓球、羽毛球、台球、网球爱好者找到附近合适的球友。本文从一个具体技术或产品问题切入，记录约球小程序从 0 到 1 过程中的设计取舍。

小i约球诞生记02：做附近球友匹配时，LBS 能力怎么选

小i约球是一个微信小程序，主要帮乒乓球、羽毛球、台球、网球爱好者找到附近合适的球友。本文记录开发过程中LBS的选型

客户端

后端

开发工具

"小i约球小程序技术解析：如何实现精准LBS约球功能？文章详细剖析了微信小程序开发中LBS功能的技术选型，对比三种存储方案优劣，最终采用云开发GeoPoint实现高效附近球友查询。涵盖定位权限、地图组件、坐标精度等关键问题，为运动社交类小程序提供实用开发参考。"

代码解释

数据库

2026上云采购 | AI焕新·智启新局

热销域名限时优惠，新客首年免费！


domain

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

小i约球诞生记02：做附近球友匹配时，LBS 能力怎么选-腾讯云开发者社区-腾讯云

小i约球诞生记02：做附近球友匹配时，LBS 能力怎么选

小i约球诞生记02：做附近球友匹配时，LBS 能力怎么选

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐