設計這樣的系統，第一步該想什麼？
上一篇把設計條件想清楚了：不需帳號、掃碼加入、只傳當下位置、活動結束資料消失。
聽起來只有四條，但攤開來看，每一條都在排除我們習慣的做法。
四個條件，四個限制
不需帳號，意味著不能用傳統的帳號密碼系統。沒有 email 驗證、沒有 OAuth（一種透過 Google / Apple 帳號快速登入的技術），也沒有「忘記密碼」這回事。使用者打開 App 就要能用。
掃碼加入，意味著活動裡的成員識別不能靠帳號，得靠別的東西。我需要一個臨時的認證機制，讓陌生人能在現場加入同一個活動。
只傳當下位置，意味著 Server（負責接收和轉發資料的主機）不需要儲存歷史軌跡。它只要知道「這個人現在在哪」，不需要知道「這個人去過哪」。
活動結束資料消失，意味著資料的生命週期要跟著活動走。活動結束，資料就該清掉——不是標記為已刪除，是真的不在了。
四個設計條件，不是功能清單，是限制條件。每一個限制都排除掉一部分現成的做法，剩下來的選項，才是真正需要決定的事。
系統的輪廓與關鍵決定
把限制條件攤開之後，系統需要的四個部分大致浮出來了：Client（手機端 App）、Server（中繼站）、資料庫、以及串起兩端的通訊協定。
這四個部分的關係其實不複雜：手機取得 GPS 位置傳給 Server，Server 轉發給同活動的其他人，手機收到後顯示在地圖上。活動結束，資料就清掉。
看起來簡單，但每一個部分背後都藏著選擇。而且有些決定會影響後面所有的選擇，順序搞錯就得砍掉重來。
我最後理出來的決策順序是這樣的：
第一個決定：Server 自己架，還是用別人的？
Firebase（Google 的雲端開發平台）能讓你不用管伺服器，直接寫 App。那為什麼不選最簡單的路？
最大的原因是成本風險：Firebase 按流量計費，初期測試階段流量小可能感覺不到，但萬一哪天流量爆增，帳單就不是自己能控制的了。加上我剛好有現成的主機和網域，自己寫的 Server 掌控性也最高——效能調校、抓蟲、資料怎麼存怎麼刪，全部自己說了算。
這個決定一旦下了，後面的技術選型全部跟著走。
第二個決定：既然自己架，Server 語言跟資料庫怎麼選？
Server 用 Go。Go 天生擅長處理大量同時連線，而且編譯後就是一個單獨的執行檔——部署到伺服器上就是放一個檔案、跑起來，不用額外裝環境。一個人管伺服器，簡單就是正義。
資料庫用 MySQL + Redis。MySQL 負責存活動、成員、Token 這些需要長期保留的結構化資料。Redis 則專門存即時位置——它的讀寫速度極快，而且可以設定資料「自動過期」，時間一到自己消失，完美配合「位置資料不留存」的設計條件。
第三個決定：沒有帳號，怎麼識別成員？
傳統做法是帳號 + 密碼，或者 OAuth。但我們不要帳號。那用什麼？Token——一組臨時代碼，掃碼或手動輸入就能加入活動。這個決定直接簡化了資料庫——不用設計帳號密碼表，也改變了 API 的認證方式。
第四個決定：手機和 Server 怎麼溝通？
WebSocket（維持持續連線的技術）即時性好，但手機長時間連線耗電量大。HTTP Polling（每隔固定時間主動向伺服器詢問）延遲幾秒，但省電得多。對於戶外活動的場景來說，手機電量是命，所以寧可接受延遲。
第五個決定：App 怎麼寫？為什麼不用跨平台框架？
這部分必須是 iOS 和 Android 雙平台同時開發。為什麼不先做一個平台試水溫？因為這是群體工具。只要車隊裡有一個人拿 Android，而你只做了 iOS 版，那個人整趟旅程就隱形了（或者整個車隊都不能用這套工具）。要讓「臨時加入同一個群體」這件事成立，就不能挑手機。
既然一定要雙平台，為什麼不用 React Native 或 Flutter 這種「寫一份程式碼蓋兩個平台」的省事做法？
因為這個 App 的核心是地圖和 GPS。地圖套件、定位權限、背景執行——這些在每個平台的底層行為都不一樣。用跨平台框架，這些差異不會消失，只是藏到更深的地方。出問題的時候，你要同時理解框架本身和底層平台，debug 的難度是兩倍，不是一半。
所以，我選擇用各自官方的最佳實踐：iOS 用 Swift + SwiftUI，Android 用 Kotlin + Jetpack Compose。
地圖的選擇也值得一提：iOS 用 Apple 原生的 MapKit，而 Android 我選了 OSM（OpenStreetMap，開放街圖）而不是 Google Maps。原因很簡單：Google Maps SDK 也是按用量計費，而 OSM 完全免費、且開源。對於一個還在測試階段的專案，能少一個計費風險就少一個。
獨立開發者的現實
這五個決定，如果是一個有完整團隊的公司在做，每一個都可以花好幾週研究、做 PoC（Proof of Concept，概念驗證）、比較方案。
但我是一個人。
一個人的意思是：沒有 DevOps（負責部署和維運的工程師）幫你管伺服器，沒有 DBA（資料庫管理師）幫你調效能，沒有資安團隊幫你做隱私合規。每一個你「選了但不夠理解」的技術，都會在三個月後變成只有你能修的坑。
所以選擇的標準不是「哪個技術最好」，是「哪個技術我能掌控」。
掌控的意思是：出問題的時候，我知道去哪裡找原因、我有能力修、修了之後我理解為什麼這樣修是對的。
系統的藍圖畫出來了，五個決定也都有了方向。接下來，就是把每個決定背後的細節攤開來看——第一個要深入的問題是：自己架 Server，實際上會遇到什麼？
想了解更多 FollowMe8 的設計故事，歡迎造訪 FollowMe8 官方網站。