時區改來改去、地圖虛線量不準、開機就閃退：這幾天在修的三個隱形問題
這幾天我主要在處理「LiveHashigo」——一個幫人規劃連續跑攤行程的App。這次遇到的問題有個共同點：表面上看起來沒事，其實藏著沒注意到的狀況，從深夜時刻的計算方式、地圖上線條的粗細，到App一開機就當掉都有。
深夜時刻要跟著手機本身的時區走
App裡有一個功能，是在使用者查末班車的深夜時段時，幫忙算出「還有多久發車」「幾點會抵達」。這段時間該用哪個時區去算，看似小事，卻直接影響畫面上顯示的數字準不準。
現在的做法是照使用者手機本身設定的時區去計算，不會另外寫死成固定的某一個時區。原因是Google地圖、蘋果地圖算時間的時候，一律照著手機本身的時區走，使用者早就習慣這套邏輯；自己另外發明一套規則，只會讓行為跟其他App不一致。這裡接受的取捨是：如果系統內部傳遞的時間資訊本身跟畫面顯示對不太上，寧可讓畫面照使用者熟悉的方式顯示，也不去追求內部數字表面上的一致。
下次遇到系統顯示的時間跟預期兜不起來時，先看看使用者已經習慣的軟體是怎麼處理同一件事，照著約定俗成的做法走更省事。
note技術細節：ETA 時區換算的取捨
- build #4 實機回報：深夜0:30顯示與後端送出日本時間01:30對不上，一度改為 japanTime.ts 固定 UTC+9 換算（lateNightSlot、etaTimeFormat）。
- 使用者裁定「照大廠做法」後撤銷（commit c63e7e1），改回端末時區計算，刪除 japanTime.ts。
- 等車秒數（waitSecondsFromRequest／totalSecondsFromRequest）是時間點相減，不受時區影響，兩版皆保留。
地圖上的虛線比實線粗，先放著等上線後處理
行程裡的地圖會用不同的線條樣式代表不同的交通方式，有些畫實線、有些畫虛線。實機測試時發現，虛線看起來比實線粗上一大截，跟原本設計稿對不上。
問題出在畫地圖的底層元件本身，虛線的粗細不是單純調整數字就能完全修好，很可能跟虛線本身一段一段的繪製方式有關，拉伸時容易失真。目前的做法是針對虛線另外設一個縮放倍率去校正，多數情況下看起來已經正常，但推測仍有部分情況因為底層繪製方式的限制沒辦法完全修好。這裡接受的取捨是：先用校正過的數字讓外觀大致正確，把徹底解決留到之後，換取現在能繼續往下做其他功能。
下次遇到這種視覺上的細節落差，如果調整過後效果有限，可以考慮先設一個「堪用就好」的門檻，把問題記下來排到之後處理。
note技術細節：MapKit 虛線校正係數
- lineStyle.ts：MAPKIT_DASHED_STROKE_SCALE 由 0.4 調整為 0.55（依手機截圖量測：虛線約放大1.8倍、實線不放大）。
- 推論殘留問題為 MapKit 虛線點陣拉伸造成的視覺失真，非單純寬度設定可解。
- TASKS.md 將 ROUTE-11 轉為封存狀態，解除條件設為「上線後排優化」。
動畫效果讀取變數的順序算錯，讓App一開機就整個當掉
新版本裝到手機上，App一打開畫面還沒跑出來就直接閃退，錯誤訊息說找不到一個叫做「orb」的東西。這個「orb」其實是畫面上一顆會呼吸、會發光的小球動畫用到的一個內部變數。
問題出在這顆球的動畫效果被特別處理過，會丟到手機畫面渲染專用的執行環境去跑，讓動畫更順。這段程式裡有一個函式，它的參數預設值直接引用了外部傳進來的一個變數。但經過那個特殊處理後，程式碼裡讀取外部變數的動作，反而排在計算參數預設值之後，變數還沒準備好，程式就先跑去讀它，自然找不到。這個問題完全被自動化測試放過，因為測試環境是用一般方式模擬執行這段程式碼，不會真的經過那個轉換過程。
自動化測試全部通過，不代表拿到真手機上開起來一定沒事。特別是牽涉到畫面渲染、動畫這類需要丟到特殊執行環境去跑的程式碼，測試用的環境如果跟正式運作的環境不一樣，某些坑測試再多次也測不到。
note技術細節：worklet closure 求值順序
- orbMath.ts 的 advanceShaderTime 由 ListeningOrb 的 useFrameCallback 在 UI thread 呼叫。
- worklet 轉譯後結構近似
function f(a, b = orb.x) { const { orb } = this.__closure; ... }，預設參數先求值、closure 後取出，導致 ReferenceError。 - jest 在 node 環境把 worklet 當一般函式執行，行為測試無法觸發此轉譯後的求值順序問題。
接下來
- 地圖虛線的優化留到App正式上線後再處理
- 上一輪修改留下的問題，一個還在等驗證、一個才剛列進待辦
- 等最新一次內部測試版本在手機上實際跑過的驗證結果
本篇由跨專案自動彙整產生，素材為 2026-09-25 之後 4 個專案的提交紀錄與 0 則知識投遞。