設計這樣的系統，第一步該想什麼？
上一篇把需求的定位說清楚了：不走失、賦能領隊、簡單輕量——這三件事是工具要守護的底線。
但需求的定位只講了「要做什麼」，沒說「怎麼做」。把這三件事翻成系統要承擔的工作，限制條件就出來了。
從核心翻成系統要做的事
不走失——即時看到隊友位置，落單時能接回、有狀況能傳訊號。系統要做的是把每個人的位置同步到同一張地圖上，不能丟失、不能延遲太久。
賦能領隊——領隊要一眼看到全隊、要能廣播、要能在活動結束時一次解散。系統要為「帶頭那個角色」留出控管介面，而不是把每個使用者都當成平等的個體。
簡單輕量——不需要帳號、不需要事前建群、掃個碼就加入。這意味著沒有傳統帳號密碼系統、沒有 email 驗證、沒有 OAuth 登入，也沒有「忘記密碼」這回事。
還有一條附加價值值得一起擺進去：隱私零煩惱——位置資料在活動期間存在，活動結束就自然過期。Server 只需要知道「這個人現在在哪」，不需要留「這個人去過哪」。這一條是領隊說服團員下載的武器。
四條擺出來，不是功能清單，是限制條件。每一條都排除掉一部分現成做法，剩下的選項才是真正需要決定的事。
系統的輪廓與關鍵決定
把限制條件攤開之後，系統需要的四個部分就清楚了：手機端 App、Server（中繼站）、資料庫、以及串起兩端的通訊協定。
這四個部分的關係其實不複雜：手機取得 GPS 位置傳給 Server，Server 轉發給同活動的其他人，手機收到後顯示在地圖上。活動結束，資料就清掉。
看起來簡單，但每一個部分都還有選擇要做。而且有些決定會影響後面所有的選擇，順序搞錯就得砍掉重來。
我最後理出來的決策順序是這樣的：
第一個決定：Server 自己架，還是用別人的？
Firebase 能讓你不用管伺服器，直接寫 App。但它按流量計費，對一個沒有收益模式的活動類 App 來說，這個變數不太好控——下一篇會把這筆帳算一次。加上我剛好有現成的主機和網域，自架的成本可控、調整也直接，最後決定走自架這條路。
第二個決定：Server 語言跟資料庫怎麼選？
Server 用 Go，資料庫用 MySQL + Redis。Go 部署單純；MySQL 存活動、成員、Token 這類結構化資料；Redis 處理即時位置——讓位置資料只活在記憶體裡，活動結束就過期。這套組合怎麼承擔即時更新、又怎麼支撐「不留軌跡」的隱私承諾，下一篇會展開。
第三個決定：沒有帳號，怎麼識別成員？
傳統做法是帳號 + 密碼，或者 OAuth。但我們不要帳號。那用什麼？兩個東西：Token + 裝置綁定。Token 是一組臨時代碼，掃碼或手動輸入就能加入活動；裝置綁定則是讓每支手機產生一組唯一識別碼，Server 靠這組識別碼知道「這支手機是誰」，不需要你填名字或登入。這個決定直接簡化了資料庫——不用設計帳號密碼表，也改變了 API 的認證方式。
第四個決定：手機和 Server 怎麼溝通？
WebSocket 即時性好，但手機長時間連線耗電量大。HTTP Polling 延遲幾秒，但省電得多。對戶外活動來說手機電量是命，所以寧可接受延遲。
第五個決定：App 怎麼寫？為什麼不用跨平台框架？
這個工具最終一定要有 iOS 和 Android 兩個版本。原因很現實：這是群體工具，只要車隊裡有一個人拿 Android，而你只有 iOS 版，那個人整趟旅程就隱形了（或者整個車隊都不能用這套工具）。要讓「臨時加入同一個群體」這件事成立，就不能挑手機。
但一個人不可能同時蓋兩棟房子。我的做法是：先把 iOS 版的所有細節做完——流程、UI、架構全部定案，等 iOS 上架的同時，再接著開發 Android 版。 先用一個平台把所有設計問題想透，第二個平台就是照著已經驗證過的設計去實作，效率高很多。
那為什麼不用 React Native 或 Flutter 這種「寫一份程式碼蓋兩個平台」的省事做法？
因為這個 App 的核心是地圖和 GPS。地圖套件、定位權限、背景執行——這些在每個平台的底層行為都不一樣。用跨平台框架，這些差異不會消失，只是藏到更深的地方。出問題的時候，你要同時理解框架本身和底層平台，debug 的難度是兩倍，不是一半。
所以，我選擇用各自官方的最佳實踐：iOS 用 Swift + SwiftUI，Android 用 Kotlin + Jetpack Compose。
地圖的選擇也值得一提：iOS 用 Apple 原生的 MapKit，Android 則選了 OpenStreetMap 而不是 Google Maps。原因很簡單：Google Maps SDK 也是按用量計費，OSM 完全免費且開源。對一個還在測試階段的專案來說，能少一個計費風險就少一個。
這五個重點背後的共同標準，是簡單、好維護——架構單純、部署直接，未來真有狀況也容易追。
系統的藍圖畫出來了，也整理出五個關鍵的技術重點。接下來，就是把每個重點背後的細節攤開來看——第一個要深入的問題是：自己架 Server，實際上會遇到什麼？
想了解更多 FollowMe8 的設計故事，歡迎造訪 FollowMe8 官方網站。