Geolocation API 簡介與應用背景
讓網站知道使用者「在哪裡」,在現代網頁開發中已是常見需求。例如地圖服務需要使用者的即時位置、電商網站希望推薦附近的店鋪或優惠、社群平台允許使用者為貼文打卡標記地點等等。Geolocation API 就是為此誕生的 Web API,它允許網站透過瀏覽器取得使用者裝置的實體地理位置資訊(如經度、緯度座標,甚至海拔高度等),前提是使用者授權同意瀏覽器分享其位置。這項技術是 HTML5 規範的一部分,採用純前端 JavaScript 即可實作,不需要額外的外部套件。
應用情境範例:
- 地圖與導航服務: 在網頁中顯示地圖並標示使用者當前位置,提供路線導航或附近景點搜尋等功能。
- 在地化內容提供: 根據使用者所在地區,提供本地新聞、天氣預報或附近店家優惠資訊,提升內容的相關性。
- 社群打卡與地理標記: 使用者發布貼文或照片時附加所在位置(地理座標或地名),方便好友瞭解其動態並增進互動。
- 定位型提醒與服務: 根據使用者位置觸發特定動作,例如接近某地點時推送通知(如進入商場時推送優惠券)。
透過 Geolocation API,開發者可以為網站增添位置感知的能力,打造更貼近使用者情境的體驗。但同時,我們也必須謹慎處理權限請求與安全性,確保尊重使用者隱私。此外,不同方法的使用時機、各種裝置與瀏覽器的支援差異、錯誤處理等也都是重要考量。接下來,我們將深入介紹 Geolocation API 的實作方式,重點說明 navigator.geolocation.getCurrentPosition 與 watchPosition 兩種方法的差異與應用情境,並涵蓋權限、安全限制、錯誤處理機制,以及主流瀏覽器與行動裝置的支援情況。每個部分都會提供清晰的程式碼範例,最後還準備了常見問答(Q&A)單元,幫助您排解實作中遇到的疑難問題。
取得單次或持續位置:getCurrentPosition 與 watchPosition
在 Geolocation API 中,主要透過 navigator.geolocation 物件提供的方法來取得使用者的位置資訊。最常用的是兩種方法:
getCurrentPosition – 單次取得當前位置。
watchPosition – 持續監聽位置變化(追蹤多次位置更新)。
兩者的功能類似,但使用情境有所不同。簡單來說:如果您只需要當下的一次位置(例如取得使用者目前所在地來載入相關資訊),使用 getCurrentPosition 即可。而如果您需要連續追蹤使用者位置(例如導航地圖隨時更新使用者移動的座標),則應使用 watchPosition。以下我們分別介紹這兩種方法的用法與差異。
單次取得位置:使用 getCurrentPosition
navigator.geolocation.getCurrentPosition(success, error, options) 方法會嘗試一次性取得裝置的當前地理位置。在呼叫此方法時,瀏覽器會視情況向使用者請求定位權限。取得位置成功後,會呼叫您提供的 success 回呼函式並傳入 position 資料;如果失敗(例如使用者拒絕或無法取得位置),則呼叫 error 回呼函式。第三個參數 options 則是可選的設定,允許您調整取得位置的行為(例如是否要求高精度、逾時時間等,下文會詳述)。
一個基本的使用範例如下:
// 檢查瀏覽器是否支援 Geolocation API
if (navigator.geolocation) {
// 呼叫 getCurrentPosition 取得目前位置
navigator.geolocation.getCurrentPosition(
function(position) {
// 成功取得位置後的處理
const coords = position.coords;
console.log(`經度: ${coords.longitude}, 緯度: ${coords.latitude}`);
console.log(`精確度:約 ${coords.accuracy} 公尺`); // accuracy 提供位置精準度
},
function(error) {
// 無法取得位置(或遭拒絕)時的處理
console.error(`定位錯誤 (代碼: ${error.code}):${error.message}`);
}
);
} else {
console.log("此瀏覽器不支援 Geolocation API");
}
上述程式碼先以 if (navigator.geolocation) 檢查功能支援,再嘗試取得位置。getCurrentPosition 的第一個參數是成功回呼,在取得座標後被呼叫。position.coords 物件包含了位置資訊,如 latitude(緯度)、longitude(經度)、accuracy(以公尺為單位的位置精確度),以及可能存在的 altitude(海拔高度)、heading(移動方位)和 speed(移動速度)等屬性。範例中我們將經緯度打印到主控台,並讀取 accuracy 提示位置大約的誤差範圍。第二個參數是錯誤回呼,用來處理各種失敗情況(例如使用者拒絕定位或裝置無法取得定位訊號)。我們在錯誤回呼中將錯誤代碼和訊息輸出至主控台以供調試。最後,如果 navigator.geolocation 不存在(表示瀏覽器不支援),則提示不支援。這段程式碼充分展示了單次定位的基本流程。
使用情境: getCurrentPosition 適合用在只需取得一次位置的情況。例如地圖應用在載入時中心定位到使用者所在城市、天氣網站根據使用者當前位置顯示天氣預報、或社群平台在使用者發布內容時記錄一次所在地理標記。每次呼叫 getCurrentPosition 都是獨立的請求;如果需要再次取得最新位置,可以再次呼叫此方法(每次都會重新觸發權限檢查和定位程序)。然而,如果您的應用需要連續更新位置,多次呼叫 getCurrentPosition 並不是最佳做法——這時就該考慮 watchPosition。
持續監控位置:使用 watchPosition
navigator.geolocation.watchPosition(success, error, options) 用於持續監視裝置位置變化。呼叫此方法後,瀏覽器會在取得初始位置後持續監聽位置的更新,只要裝置位置發生變動或有新的定位資訊,就會反覆呼叫您提供的 success 回呼函式,傳入最新的 position 資料。與此同時,watchPosition 也會在發生錯誤時呼叫 error 回呼。這種方式非常適合需要實時追蹤使用者移動的情境,如導覽地圖、運動記錄應用(跑步路線追蹤)、叫車服務即時顯示車輛位置等。
watchPosition 會返回一個數字 ID,代表這個持續監聽的位置監視器。我們可以稍後使用此 ID 來停止追蹤。請看以下範例:
// 啟動持續追蹤使用者位置
const watchId = navigator.geolocation.watchPosition(
function(position) {
// 每當取得新位置時被呼叫
const coords = position.coords;
console.log(`使用者新位置:經度 ${coords.longitude}, 緯度 ${coords.latitude}`);
// 這裡可以更新地圖上使用者的位置標記,或執行其他追蹤相關的邏輯
},
function(error) {
console.error(`監控定位錯誤 (代碼: ${error.code}):${error.message}`);
},
{
enableHighAccuracy: false,
maximumAge: 5000,
timeout: 10000
}
);
// ... 根據應用情況,稍後在適當的時機停止監控
// 例如當不再需要追蹤時或使用者離開頁面:
navigator.geolocation.clearWatch(watchId);
在這段程式中,watchPosition 開始監控位置變化。一旦裝置獲取到定位或之後有更新,成功回呼函式就會被多次調用,我們在其中打印出每次更新的經緯度。您可以在此回呼中更新 UI,例如移動地圖上的標記點到新的座標、計算移動距離等。當不再需要繼續監控時,務必調用 navigator.geolocation.clearWatch(watchId) 並傳入先前取得的 ID,主動停止追蹤。這不僅可以節省裝置電量(持續定位會消耗電池),也避免不必要的背景定位行為。良好的實踐是:例如使用者關閉地圖頁面或切換功能時,就應該清除監聽。
使用情境: watchPosition 非常適合連續定位場景。例如,在導航應用中持續更新使用者在地圖上的位置從而實現即時導航指引;在交友或外送應用中實時分享自己位置給好友;在跑步健身類網站上連續取得位置計算路徑與距離等。需要注意的是,watchPosition 在網頁開啟期間持續運作,一旦使用者關閉該網頁或切換到不支援背景定位的情況,追蹤就會停止(瀏覽器不允許網頁在關閉後繼續獲取位置)。因此,持續定位通常只在使用者停留於該頁面時有效。
方法差異小結
- 呼叫時機: getCurrentPosition 每次呼叫只獲取一次定位;watchPosition 一次呼叫後可多次回傳更新位置。
- 典型用途: 單次定位用於取得初始狀態或偶爾需要的位置資訊;持續定位用於需要實時更新的位置追蹤。
- 停止方式: 單次定位不需要特別停止,取得一次結果即結束;持續定位需透過 clearWatch 主動停止。
- 資源耗用: 單次定位只啟動一次定位硬體;持續定位會保持定位硬體啟動狀態,因此更耗電和耗資源,務必在不需要時清除監聽。
- 權限提示: 兩者首次使用時都會觸發使用者授權提示(若尚未同意或拒絕),watchPosition 在監控過程中一般不會重複提示,但如果使用者在監控期間更改了權限(例如從允許改為拒絕),後續會收到錯誤。
瞭解了 getCurrentPosition 與 watchPosition 的差異後,開發者應根據實際需求選擇合適的方法。在很多應用中,兩者也能搭配使用:例如先用 getCurrentPosition 快速取得一次初始位置,再用 watchPosition 持續追蹤更新,確保應用對於位置變化有良好的響應。
權限請求與安全性考量
權限機制:
出於隱私與安全考量,瀏覽器在使用 Geolocation API 時必須取得使用者明確授權。也就是說,當您呼叫 getCurrentPosition 或 watchPosition 時,如果使用者尚未對您的網站做過「允許/拒絕共享位置」的選擇,瀏覽器會自動彈出一個權限請求對話框,詢問使用者是否允許取得其地理位置。如使用者選擇「允許」,您的回呼函式才有機會得到位置信息;如選擇「拒絕」,則會立即調用錯誤回呼並傳回權限被拒的錯誤(代碼值通常為 1,稍後介紹)。請注意,開發者無法繞過或預先取得這個權限詢問——它完全由瀏覽器控制。我們能做的是盡量優化使用者在授權時的體驗:
- 延後權限請求時機: 最佳實踐是不要在頁面載入時就馬上請求定位權限。相反地,應在使用者有相關操作意圖時才發起請求。例如使用者點擊「顯示我的位置」按鈕時再呼叫 Geolocation API。這可讓使用者瞭解請求位置的原因,避免權限對話框突然出現造成反感。
- 說明用途: 在介面上清楚告知為什麼需要位置資訊。例如在按鈕或提示文字上説明:「取得您的所在地以提供天氣資訊」等。讓使用者明白授權的位置資訊將帶來何種好處,有助於提高授權率。
- 權限預設狀態: 您可以透過瀏覽器的 Permissions API(如果支援)事先查詢 navigator.permissions.query({ name: 'geolocation' }) 了解當前權限狀態(granted 已授權,prompt 尚未決定,denied 已拒絕),以便決定是否顯示一些引導。雖然許多瀏覽器支援這項查詢,但仍應做好例外處理,因為部分環境可能不提供預檢查。
HTTPS 與安全限制:
現代瀏覽器出於安全考量,強制要求 Geolocation API 只能在安全上下文中使用。簡而言之,您的網頁必須透過 HTTPS 協定提供(或在本機開發時使用 http://localhost 等被視為安全的來源),否則定位請求將無法運作。自從數年前(例如 Chrome 從 50 版開始)實施這項限制後,所有主流瀏覽器皆遵循此安全策略:如果您的站點是經由非安全的 HTTP 協定加載,呼叫 getCurrentPosition 或 watchPosition 不會得到任何結果(通常瀏覽器會直接阻擋請求,甚至不會提示使用者授權)。因此,務必在生產環境為網站配置 HTTPS。開發階段則建議使用 localhost 作為主機進行測試,localhost 在大部分瀏覽器中被視作安全等同於 HTTPS。如果您直接以檔案檢視(file://)打開 HTML 做測試,不同瀏覽器的表現可能有所不同:有的允許定位,有的會當作不安全內容而阻止。最穩妥的方式是在本機架設一個開發用伺服器(例如使用 Node.js 的 lite-server、VS Code 的 Live Server 外掛等)來提供頁面,確保 Geolocation API 能正常運行。
除了協定限制,有些公司內網或特定情境下可能會透過瀏覽器的 Permissions Policy限制地理位置功能(例如在 <iframe> 中的第三方內容可能被預設禁止使用定位)。如果您在嵌入環境中使用 Geolocation API,要確認容器頁面是否設置允許地理位置權限。總的來說,大部分開發者只需記住「HTTPS 才能定位」這條鐵則,就能避免踩到瀏覽器安全限制的坑。
提示:確保在請求定位前,網站已經做好相應的 UI 提示。例如在地圖應用中,使用者點擊「定位」按鈕後,如果瀏覽器未能取定位(可能因為 HTTP 環境被擋下了),您應該提示使用者「必須使用 HTTPS 才能啟用定位功能」之類的訊息,而不是讓按鈕點擊沒反應。
錯誤處理機制
為何要處理錯誤:
並非每次定位請求都能順利取得結果。使用者可能拒絕授權、裝置可能暫時無法定位(例如 GPS 收不到信號),或定位過程超時等等。良好的應用應具備防禦性,妥善處理這些錯誤情況,給使用者適當的回饋或後續措施。Geolocation API 在調用 getCurrentPosition 或 watchPosition 時,如果發生問題,會呼叫您提供的錯誤回呼函式並傳入一個 error 物件,其中包含 code 和 message 屬性說明錯誤類型。error.code 是數字代碼,對應如下含義:
- 1 – 權限被拒 (PERMISSION_DENIED): 使用者拒絕了定位請求。也可能是使用者的裝置定位功能被停用,導致瀏覽器無法取得權限。此時應告知使用者未授權則無法取得位置,可提供重新嘗試的機會(但注意,多數瀏覽器在使用者明確點選拒絕後,不會再次自動彈窗詢問,除非使用者改變了權限設定)。
- 2 – 位置不可用 (POSITION_UNAVAILABLE): 瀏覽器無法取得定位資訊。可能是裝置的定位硬體(GPS、Wifi 等)無法提供位置,或裝置目前沒有連線(某些瀏覽器需要網路以解析位置)。這通常是暫時狀況,您可以提示使用者檢查裝置的「定位服務」是否已開啟,或稍後再試。
- 3 – 請求逾時 (TIMEOUT): 在您指定的等待時間內無法取得定位結果。這發生於您在 options 中設定了 timeout 閾值,而裝置在該時間內仍未回報位置。常見原因包括處於室內或遮蔽區域導致 GPS 遙遲定位。遇到逾時可建議使用者移動到開闊地點,或放寬允許等待的時間。
- 0 – 未知錯誤 (UNKNOWN_ERROR): 未預期的錯誤,無法歸類於上述任何一種的情況(代碼 0 非 W3C 標準定義,但某些瀏覽器可能使用它表示不明原因的失敗)。遇到此錯誤時只能告知使用者「發生未知的錯誤」,並建議稍後重試。
舉例來說,我們可以在錯誤回呼中根據代碼做不同處理:
navigator.geolocation.getCurrentPosition(successCallback, function(error) {
switch (error.code) {
case 1:
alert("您拒絕了定位請求,功能將無法提供服務。請允許位置存取或在瀏覽器設定中解除封鎖。");
break;
case 2:
alert("無法取得您的位置資訊。請確認裝置的定位功能已開啟,或稍後再試。");
break;
case 3:
alert("取得位置逾時,可能是訊號不佳。請移至空曠地區或稍後再嘗試。");
break;
default:
alert("定位過程發生未知錯誤,請重新嘗試。");
}
});
除了彈出提示,您也可以在介面上顯示友好的訊息,或提供替代方案:例如在定位失敗時允許使用者手動輸入所在地,或者降級使用根據 IP 推斷的大概位置(雖然不精準,但在使用者不願授權精確位置時,這可能是唯一能取得一些地理資訊的方式)。
逾時與選項設定: 開發者可透過 options 物件對定位請求進行一些控制,以降低發生錯誤的機率或影響。例如,設定一個合理的 timeout(毫秒)可以避免無限等待;使用 enableHighAccuracy 設為 true 時可以要求裝置使用高精度模式(如 GPS),但這可能使初次定位變慢。如果對時間要求很高,可以將 enableHighAccuracy 設為 false(預設值),瀏覽器可能優先返回較快速的粗略位置(例如透過 Wi-Fi / IP),在精度足夠應用的情況下,這比等待 GPS 有時更實用。另外,maximumAge 可以告訴瀏覽器允許返回快取中的舊位置:例如設為 maximumAge: 30000 表示接受最多 30 秒前的定位結果,這樣裝置如果有近期的定位資訊可用,就無需再次啟動硬體測定位,既加快響應也節省資源。合理運用這些選項有助於提高使用者體驗。例如在使用 watchPosition 持續追蹤時,可以設定較短的 timeout 和適當的 maximumAge,確保位置更新不至於太慢或停滯。
總而言之,一定要在程式中實作錯誤回呼,並處理以上各種情況。切忌將 Geolocation 當作百分之百可靠而不處理失敗,否則使用者在定位失敗時只會無所適從。此外,也要考慮使用者拒絕的情況屬於正常使用場景——網站應在這種情況下照常運行(只是沒有定位功能),或給出替代內容,而非完全崩潰。
各瀏覽器與裝置的支援差異
支援度概覽:
Geolocation API 早在 HTML5 時期就已成為 Web 標準的一部分,目前所有主流瀏覽器都對其提供了良好支援,包括 Chromium 核心的瀏覽器(Chrome、Edge、Opera 等)、Firefox、Safari 等,以及行動裝置上的內建瀏覽器(如Android 上的 Chrome、三星瀏覽器,iOS 上的 Safari、Chrome 等)。換言之,只要是現代的網頁瀏覽器,幾乎都可以使用 navigator.geolocation 提供的位置功能。即使是較早期的 IE9+ 瀏覽器也實作了這套 API(雖然老舊瀏覽器已不再常見於現代網路環境)。因此開發者大可放心地在 Web 應用中加入地理定位功能,同時為罕見的不支援情形實作回退方案即可。
桌面 vs 行動裝置:
不同裝置類型在定位方式和精度上可能有所差異。桌上型電腦或筆電通常沒有 GPS 模組,它們依賴網路連線資訊來定位,例如透過 IP 位址估測或 Wi-Fi 熱點位置資料庫。這意味著在桌面設備上取得的位置可能誤差較大(可能在數百公尺以上),且需要網際網路才能解析位置。而智慧型手機、平板等行動裝置大多配備 GPS、蜂巢網路和 Wi-Fi 定位,多重技術融合下通常可以取得相當精確的位置(誤差在幾公尺到幾十公尺內,視環境而定)。另外,行動裝置上的瀏覽器可能將定位結果快取更頻繁,以平衡耗電,因此連續多次請求可能得到相同結果(除非明確設定 maximumAge: 0 要求不使用快取)。行動端瀏覽器在介面上也可能將權限請求選項做得更細,例如 iOS Safari 上用戶可能可以選擇「僅此次允許」或「允許在未來 24 小時內使用」等。
不同瀏覽器的差異點:
雖然 API 介面在各大瀏覽器中是一致的,但在實際行為上仍存在些微差異。例如:
- 權限記憶:有些瀏覽器(如 Chrome)在使用者同意後,會記住該站點的授權狀態,下次造訪時再使用 Geolocation API 不會每次都彈窗;而某些瀏覽器或情境下(特別是 Safari)可能偏向每次都詢問或只記憶短時間。
- 精度與更新頻率:各瀏覽器對於 enableHighAccuracy 的實作略有不同。一般來說,開啟高精度會啟動 GPS,消耗更多電力且獲取速度較慢,但精度更高;關閉則可能僅用網路推算位置。不同瀏覽器對高精度的響應時間和誤差範圍優化各異。另外,watchPosition 的回傳頻率沒有明確標準,不同瀏覽器與裝置會根據裝置移動的物理情況、定位技術以及內部演算法決定何時提供新的位置——通常當使用者移動了一定距離或經過一定時間才更新,而不是毫秒級別的連續不斷更新。
- 缺失支援:極少數特殊瀏覽器可能不支援 Geolocation API。例如主打壓縮流量的舊版 Opera Mini,由於很多代請求在伺服器端進行,地理定位可能無法使用(或返回伺服器的位置而非用戶位置)。這類例子很罕見,但如果您的服務針對的用戶群體中存在這樣的環境,可能需要特別處理(例如檢測 user agent 並提示不支援)。
總的來說,相容性問題極少是 Geolocation API 的阻礙。在 HTML、JS 標準功能中,地理定位算是發展成熟且廣獲支援的一環。您大可遵循標準實作,同時加上上述的 navigator.geolocation 檢查以及錯誤回呼,就能覆蓋大多數情況。若要瞭解更詳細的瀏覽器版本支援,可以參考像 CanIUse 之類的相容性列表;不過在2025年來看,只要使用的是現代瀏覽器,都應能順利使用。
開發最佳實踐
為了讓 Geolocation 功能更順暢、安全且有效地融入您的應用,請考慮以下幾點最佳實踐:
- 在適當時機才請求定位: 切勿一上來就冒然要求使用者分享位置。應將權限請求與使用者操作建立關聯,例如點擊「查看附近資訊」按鈕時再觸發,避免突如其來的彈窗降低用戶信任。
- 解釋用途並尊重隱私: 向使用者明確說明請求位置的目的。如果只為了提供服務,不要收集或保存不必要的位置信息。若將位置上傳到伺服器,務必使用加密連線並遵守隱私規範,並在隱私政策中載明用途。
- 合理設定參數: 根據應用需求調整 enableHighAccuracy、timeout、maximumAge 等參數。不要一味追求最高精度而忽略速度與耗電,也不要無限制等待結果而導致用戶久無響應。找到精度與效率的平衡點,例如導航類應用可開啟高精度,新聞類應用則可接受較粗略但快速的定位。
- 善用快取結果: 如果您的應用對定位的實時性要求沒那麼高,使用 maximumAge 允許瀏覽器返回最近的快取位置,可大幅提升速度並減少硬體啟動次數。這對需要頻繁定位的場合(如每隔幾秒定位一次)尤為重要。
- 停止持續監控以節省資源: 切記在不需要時呼叫 clearWatch 停止 watchPosition。持續監控會消耗裝置電力以及(在某些裝置上)資料流量,故應避免遺漏清除。例如用戶離開相關頁面或功能時,就應該停止定位監聽。
- 測試各種情況: 在開發過程中,務必測試授權允許、拒絕、無法取得定位、緩慢定位等各種狀況。您可以使用瀏覽器開發者工具來模擬:以 Chrome 為例,開啟 DevTools 的「Sensors」面板,可以模擬不同城市的座標,甚至模擬「位置不可用」的狀態。確保您的應用在這些情境下都能有合理表現。
遵循上述原則,您可以在提供便利的同時,盡量減少 Geolocation 功能對使用者體驗的負面影響,並構築一個可靠、貼心的定位服務。
常見問答 (Q&A)
Q1: 為什麼我的網站在 HTTP 協定下無法使用 Geolocation 定位功能?
A1: 現代瀏覽器都要求 Geolocation API 只能在 HTTPS 安全環境中運行。如果您的網站以 http:// 提供,瀏覽器會阻止定位請求,導致您的程式碼看似沒有反應。解決方法是為網站配置 SSL/TLS 憑證,使其透過 https:// 存取。開發時您可在本機使用 localhost(瀏覽器將其視為安全來源)進行測試,或架設自簽章憑證的本機伺服器。總之,切換到 HTTPS 後問題即可迎刃而解。
Q2: 如果使用者點選「拒絕」提供位置,我該如何處理?可以再次請求權限嗎?
A2: 當使用者拒絕授權時,您的 Geolocation 回呼會收到一個 權限被拒 的錯誤(代碼 1)。此時應尊重使用者決定,停止後續定位嘗試,並提供對應的體驗降級方案,例如要求使用者手動輸入位置,或僅提供一般功能不涉及定位。大多數瀏覽器不會允許立即再次彈出權限詢問,除非使用者主動重新觸發或更改了設定。因此,您無法程式設計地「再次要求」權限(第二次呼叫 Geolocation API 通常會直接失敗而不彈窗)。比較好的做法是在 UI 上提供一個按鈕或提示,例如「定位功能已被關閉,點此重新嘗試啟用」,讓使用者明確知道可以再嘗試一次;當使用者點擊時再呼叫一次 getCurrentPosition,此時瀏覽器可能會再次詢問(具體行為視瀏覽器而定,有的會直接失敗,需要使用者去瀏覽器設定中手動解除封鎖)。總之,避免不停地自動請求權限,將選擇權交給使用者,並在拒絕後給出明確訊息是最恰當的處理方式。
Q3: 為什麼裝置無法取得定位訊號或一直顯示定位逾時?
A3: 可能的原因有幾種:其一,使用者裝置的定位服務被關閉(例如手機整體的 GPS 開關處於關閉狀態),導致瀏覽器拿不到位置。其二,所在環境可能無法取得足夠的定位訊號,例如處在密閉室內、地下室或信號弱區域,GPS 衛星訊號微弱,Wi-Fi / 行動網路訊號也不足,這會讓定位耗時很久甚至失敗。其三,若您沒有設定 timeout,定位請求可能一直處於等待狀態,看似「卡住」了。對策是:首先確認裝置的定位功能已開啟;其次可以引導使用者移動到空曠地、打開網路連線;另外在程式上加上 timeout 參數,例如 10 秒或 30 秒,確保在過久無結果時能返回錯誤,您可以提示使用者重試。也可以嘗試將 enableHighAccuracy 設為 false,允許瀏覽器先回傳較不精確但可能更快獲取的位置(例如基於基地台或 Wi-Fi 的粗略位置),以避免長時間等待。
Q4: 需要持續追蹤使用者位置時,我應該反覆呼叫 getCurrentPosition 還是使用 watchPosition?
A4: 建議使用 watchPosition。雖然您可以透過 setInterval 等方式定期調用 getCurrentPosition 達到反覆定位的效果,但這種方式效率較低,而且可能導致多次重複的權限提示(特別是在使用者尚未同意時)。watchPosition 則是專為連續追蹤設計的:它在第一次取得授權後會自動持續回報位置變化,直到您停止或頁面關閉為止。另外,watchPosition 方便您隨時停止(用 clearWatch),而自行輪詢 getCurrentPosition 則需要額外管理停止條件。基於性能和使用便利性考量,應首選 watchPosition 來實現實時定位追蹤。
Q5: 能否在網頁關閉或背景狀態下繼續取得使用者的位置?
A5: 一般情況下不行。瀏覽器出於隱私和電力考量,限制網頁只能在使用者與其互動的情況下存取地理位置。一旦頁面關閉,或(在行動裝置上)使用者切換至其他應用且瀏覽器不在前景,Geolocation API 將無法繼續提供位置更新。例如,您無法期望用戶關閉瀏覽器後您的網站仍在背景悄悄跟蹤他的移動——這在 web 平台上是不被允許的。某些先進的應用類型如安裝為 PWA(Progressive Web App)後,配合後端推送或特定 API,可能有限度地實現背景定位,但那已超出純前端範疇而且受嚴格限制。目前的 Geolocation API 本身無法在頁面關閉後繼續運作。如果您的需求包含長時間的背景定位追蹤,可能需要開發行動裝置原生 App 或尋找其他平台方案。
Q6: 為什麼我取得的經緯度座標精度不高?可以提高準確度嗎?
A6: 定位精度取決於裝置能力與使用的技術。桌面端通常只有 IP 或 Wi-Fi 定位,誤差在數百公尺是正常的;行動端如果只用了網路訊號定位,誤差也可能在數十至上百公尺。若要提高準確度,可以將 enableHighAccuracy: true 傳入 options,請求使用 GPS 等高精度方式。然而,即便如此,精度仍受環境限制——在開闊室外通常可精準到十公尺以內,但在室內或密集城市峽谷中誤差仍可能較大。此外,高精度模式會增大耗電和取得時間。如果您的應用確實需要盡可能精準的位置(例如導航轉彎指引),應啟用高精度並提示使用者到戶外開啟 GPS。但如果精度要求沒有那麼嚴苛(例如區域性推送消息),使用預設模式即可,因為過高要求可能得不償失。您也可以查看 position.coords.accuracy 值來判斷當前精度,如果誤差過大,通知使用者或嘗試重啟定位。
Q7: 在開發和測試時,有沒有辦法模擬不同的地理位置或情況?
A7: 可以的。現代瀏覽器的開發者工具大多提供了模擬地理位置的功能。例如在 Chrome 瀏覽器,打開開發者工具 (DevTools) 後,點擊右上角「三點選單」並選擇 More Tools -> Sensors(感應器);在出現的 Sensors 面板中,您可以設定自訂的緯度/經度來模擬裝置位置,或直接選擇預設城市,甚至可選「Location unavailable」來模擬無法取得定位的情況。透過這些工具,您可以方便地測試您的應用在不同地點以及不同權限情境(允許或封鎖定位)下的行為。Firefox 瀏覽器也有類似的功能(在開發者工具的設定中啟用「模擬位置」),Safari 則可以透過開發選單來設置模擬的 GPS 訊號。利用這些手段,您不需要真的跑到戶外或改變網路,就能驗證程式碼的正確性。
Q8: Geolocation API 可以直接取得人類可讀的地址嗎?
A8: 不行,Geolocation API 僅提供經緯度等座標資訊。若您想將座標轉換為實際的地址(例如「台北市信義區松高路××號」),需要調用第三方的地理編碼(Geocoding)服務。許多地圖平台提供對應的 API,可以根據經緯度查詢最近的地址或地標(例如 Google Maps Geocoding API、OpenCage Geocoder 等)。同樣地,若您有地址想取得座標,也需要反向地理編碼服務。這部分屬於後續應用層面的資料轉換,並非 Geolocation API 的功能範疇。換言之,Geolocation API 解答「使用者在哪裡(座標)」,但如果您的應用需要「這個座標是什麼地方(地址/地名)」,就要借助其他 API 來實現。此外,將經緯度用於地圖顯示也需要結合地圖服務的 SDK。這超出了本文範圍,但請知悉這是正常的——瀏覽器本身不內建地址解析,僅提供原始的地理座標。
經由以上講解,我們深入瞭解了如何在前端使用 Geolocation API 取得使用者位置,以及 getCurrentPosition 和 watchPosition 的差異與適用場景。我們說明了權限請求流程與安全限制(記得必須 HTTPS)、探討了錯誤碼與對應的處理方式,也比較了不同裝置與瀏覽器的支援情況。透過一系列程式碼範例,中級開發者應該能掌握如何將地理定位功能整合進自己的專案。在實作過程中,務必秉持對使用者隱私和體驗負責的態度:該請求時才請求,清楚告知用途,妥善處理任何可能的錯誤或拒絕。總而言之,Geolocation API 為 Web 應用帶來了強大的「位置」能力,只要運用得當,便能創造出更多貼近生活、智慧便利的功能。現在,您可以嘗試將本文的範例應用到實際項目中,為您的使用者打造更豐富的體驗!
