【定位】為什麼這個 App 必須「用完即丟」？長期追蹤是我們刻意不做的功能

當初在山區迷路，手機訊號微弱、電池電量耗盡的焦慮感，驅使我開發《FollowMe8》。這個 App 的核心目標很單純：確保車隊成員在戶外活動時「不跟丟」。然而，在開發過程中，我們面臨一個關鍵的抉擇：究竟要不要提供「長期歷史軌跡追蹤」功能？答案很明確：我們刻意不這麼做。

這個問題的衝突點在於：使用者直覺上會期待一個「追蹤型 App」能記錄完整的移動路線。但對於一個資源有限的獨立開發者來說，要實作這樣的功能，將帶來巨大的技術與維運負擔，更重要的是，它與「防走失」的原始初衷產生了根本的衝突。我們需要的是在關鍵時刻能找到隊友，而不是事後回顧每一寸走過的足跡。

我們內部仔細考慮了兩種方案：
1. 方案一（被放棄）：在伺服器端長時間儲存每個成員的連續位置座標序列，以便事後查閱或生成歷史軌跡。
2. 方案二（採納）：只儲存成員「最後的已知位置」，並在活動結束後自動清除所有相關位置數據。

之所以放棄方案一，主要基於三大考量：

首先是資源開銷。連續追蹤會產生大量的數據，無論是傳輸量還是儲存量，都會對手機電池和伺服器造成沉重負擔。在山區，每一格電池都彌足珍貴，我們無法接受為一個非核心功能犧牲續航力。這也意味著伺服器需要巨大的儲存空間和更複雜的查詢能力，對於單人維運的專案來說，這幾乎是不可能的任務。

其次是隱私權保護。若 App 具備「長期追蹤」的能力，無論其出發點多麼良好，都可能被誤解或濫用為監控工具。我們設計《FollowMe8》的理念是提供即時協助，而非侵犯個人隱私。我們希望使用者能放心開啟 App，知道它的數據是暫時的、安全的。

最後是架構簡潔性。為了實現「用完即丟」的策略，我們採用了極簡的數據處理方式。所有即時位置更新會先寫入 Redis 快取，其 Key 格式為 `loc:{activity_id}:{member_id}`，並設定了2 分鐘的 TTL (Time-To-Live)。這表示一旦成員停止更新位置超過 2 分鐘，他們的即時位置資訊就會自動從 Redis 中消失，被視為離線。同時，後端的 `activity_locations` 資料表也只會儲存每一個成員的「最後一筆已知位置」，欄位包含 `latitude, longitude, accuracy, has_gps, recorded_at`，不具備連續的時序軌跡。活動結束後，這些暫存數據也會隨之清除，Server 不保留任何歷史軌跡。

這個決策對用戶的實際影響是：你不會在《FollowMe8》中找到任何「我的足跡」或「歷史路線回顧」功能。取而代之的是一個極度省電、無感運行、且對隱私高度尊重的工具。它專注於當下，確保你在需要協助時，隊友能找到你。你得到的不是一份監控報告，而是一個緊急聯絡網，一個真正做到「防走失」的可靠夥伴。

👉 了解更多關於 FollowMe8 短期活動追蹤定位 App：
https://followme8.ofuyuan.com/