：后端鏈路與隱私合規(guī)避坑指南)
簡介一份基于Xposed框架的微信附近人采集工具源碼包適合具有一定Android逆向基礎(chǔ)、關(guān)注Hook技術(shù)與網(wǎng)絡(luò)協(xié)議模擬的開發(fā)者學(xué)習(xí)參考。資源圍繞三個核心模塊展開通過Xposed鉤子攔截微信附近人界面UI組件并獲取上下文信息模擬微信客戶端HTTP請求協(xié)議頭以獲取附近人原始數(shù)據(jù)借助多線程隊列完成采集處理并使用POI實時導(dǎo)出為Excel。源碼中同時涉及微信客戶端安全機制、數(shù)據(jù)包加解密、防刷機制等問題的應(yīng)對思路對想深入了解安卓Hook開發(fā)與HTTP交互的讀者較有參考價值。包體共15個文件主要包括6個Java源碼、5個xlsx示例數(shù)據(jù)、1個XML配置及README說明壓縮包僅38KB結(jié)構(gòu)簡潔、便于快速瀏覽。已有78人學(xué)習(xí)下載。需要提醒的是此類工具涉及用戶隱私與平臺安全邊界僅建議用于技術(shù)學(xué)習(xí)與合規(guī)研究切勿用于非法用途。 看到“微信附近人采集工具[源碼]”這個關(guān)鍵詞組合我先說個立場如果你是想寫個腳本去批量抓取微信里的“附近人”數(shù)據(jù)那種“采集”路數(shù)我不會教也勸你別碰。這不是技術(shù)能不能實現(xiàn)的問題——微信對用戶位置和身份信息的保護機制非常嚴格繞過平臺規(guī)則去拿用戶數(shù)據(jù)輕則賬號被處理重則面臨隱私方面的合規(guī)風(fēng)險完全是得不償失。但換個角度看“附近的人”是社交、本地生活、社區(qū)服務(wù)類產(chǎn)品里非常核心的功能模塊。你的真實需求很可能是在一個微信小程序里做出類似微信“附近的人”的效果用戶授權(quán)上報位置服務(wù)端檢索出附近用戶前端展示列表和距離。這套需求完全可以用小程序官方能力加自建后端來實現(xiàn)合法且可落地。這篇文章就把完整鏈路拆開講清楚從坐標(biāo)系處理、距離計算、存儲方案到后端接口、小程序端實現(xiàn)再到隱私合規(guī)和平臺審核避坑全是能直接參考的實操內(nèi)容。1. 先搞清楚“采集”在合規(guī)產(chǎn)品里應(yīng)該怎么做1.1 合規(guī)的位置數(shù)據(jù)只能“用戶主動給”不能“平臺偷偷拿”在做“附近的人”的時候很多人第一反應(yīng)是“怎么把數(shù)據(jù)拿過來”。在微信生態(tài)里答案只有一個讓用戶自己授權(quán)。小程序官方提供了一整套位置能力包括wx.getLocation、wx.chooseLocation、wx.onLocationChange等接口用戶必須主動點擊授權(quán)你才能拿“我自己”的經(jīng)緯度。想拿其他用戶的位置只有一種方式——對方也使用了你的產(chǎn)品并且主動上報了位置。所以合規(guī)產(chǎn)品里的“采集”本質(zhì)是“上報-存儲-檢索”三步閉環(huán)而不是“抓取-解析-入庫”。你在網(wǎng)上能搜到的那些所謂“微信附近人接口”“自動采集源碼”基本都涉及對微信客戶端的注入或協(xié)議破解屬于嚴重違規(guī)我親眼見過有人因為做這個東西被批量封號業(yè)務(wù)一夜歸零。真想在自己的產(chǎn)品里做類似能力必須走官方位置接口加自建后端這條路。1.2 一個最小可用的“附近的人”功能需要哪些模塊拆開來看功能其實不復(fù)雜用戶上報當(dāng)前經(jīng)緯度這一步需要位置授權(quán)。服務(wù)端保存用戶位置與最后活躍時間。查詢接口接收經(jīng)緯度和半徑返回附近用戶列表。前端以列表或地圖形式展示顯示距離信息。用戶可控制開關(guān)關(guān)閉后立即從附近列表中消失。這個功能對實時性的要求其實不高能做到分鐘級更新就已經(jīng)很好。初期數(shù)據(jù)量就是幾千到幾萬條后面增長再考慮更重的存儲和檢索方案。關(guān)鍵是把鏈路跑通而不是一上來就上重型架構(gòu)。2. 技術(shù)選型與整體架構(gòu)2.1 技術(shù)棧怎么選為什么我用 Redis GEO我給出一套比較省心的組合小程序端 Node.jsExpress Redis GEO?？赡苡信笥褧枮槭裁床挥?MySQL 或 MongoDB先說結(jié)論“附近的人”本質(zhì)上是一個半徑檢索問題也就是給定一個點和一個半徑找出這個圓內(nèi)有哪些點位。數(shù)據(jù)量在百萬以內(nèi)時Redis GEO 是最合適的方案寫入快、查詢快、部署成本低。MySQL 8.0 也有空間索引支持ST_Distance_Sphere這類函數(shù)但它更適合和復(fù)雜業(yè)務(wù)查詢耦合在一起的情況MongoDB 的 GeoJSON 查詢體驗也不錯但屬于多引入一套存儲體系維護成本偏高。如果項目里已經(jīng)有用得很熟的 MySQL而且數(shù)據(jù)量不大用空間索引也完全可以。這篇文章的主代碼以 Redis GEO 為例因為它最直觀理解以后遷移到 MySQL 也只是換一套查詢語句的事。2.2 整體調(diào)用鏈路整個流程是這樣的小程序端定位 - 通過wx.request把坐標(biāo)上報到后端 - 后端寫入 Redis GEO - 其他用戶請求附近列表 - 后端執(zhí)行半徑查詢 - 返回脫敏后的用戶數(shù)據(jù)用戶ID、昵稱、距離- 小程序渲染列表。這里有個關(guān)鍵點必須反復(fù)強調(diào)后端返回給前端的數(shù)據(jù)永遠不要包含精確經(jīng)緯度。只返回“用戶ID、昵稱、距離文本”。精確坐標(biāo)屬于個人敏感信息用戶授權(quán)給的是平臺不是授權(quán)給平臺里其他用戶。一旦把精確坐標(biāo)暴露給任意查詢者你的產(chǎn)品就從“附近的人”變成了“實時定位監(jiān)控”這在隱私合規(guī)上是絕對過不了關(guān)的。3. 核心原理坐標(biāo)系、距離計算與空間檢索3.1 坐標(biāo)系為什么你的距離總是偏差幾百米國內(nèi)做 LBS 繞不開兩套坐標(biāo)系WGS84 和 GCJ-02。簡單說WGS84 是 GPS 原始的全球坐標(biāo)GCJ-02 是國內(nèi)地圖廠商使用的加密坐標(biāo)俗稱火星坐標(biāo)。微信小程序wx.getLocation的type設(shè)為gcj02時返回的就是 GCJ-02騰訊地圖、高德地圖用的也是 GCJ-02。我的建議是全程統(tǒng)一使用 GCJ-02不要混用。如果你把 GCJ-02 坐標(biāo)直接當(dāng)成 WGS84 去算距離偏差可能達到幾百米如果再把坐標(biāo)展示到地圖上點位會明顯偏移。這段“路線偏差”的問題是很多新手排查半天都找不到原因的經(jīng)典坑其實一開始統(tǒng)一坐標(biāo)系就沒事了。3.2 距離計算Haversine 公式了解一下球面上兩點的距離不能用平面直角坐標(biāo)系里的歐氏距離直接算因為地球是個球體。常用的球面距離公式是 Haversinea sin2(Δφ/2) cos φ1 × cos φ2 × sin2(Δλ/2)c 2 × atan2(√a, √(1?a))d R × c其中 R 取地球平均半徑 6371 公里在代碼里實現(xiàn)也不復(fù)雜先把經(jīng)緯度轉(zhuǎn)成弧度然后套公式。如果使用的是 Redis GEO 或 MySQL 空間函數(shù)庫內(nèi)部已經(jīng)處理了球面計算不需要自己寫公式。但理解原理仍然重要因為排查“距離為什么不對”的時候第一步是確認坐標(biāo)系第二步就是確認計算方式兩個都對了距離基本就不會錯。3.3 空間檢索三種方案對比這里把三種常見方案放在一起看方便你根據(jù)項目情況選擇方案核心能力優(yōu)點注意點Redis GEOGEOADD、GEORADIUS、GEOSEARCH性能極好部署簡單支持百萬級點位毫秒級查詢GEO 本身不帶業(yè)務(wù)屬性用戶信息要另外存MySQL 空間索引ST_Distance_Sphere、ST_Within和業(yè)務(wù)數(shù)據(jù)強耦合查詢條件可以寫得很靈活高并發(fā)寫入時壓力較大需要維護空間索引手動 GeoHash坐標(biāo)編碼為字符串按前綴匹配不依賴額外組件完全自控需要處理網(wǎng)格邊界和精度問題工程量大對于大多數(shù)中小型產(chǎn)品Redis GEO 是完全夠用的。我本地測試過幾十萬個點位做半徑查詢響應(yīng)時間基本穩(wěn)定在幾十毫秒內(nèi)只有當(dāng)你把數(shù)據(jù)量推到幾百萬且并發(fā)很高時才需要考慮分片或者換更重的方案。4. 從零實現(xiàn)后端接口 小程序端完整鏈路4.1 后端接口設(shè)計整個后端只需要兩個接口POST /api/location/report上報當(dāng)前位置。GET /api/location/nearby查詢附近用戶。上報接口需要前端傳用戶ID、經(jīng)緯度查詢接口需要傳當(dāng)前經(jīng)緯度、查詢半徑。真實項目中用戶ID應(yīng)該由后端從登錄態(tài)中解析出來而不是直接信任前端傳值我這里為了演示方便簡化處理。4.2 Node.js Redis GEO 的實現(xiàn)先安裝依賴npm install express redis uuid這里以 node-redis v4 的 API 為例實現(xiàn)上報接口const express require(express); const { createClient } require(redis); const app express(); app.use(express.json()); const redis createClient(); redis.connect(); const GEO_KEY nearby:users; // 上報位置 app.post(/api/location/report, async (req, res) { const { userId, lng, lat } req.body; if (!userId || lng undefined || lat undefined) { return res.status(400).json({ code: 1, message: 參數(shù)不完整 }); } await redis.geoAdd(GEO_KEY, { longitude: lng, latitude: lat, member: userId }); // 記錄最后活躍時間24小時內(nèi)有效 await redis.set(online:${userId}, String(Date.now()), { EX: 86400 }); res.json({ code: 0, message: ok }); });然后是附近查詢接口// 查詢附近 app.get(/api/location/nearby, async (req, res) { const { lng, lat, radius 5000 } req.query; if (lng undefined || lat undefined) { return res.status(400).json({ code: 1, message: 缺少經(jīng)緯度 }); } const result await redis.geoSearch( GEO_KEY, { longitude: Number(lng), latitude: Number(lat) }, { radius: Number(radius), unit: m, sort: ASC } ); const users []; for (const item of result) { if (item.member req.query.userId) continue; // 排除自己 // 只返回脫敏信息和距離不返回坐標(biāo) users.push({ userId: item.member, distance: Math.round(item.distance), distanceText: formatDistance(item.distance) }); } res.json({ code: 0, data: users }); }); function formatDistance(m) { if (m 1000) return ${Math.round(m)}m; return ${(m / 1000).toFixed(1)}km; } app.listen(3000, () console.log(server running at 3000));這段代碼里有兩個容易被忽略的細節(jié)。第一geoSearch返回的結(jié)果里帶有每個成員與中心點的距離單位是米直接拿來做距離展示不需要自己再算一遍。第二查詢結(jié)果要排除自己否則你會在“附近的人”里看到自己。關(guān)于數(shù)據(jù)過期機制我的設(shè)計是這樣GEO key 本身不設(shè) TTL因為如果整個 key 過期所有用戶位置會被一次性清空每個用戶上報時就覆蓋同一個 member 的坐標(biāo)。另用一個online:{userId}的 key 記錄最后活躍時間TTL 設(shè)為 24 小時。查詢時如果要做更嚴格的過濾可以先掃描在線用戶再查 GEO。這樣既不丟數(shù)據(jù)又能自然淘汰長期不活躍的用戶。4.3 小程序端實現(xiàn)小程序端的第一步是在app.json里聲明位置權(quán)限的用途說明{ permission: { scope.userLocation: { desc: 你的位置信息將用于展示附近的人 } }, requiredPrivateInfos: [getLocation] }requiredPrivateInfos這個字段是后期審核要求加上的必須有否則在微信開發(fā)者工具里可能直接報錯。接下來是獲取定位并上報function reportLocation(userId) { wx.getLocation({ type: gcj02, success(res) { wx.request({ url: https://your.domain.com/api/location/report, method: POST, data: { userId, lng: res.longitude, lat: res.latitude } }); }, fail(err) { console.error(獲取位置失敗, err); wx.showToast({ title: 授權(quán)位置后才能使用附近的人, icon: none }); } }); }這里我把type固定為gcj02就是為了和后端、地圖保持同一套坐標(biāo)系避免后續(xù)距離偏移。接下來是查詢并渲染列表function loadNearby(userId, lng, lat) { wx.request({ url: https://your.domain.com/api/location/nearby, data: { userId, lng, lat, radius: 5000 }, success(res) { if (res.data.code 0) { this.setData({ nearbyList: res.data.data }); } } }); }前端拿到列表后直接展示昵稱和距離文本即可。如果要做地圖打點請再次確認不要給地圖傳入其他人的精確坐標(biāo)而是只展示“當(dāng)前用戶位置 附近用戶距離范圍”否則審核風(fēng)險很高。4.4 列表展示和地圖展示怎么選列表是初期最推薦的形式信息密度高、實現(xiàn)簡單、滾動性能好。地圖組件視覺效果好能直觀展示空間關(guān)系但小程序里的map組件相對較重在列表滾動、坐標(biāo)事件交互上要處理更多細節(jié)。我的習(xí)慣是先做列表快速驗證業(yè)務(wù)模型。等用戶量起來、業(yè)務(wù)方向確認后再考慮加一個“地圖視角”開關(guān)用地圖展示當(dāng)前用戶的周邊范圍。千萬不要一上來就同時做兩套否則前后端聯(lián)調(diào)的工作量會翻倍。5. 隱私合規(guī)與平臺審核避坑5.1 上線前必須做的配置這個環(huán)節(jié)非常重要至少有三件事必須提前處理好。第一小程序管理后臺要申請位置相關(guān)接口權(quán)限也就是wx.getLocation并填寫實際用途。用途說明要寫得很具體比如“用戶開啟附近功能后獲取其位置信息用于計算并展示與其他用戶的距離”不要只寫“用于附近的人”五個字太敷衍容易被駁回。第二小程序的隱私協(xié)議中要單獨說明位置信息的采集、使用、存儲方式包括存儲時長和用戶如何主動清除位置。這塊不僅是審核要求也是產(chǎn)品對用戶負責(zé)任的表現(xiàn)。第三功能層面必須支持用戶主動關(guān)閉附近展示。關(guān)閉后后端要立即刪除該用戶在 Redis GEO 中的記錄而不是僅僅在前端隱藏。我見過有些產(chǎn)品只在前端把按鈕關(guān)掉后端數(shù)據(jù)還在用戶隱私就存在隱患。5.2 審核被拒的常見原因我把審核時最容易踩的幾個坑整理成了表格被拒原因典型表現(xiàn)規(guī)避方法隱私接口未聲明一調(diào)用getLocation就被判違規(guī)在app.json和后臺同時完善隱私聲明強制授權(quán)用戶拒絕位置授權(quán)后完全沒法使用小程序允許游客模式位置作為可選功能用途說明太簡單審核員看不懂你為什么要做“附近的人”寫清產(chǎn)品場景、功能路徑、數(shù)據(jù)使用范圍展示他人精確坐標(biāo)地圖打點直接顯示其他用戶位置只返回距離文本不返回其他人的經(jīng)緯度位置數(shù)據(jù)沒有刪除路徑用戶關(guān)閉功能后數(shù)據(jù)仍保留關(guān)閉時清理后端 GEO 記錄提供聯(lián)系方式引導(dǎo)5.3 我踩過的一個真實坑我之前做過一版類似功能為了省事把用戶經(jīng)緯度直接放在接口返回值里前端在地圖上直接打點。結(jié)果審核被拒理由就是“展示用戶精確位置”。后來改成服務(wù)端只返回距離前端只顯示距離文本才通過。這個經(jīng)驗真的建議提前看位置數(shù)據(jù)不同于普通頭像昵稱一旦展示給陌生人帶來的安全隱患非常大。產(chǎn)品設(shè)計上寧可保守也別惹麻煩。6. 常見問題與排查實錄6.1 定位失敗或者授權(quán)彈窗不出現(xiàn)常見原因有三個requiredPrivateInfos沒配用戶之前拒絕過授權(quán)代碼里沒有處理fail回調(diào)。處理方案是在頁面啟動時主動引導(dǎo)授權(quán)如果用戶拒絕再通過wx.openSetting引導(dǎo)去設(shè)置頁打開授權(quán)。注意不要在小程序一啟動時就同時彈多個授權(quán)框體驗會非常差。6.2 坐標(biāo)看起來沒問題但距離差了好幾倍這個問題我排查過很多次基本就兩類原因坐標(biāo)系混用或者經(jīng)緯度字段寫反了。wx.getLocation返回的是longitude和latitude有的接口會簡寫成lng和lat復(fù)制代碼時很容易對錯位置。建議在請求后端前打一條日志實際打印出經(jīng)緯度再核對。6.3 Redis GEO 里能查到人小程序里卻看不到十有八九是后端接口字段名不匹配或者小程序的 request 合法域名沒有配置。開發(fā)階段可以在微信開發(fā)者工具里勾選“不校驗合法域名”但上線前一定要把接口域名加到 request 合法域名列表并確保接口是 HTTPS。6.4 數(shù)據(jù)量變大后查詢變慢怎么辦先用數(shù)據(jù)說話明確用戶量和 QPS 上限。Redis GEO 在百萬級點位上是毫秒級響應(yīng)一般產(chǎn)品根本到不了性能瓶頸。如果真遇到問題常見的優(yōu)化思路是按城市拆多個 GEO key比如nearby:users:beijing、nearby:users:shanghai查詢時根據(jù)目標(biāo)坐標(biāo)先定位城市再查對應(yīng) key。這個方案實現(xiàn)成本不高效果卻很明顯。6.5 真機調(diào)試和開發(fā)者工具定位結(jié)果不一致開發(fā)者工具里的定位是模擬的默認位置在北京或者你手動選擇的城市真機則是真實 GPS。這也解釋了為什么很多人開發(fā)時測試一切正常一上真機就發(fā)現(xiàn)距離計算不對。建議真機測試時去不同環(huán)境多試幾次室內(nèi)、室外、電梯里都跑一下看定位精度是否符合預(yù)期。我在實際做類似功能時踩過最多坑的不是后端代碼而是隱私審核和坐標(biāo)系。位置數(shù)據(jù)這個方向一旦口徑不統(tǒng)一、用途沒說清后面全是返工。最后再分享一個自用的小技巧上報位置時不要只存坐標(biāo)把設(shè)備的精度值也一并存下來。如果某次定位精度是 500 米距離展示就不要精確到“301 米”顯示“約 500 米內(nèi)”會更合理。這在審核和用戶感知上都更安全也更符合位置數(shù)據(jù)的真實精度水平。本文還有配套的精品資源點擊獲取 微信小程序“附近的人”功能實現(xiàn)：后端鏈路與隱私合規(guī)避坑指南
簡介一份基于Xposed框架的微信附近人采集工具源碼包適合具有一定Android逆向基礎(chǔ)、關(guān)注Hook技術(shù)與網(wǎng)絡(luò)協(xié)議模擬的開發(fā)者學(xué)習(xí)參考。資源圍繞三個核心模塊展開通過Xposed鉤子攔截微信附近人界面UI組件并獲取上下文信息模擬微信客戶端HTTP請求協(xié)議頭以獲取附近人原始數(shù)據(jù)借助多線程隊列完成采集處理并使用POI實時導(dǎo)出為Excel。源碼中同時涉及微信客戶端安全機制、數(shù)據(jù)包加解密、防刷機制等問題的應(yīng)對思路對想深入了解安卓Hook開發(fā)與HTTP交互的讀者較有參考價值。包體共15個文件主要包括6個Java源碼、5個xlsx示例數(shù)據(jù)、1個XML配置及README說明壓縮包僅38KB結(jié)構(gòu)簡潔、便于快速瀏覽。已有78人學(xué)習(xí)下載。需要提醒的是此類工具涉及用戶隱私與平臺安全邊界僅建議用于技術(shù)學(xué)習(xí)與合規(guī)研究切勿用于非法用途。 看到“微信附近人采集工具[源碼]”這個關(guān)鍵詞組合我先說個立場如果你是想寫個腳本去批量抓取微信里的“附近人”數(shù)據(jù)那種“采集”路數(shù)我不會教也勸你別碰。這不是技術(shù)能不能實現(xiàn)的問題——微信對用戶位置和身份信息的保護機制非常嚴格繞過平臺規(guī)則去拿用戶數(shù)據(jù)輕則賬號被處理重則面臨隱私方面的合規(guī)風(fēng)險完全是得不償失。但換個角度看“附近的人”是社交、本地生活、社區(qū)服務(wù)類產(chǎn)品里非常核心的功能模塊。你的真實需求很可能是在一個微信小程序里做出類似微信“附近的人”的效果用戶授權(quán)上報位置服務(wù)端檢索出附近用戶前端展示列表和距離。這套需求完全可以用小程序官方能力加自建后端來實現(xiàn)合法且可落地。這篇文章就把完整鏈路拆開講清楚從坐標(biāo)系處理、距離計算、存儲方案到后端接口、小程序端實現(xiàn)再到隱私合規(guī)和平臺審核避坑全是能直接參考的實操內(nèi)容。1. 先搞清楚“采集”在合規(guī)產(chǎn)品里應(yīng)該怎么做1.1 合規(guī)的位置數(shù)據(jù)只能“用戶主動給”不能“平臺偷偷拿”在做“附近的人”的時候很多人第一反應(yīng)是“怎么把數(shù)據(jù)拿過來”。在微信生態(tài)里答案只有一個讓用戶自己授權(quán)。小程序官方提供了一整套位置能力包括wx.getLocation、wx.chooseLocation、wx.onLocationChange等接口用戶必須主動點擊授權(quán)你才能拿“我自己”的經(jīng)緯度。想拿其他用戶的位置只有一種方式——對方也使用了你的產(chǎn)品并且主動上報了位置。所以合規(guī)產(chǎn)品里的“采集”本質(zhì)是“上報-存儲-檢索”三步閉環(huán)而不是“抓取-解析-入庫”。你在網(wǎng)上能搜到的那些所謂“微信附近人接口”“自動采集源碼”基本都涉及對微信客戶端的注入或協(xié)議破解屬于嚴重違規(guī)我親眼見過有人因為做這個東西被批量封號業(yè)務(wù)一夜歸零。真想在自己的產(chǎn)品里做類似能力必須走官方位置接口加自建后端這條路。1.2 一個最小可用的“附近的人”功能需要哪些模塊拆開來看功能其實不復(fù)雜用戶上報當(dāng)前經(jīng)緯度這一步需要位置授權(quán)。服務(wù)端保存用戶位置與最后活躍時間。查詢接口接收經(jīng)緯度和半徑返回附近用戶列表。前端以列表或地圖形式展示顯示距離信息。用戶可控制開關(guān)關(guān)閉后立即從附近列表中消失。這個功能對實時性的要求其實不高能做到分鐘級更新就已經(jīng)很好。初期數(shù)據(jù)量就是幾千到幾萬條后面增長再考慮更重的存儲和檢索方案。關(guān)鍵是把鏈路跑通而不是一上來就上重型架構(gòu)。2. 技術(shù)選型與整體架構(gòu)2.1 技術(shù)棧怎么選為什么我用 Redis GEO我給出一套比較省心的組合小程序端 Node.jsExpress Redis GEO?？赡苡信笥褧枮槭裁床挥?MySQL 或 MongoDB先說結(jié)論“附近的人”本質(zhì)上是一個半徑檢索問題也就是給定一個點和一個半徑找出這個圓內(nèi)有哪些點位。數(shù)據(jù)量在百萬以內(nèi)時Redis GEO 是最合適的方案寫入快、查詢快、部署成本低。MySQL 8.0 也有空間索引支持ST_Distance_Sphere這類函數(shù)但它更適合和復(fù)雜業(yè)務(wù)查詢耦合在一起的情況MongoDB 的 GeoJSON 查詢體驗也不錯但屬于多引入一套存儲體系維護成本偏高。如果項目里已經(jīng)有用得很熟的 MySQL而且數(shù)據(jù)量不大用空間索引也完全可以。這篇文章的主代碼以 Redis GEO 為例因為它最直觀理解以后遷移到 MySQL 也只是換一套查詢語句的事。2.2 整體調(diào)用鏈路整個流程是這樣的小程序端定位 - 通過wx.request把坐標(biāo)上報到后端 - 后端寫入 Redis GEO - 其他用戶請求附近列表 - 后端執(zhí)行半徑查詢 - 返回脫敏后的用戶數(shù)據(jù)用戶ID、昵稱、距離- 小程序渲染列表。這里有個關(guān)鍵點必須反復(fù)強調(diào)后端返回給前端的數(shù)據(jù)永遠不要包含精確經(jīng)緯度。只返回“用戶ID、昵稱、距離文本”。精確坐標(biāo)屬于個人敏感信息用戶授權(quán)給的是平臺不是授權(quán)給平臺里其他用戶。一旦把精確坐標(biāo)暴露給任意查詢者你的產(chǎn)品就從“附近的人”變成了“實時定位監(jiān)控”這在隱私合規(guī)上是絕對過不了關(guān)的。3. 核心原理坐標(biāo)系、距離計算與空間檢索3.1 坐標(biāo)系為什么你的距離總是偏差幾百米國內(nèi)做 LBS 繞不開兩套坐標(biāo)系WGS84 和 GCJ-02。簡單說WGS84 是 GPS 原始的全球坐標(biāo)GCJ-02 是國內(nèi)地圖廠商使用的加密坐標(biāo)俗稱火星坐標(biāo)。微信小程序wx.getLocation的type設(shè)為gcj02時返回的就是 GCJ-02騰訊地圖、高德地圖用的也是 GCJ-02。我的建議是全程統(tǒng)一使用 GCJ-02不要混用。如果你把 GCJ-02 坐標(biāo)直接當(dāng)成 WGS84 去算距離偏差可能達到幾百米如果再把坐標(biāo)展示到地圖上點位會明顯偏移。這段“路線偏差”的問題是很多新手排查半天都找不到原因的經(jīng)典坑其實一開始統(tǒng)一坐標(biāo)系就沒事了。3.2 距離計算Haversine 公式了解一下球面上兩點的距離不能用平面直角坐標(biāo)系里的歐氏距離直接算因為地球是個球體。常用的球面距離公式是 Haversinea sin2(Δφ/2) cos φ1 × cos φ2 × sin2(Δλ/2)c 2 × atan2(√a, √(1?a))d R × c其中 R 取地球平均半徑 6371 公里在代碼里實現(xiàn)也不復(fù)雜先把經(jīng)緯度轉(zhuǎn)成弧度然后套公式。如果使用的是 Redis GEO 或 MySQL 空間函數(shù)庫內(nèi)部已經(jīng)處理了球面計算不需要自己寫公式。但理解原理仍然重要因為排查“距離為什么不對”的時候第一步是確認坐標(biāo)系第二步就是確認計算方式兩個都對了距離基本就不會錯。3.3 空間檢索三種方案對比這里把三種常見方案放在一起看方便你根據(jù)項目情況選擇方案核心能力優(yōu)點注意點Redis GEOGEOADD、GEORADIUS、GEOSEARCH性能極好部署簡單支持百萬級點位毫秒級查詢GEO 本身不帶業(yè)務(wù)屬性用戶信息要另外存MySQL 空間索引ST_Distance_Sphere、ST_Within和業(yè)務(wù)數(shù)據(jù)強耦合查詢條件可以寫得很靈活高并發(fā)寫入時壓力較大需要維護空間索引手動 GeoHash坐標(biāo)編碼為字符串按前綴匹配不依賴額外組件完全自控需要處理網(wǎng)格邊界和精度問題工程量大對于大多數(shù)中小型產(chǎn)品Redis GEO 是完全夠用的。我本地測試過幾十萬個點位做半徑查詢響應(yīng)時間基本穩(wěn)定在幾十毫秒內(nèi)只有當(dāng)你把數(shù)據(jù)量推到幾百萬且并發(fā)很高時才需要考慮分片或者換更重的方案。4. 從零實現(xiàn)后端接口 小程序端完整鏈路4.1 后端接口設(shè)計整個后端只需要兩個接口POST /api/location/report上報當(dāng)前位置。GET /api/location/nearby查詢附近用戶。上報接口需要前端傳用戶ID、經(jīng)緯度查詢接口需要傳當(dāng)前經(jīng)緯度、查詢半徑。真實項目中用戶ID應(yīng)該由后端從登錄態(tài)中解析出來而不是直接信任前端傳值我這里為了演示方便簡化處理。4.2 Node.js Redis GEO 的實現(xiàn)先安裝依賴npm install express redis uuid這里以 node-redis v4 的 API 為例實現(xiàn)上報接口const express require(express); const { createClient } require(redis); const app express(); app.use(express.json()); const redis createClient(); redis.connect(); const GEO_KEY nearby:users; // 上報位置 app.post(/api/location/report, async (req, res) { const { userId, lng, lat } req.body; if (!userId || lng undefined || lat undefined) { return res.status(400).json({ code: 1, message: 參數(shù)不完整 }); } await redis.geoAdd(GEO_KEY, { longitude: lng, latitude: lat, member: userId }); // 記錄最后活躍時間24小時內(nèi)有效 await redis.set(online:${userId}, String(Date.now()), { EX: 86400 }); res.json({ code: 0, message: ok }); });然后是附近查詢接口// 查詢附近 app.get(/api/location/nearby, async (req, res) { const { lng, lat, radius 5000 } req.query; if (lng undefined || lat undefined) { return res.status(400).json({ code: 1, message: 缺少經(jīng)緯度 }); } const result await redis.geoSearch( GEO_KEY, { longitude: Number(lng), latitude: Number(lat) }, { radius: Number(radius), unit: m, sort: ASC } ); const users []; for (const item of result) { if (item.member req.query.userId) continue; // 排除自己 // 只返回脫敏信息和距離不返回坐標(biāo) users.push({ userId: item.member, distance: Math.round(item.distance), distanceText: formatDistance(item.distance) }); } res.json({ code: 0, data: users }); }); function formatDistance(m) { if (m 1000) return ${Math.round(m)}m; return ${(m / 1000).toFixed(1)}km; } app.listen(3000, () console.log(server running at 3000));這段代碼里有兩個容易被忽略的細節(jié)。第一geoSearch返回的結(jié)果里帶有每個成員與中心點的距離單位是米直接拿來做距離展示不需要自己再算一遍。第二查詢結(jié)果要排除自己否則你會在“附近的人”里看到自己。關(guān)于數(shù)據(jù)過期機制我的設(shè)計是這樣GEO key 本身不設(shè) TTL因為如果整個 key 過期所有用戶位置會被一次性清空每個用戶上報時就覆蓋同一個 member 的坐標(biāo)。另用一個online:{userId}的 key 記錄最后活躍時間TTL 設(shè)為 24 小時。查詢時如果要做更嚴格的過濾可以先掃描在線用戶再查 GEO。這樣既不丟數(shù)據(jù)又能自然淘汰長期不活躍的用戶。4.3 小程序端實現(xiàn)小程序端的第一步是在app.json里聲明位置權(quán)限的用途說明{ permission: { scope.userLocation: { desc: 你的位置信息將用于展示附近的人 } }, requiredPrivateInfos: [getLocation] }requiredPrivateInfos這個字段是后期審核要求加上的必須有否則在微信開發(fā)者工具里可能直接報錯。接下來是獲取定位并上報function reportLocation(userId) { wx.getLocation({ type: gcj02, success(res) { wx.request({ url: https://your.domain.com/api/location/report, method: POST, data: { userId, lng: res.longitude, lat: res.latitude } }); }, fail(err) { console.error(獲取位置失敗, err); wx.showToast({ title: 授權(quán)位置后才能使用附近的人, icon: none }); } }); }這里我把type固定為gcj02就是為了和后端、地圖保持同一套坐標(biāo)系避免后續(xù)距離偏移。接下來是查詢并渲染列表function loadNearby(userId, lng, lat) { wx.request({ url: https://your.domain.com/api/location/nearby, data: { userId, lng, lat, radius: 5000 }, success(res) { if (res.data.code 0) { this.setData({ nearbyList: res.data.data }); } } }); }前端拿到列表后直接展示昵稱和距離文本即可。如果要做地圖打點請再次確認不要給地圖傳入其他人的精確坐標(biāo)而是只展示“當(dāng)前用戶位置 附近用戶距離范圍”否則審核風(fēng)險很高。4.4 列表展示和地圖展示怎么選列表是初期最推薦的形式信息密度高、實現(xiàn)簡單、滾動性能好。地圖組件視覺效果好能直觀展示空間關(guān)系但小程序里的map組件相對較重在列表滾動、坐標(biāo)事件交互上要處理更多細節(jié)。我的習(xí)慣是先做列表快速驗證業(yè)務(wù)模型。等用戶量起來、業(yè)務(wù)方向確認后再考慮加一個“地圖視角”開關(guān)用地圖展示當(dāng)前用戶的周邊范圍。千萬不要一上來就同時做兩套否則前后端聯(lián)調(diào)的工作量會翻倍。5. 隱私合規(guī)與平臺審核避坑5.1 上線前必須做的配置這個環(huán)節(jié)非常重要至少有三件事必須提前處理好。第一小程序管理后臺要申請位置相關(guān)接口權(quán)限也就是wx.getLocation并填寫實際用途。用途說明要寫得很具體比如“用戶開啟附近功能后獲取其位置信息用于計算并展示與其他用戶的距離”不要只寫“用于附近的人”五個字太敷衍容易被駁回。第二小程序的隱私協(xié)議中要單獨說明位置信息的采集、使用、存儲方式包括存儲時長和用戶如何主動清除位置。這塊不僅是審核要求也是產(chǎn)品對用戶負責(zé)任的表現(xiàn)。第三功能層面必須支持用戶主動關(guān)閉附近展示。關(guān)閉后后端要立即刪除該用戶在 Redis GEO 中的記錄而不是僅僅在前端隱藏。我見過有些產(chǎn)品只在前端把按鈕關(guān)掉后端數(shù)據(jù)還在用戶隱私就存在隱患。5.2 審核被拒的常見原因我把審核時最容易踩的幾個坑整理成了表格被拒原因典型表現(xiàn)規(guī)避方法隱私接口未聲明一調(diào)用getLocation就被判違規(guī)在app.json和后臺同時完善隱私聲明強制授權(quán)用戶拒絕位置授權(quán)后完全沒法使用小程序允許游客模式位置作為可選功能用途說明太簡單審核員看不懂你為什么要做“附近的人”寫清產(chǎn)品場景、功能路徑、數(shù)據(jù)使用范圍展示他人精確坐標(biāo)地圖打點直接顯示其他用戶位置只返回距離文本不返回其他人的經(jīng)緯度位置數(shù)據(jù)沒有刪除路徑用戶關(guān)閉功能后數(shù)據(jù)仍保留關(guān)閉時清理后端 GEO 記錄提供聯(lián)系方式引導(dǎo)5.3 我踩過的一個真實坑我之前做過一版類似功能為了省事把用戶經(jīng)緯度直接放在接口返回值里前端在地圖上直接打點。結(jié)果審核被拒理由就是“展示用戶精確位置”。后來改成服務(wù)端只返回距離前端只顯示距離文本才通過。這個經(jīng)驗真的建議提前看位置數(shù)據(jù)不同于普通頭像昵稱一旦展示給陌生人帶來的安全隱患非常大。產(chǎn)品設(shè)計上寧可保守也別惹麻煩。6. 常見問題與排查實錄6.1 定位失敗或者授權(quán)彈窗不出現(xiàn)常見原因有三個requiredPrivateInfos沒配用戶之前拒絕過授權(quán)代碼里沒有處理fail回調(diào)。處理方案是在頁面啟動時主動引導(dǎo)授權(quán)如果用戶拒絕再通過wx.openSetting引導(dǎo)去設(shè)置頁打開授權(quán)。注意不要在小程序一啟動時就同時彈多個授權(quán)框體驗會非常差。6.2 坐標(biāo)看起來沒問題但距離差了好幾倍這個問題我排查過很多次基本就兩類原因坐標(biāo)系混用或者經(jīng)緯度字段寫反了。wx.getLocation返回的是longitude和latitude有的接口會簡寫成lng和lat復(fù)制代碼時很容易對錯位置。建議在請求后端前打一條日志實際打印出經(jīng)緯度再核對。6.3 Redis GEO 里能查到人小程序里卻看不到十有八九是后端接口字段名不匹配或者小程序的 request 合法域名沒有配置。開發(fā)階段可以在微信開發(fā)者工具里勾選“不校驗合法域名”但上線前一定要把接口域名加到 request 合法域名列表并確保接口是 HTTPS。6.4 數(shù)據(jù)量變大后查詢變慢怎么辦先用數(shù)據(jù)說話明確用戶量和 QPS 上限。Redis GEO 在百萬級點位上是毫秒級響應(yīng)一般產(chǎn)品根本到不了性能瓶頸。如果真遇到問題常見的優(yōu)化思路是按城市拆多個 GEO key比如nearby:users:beijing、nearby:users:shanghai查詢時根據(jù)目標(biāo)坐標(biāo)先定位城市再查對應(yīng) key。這個方案實現(xiàn)成本不高效果卻很明顯。6.5 真機調(diào)試和開發(fā)者工具定位結(jié)果不一致開發(fā)者工具里的定位是模擬的默認位置在北京或者你手動選擇的城市真機則是真實 GPS。這也解釋了為什么很多人開發(fā)時測試一切正常一上真機就發(fā)現(xiàn)距離計算不對。建議真機測試時去不同環(huán)境多試幾次室內(nèi)、室外、電梯里都跑一下看定位精度是否符合預(yù)期。我在實際做類似功能時踩過最多坑的不是后端代碼而是隱私審核和坐標(biāo)系。位置數(shù)據(jù)這個方向一旦口徑不統(tǒng)一、用途沒說清后面全是返工。最后再分享一個自用的小技巧上報位置時不要只存坐標(biāo)把設(shè)備的精度值也一并存下來。如果某次定位精度是 500 米距離展示就不要精確到“301 米”顯示“約 500 米內(nèi)”會更合理。這在審核和用戶感知上都更安全也更符合位置數(shù)據(jù)的真實精度水平。本文還有配套的精品資源點擊獲取