## Case #2: 中點估計法與誤差上界的工程化落地

### Problem Statement（問題陳述）
業務場景：在搶票倒數時，需要把握按鍵時刻。即便能從 HTTP 取得 Date，仍面臨網路往返不均衡的問題，無法知道伺服器何時產生此標頭。需要一個在工程上可接受、簡單可用的近似方法給使用者依據。
技術挑戰：T1/T2 無法直接測得，傳輸時間不對稱，Date 可能代表的是訊息產生時間而非到達時間。
影響範圍：若估算法不一致，顯示時間將偏快或偏慢，影響使用者判斷。
複雜度評級：中

### Root Cause Analysis（根因分析）
直接原因：
1. 只有 t0、t3 可測；t1、t2 不可測。
2. 上/下行延遲不對稱，單邊延遲差異導致偏差。
3. Date 標示點可能位於 T1~T2 中任一點（不可精確）。
深層原因：
- 架構層面：HTTP 非對時協議，未設計精準時刻對齊。
- 技術層面：缺少傳輸時間細節與伺服器產生標頭時間戳。
- 流程層面：未做多樣本統計降低不確定性。

### Solution Design（解決方案設計）
解決策略：採用中點估計法 t1' ≈ t0 + (t3 - t0)/2 作為近似伺服器時間對齊點，並將最大誤差估為 RTT/2；以此給出明確誤差上界，供使用者風險評估。

實施步驟：
1. 計算 RTT 與中點
- 實作細節：測量 t0、t3；midpoint = t0 + RTT/2
- 所需資源：HttpClient、時間 API
- 預估時間：0.3 小時

2. 套用中點近似與誤差上界展示
- 實作細節：offset = serverDate - midpoint；顯示 maxError=RTT/2
- 所需資源：UI 控制項
- 預估時間：0.5 小時

3. 使用者策略建議
- 實作細節：在 maxError 仍大的狀況，建議提前或延後按鍵策略
- 所需資源：文案
- 預估時間：0.2 小時

關鍵程式碼/設定：
```csharp
var t0 = DateTimeOffset.UtcNow;
var rsp = await client.SendAsync(req, HttpCompletionOption.ResponseHeadersRead);
var t3 = DateTimeOffset.UtcNow;

var date = rsp.Headers.Date!.Value; // RFC1123, UTC
var rttMs = (t3 - t0).TotalMilliseconds;

var midpoint = t0.AddMilliseconds(rttMs / 2);
var offset = date - midpoint;
var maxErrorMs = rttMs / 2.0;

// UI 呈現
labelOffset.Text = $"Offset: {offset.TotalMilliseconds:F0} ms, MaxError: {maxErrorMs:F0} ms";

## Case #3: 使用 HEAD 與 ResponseHeadersRead 降低負載與延遲

### Problem Statement（問題陳述）
業務場景：對時時只需 Date 標頭，若下載整頁（HTML/CSS/JS）將浪費頻寬且增加等待時間，也可能對目標站造成多餘負載，甚至觸發風控。
技術挑戰：如何只取得標頭，不下載主體，同時縮短等待時間以降低 RTT。
影響範圍：頻寬浪費、延遲加大、被禁止訪問風險提升。
複雜度評級：低

### Root Cause Analysis（根因分析）
直接原因：
1. GET 預設會抓取內容，造成多餘資料傳輸。
2. 等待內容下載會拉長 t3 時刻，RTT 膨脹。
3. 頻繁大流量請求可能被目標站封鎖。
深層原因：
- 架構層面：未區分「標頭需求」與「內容需求」。
- 技術層面：不熟悉 HttpCompletionOption.ResponseHeadersRead。
- 流程層面：無負載意識，對時策略不節制。

### Solution Design（解決方案設計）
解決策略：以 HEAD 請求只取回應標頭、並設定 ResponseHeadersRead 讓回應在標頭到達即可返回，避免下載 body，縮短整體耗時與負載。

實施步驟：
1. 改用 HEAD 請求
- 實作細節：HttpMethod.Head
- 所需資源：HttpClient
- 預估時間：0.2 小時

2. 只讀標頭即返回
- 實作細節：HttpCompletionOption.ResponseHeadersRead
- 所需資源：程式碼調整
- 預估時間：0.2 小時

3. 驗證節流
- 實作細節：一次對時即可，不連續輪詢
- 所需資源：UI 提示
- 預估時間：0.3 小時

關鍵程式碼/設定：
```csharp
var req = new HttpRequestMessage(HttpMethod.Head, "/");
// 回應一拿到標頭就返回，避免等待 body
var rsp = await client.SendAsync(req, HttpCompletionOption.ResponseHeadersRead);

## Case #4: URL 防呆與常見輸入錯誤處理

### Problem Statement（問題陳述）
業務場景：使用者常輸入不完整 URL（缺少 http://）、留空或貼錯網址，導致程式崩潰或對時失敗，影響搶票關鍵作業。
技術挑戰：需在對時前確保 URL 格式正確、可連線，避免例外。
影響範圍：工具可靠性、使用者信任、臨場時間浪費。
複雜度評級：低

### Root Cause Analysis（根因分析）
直接原因：
1. URL 缺少協定（http/https）。
2. 非法字元或空字串。
3. BaseAddress 與相對路徑組合錯誤。
深層原因：
- 架構層面：UI 未建立輸入驗證層。
- 技術層面：未使用 Uri.TryCreate 正確解析。
- 流程層面：缺乏交互提示與預設修正策略。

### Solution Design（解決方案設計）
解決策略：增加 URL 驗證與自動補全協定；在無效時提示並阻止對時，確保後續流程穩定。

實施步驟：
1. 驗證與補全
- 實作細節：Uri.TryCreate；若無協定預設加 http://
- 所需資源：C# 基礎
- 預估時間：0.3 小時

2. 預檢可連線
- 實作細節：可選 HEAD ping 或 DNS 解析檢查
- 所需資源：HttpClient/DNS
- 預估時間：0.5 小時

3. 友善提示
- 實作細節：UI 錯誤訊息與修正建議
- 所需資源：UI 文案
- 預估時間：0.2 小時

關鍵程式碼/設定：
```csharp
bool TryNormalizeUrl(string input, out Uri baseUri)
{
    baseUri = null!;
    if (string.IsNullOrWhiteSpace(input)) return false;

    if (!input.StartsWith("http://") && !input.StartsWith("https://"))
        input = "http://" + input;

    return Uri.TryCreate(input, UriKind.Absolute, out baseUri) &&
           (baseUri.Scheme == Uri.UriSchemeHttp || baseUri.Scheme == Uri.UriSchemeHttps);
}

## Case #5: 正確解析 RFC1123 Date 與時區/文化陷阱

### Problem Statement（問題陳述）
業務場景：HTTP Date 為 RFC1123 格式（GMT/UTC），若以 DateTime.Parse 使用本地文化或未處理時區，會產生偏移錯誤，導致 offset 計算失準。
技術挑戰：處理 RFC1123 格式、統一為 UTC、避免文化差異和 DST 問題。
影響範圍：對時結果偏差、誤差上界失真。
複雜度評級：中

### Root Cause Analysis（根因分析）
直接原因：
1. 使用 DateTime.Parse 可能受本地文化影響。
2. 未指定 DateTimeStyles，導致 Kind 不一致。
3. 忽略 RFC1123 固定 UTC 事實。
深層原因：
- 架構層面：時間處理未統一 UTC。
- 技術層面：未採 DateTimeOffset 與固定格式。
- 流程層面：缺少解析失敗的防護與回退。

### Solution Design（解決方案設計）
解決策略：使用 DateTimeOffset 與 TryParseExact("r", InvariantCulture, AssumeUniversal | AdjustToUniversal) 解析 Date；內部一律採 UTC 計算。

實施步驟：
1. 解析固定格式
- 實作細節：TryParseExact("r")
- 所需資源：System.Globalization
- 預估時間：0.3 小時

2. 一律使用 UTC（DateTimeOffset）
- 實作細節：運算與儲存皆用 UTC
- 所需資源：C# 時間 API
- 預估時間：0.3 小時

3. 解析失敗處理
- 實作細節：錯誤訊息與回退策略
- 所需資源：例外處理
- 預估時間：0.3 小時

關鍵程式碼/設定：
```csharp
using System.Globalization;

bool TryParseHttpDate(IEnumerable<string> values, out DateTimeOffset utc)
{
    utc = default;
    var s = values?.FirstOrDefault();
    if (string.IsNullOrEmpty(s)) return false;

    return DateTimeOffset.TryParseExact(
        s, "r", CultureInfo.InvariantCulture,
        DateTimeStyles.AssumeUniversal | DateTimeStyles.AdjustToUniversal,
        out utc);
}

## Case #6: 缺少或格式錯誤的 Date Header 之容錯

### Problem Statement（問題陳述）
業務場景：部分情況（1xx/5xx、伺服器無時鐘）可能不返回 Date；或代理重寫、格式異常，對時流程中斷。
技術挑戰：需在不可靠的 HTTP Date 下維持穩定體驗，並提供對策。
影響範圍：對時失敗、使用者在關鍵操作前無法獲取準確時間。
複雜度評級：中

### Root Cause Analysis（根因分析）
直接原因：
1. RFC 允許特定例外不帶 Date。
2. 代理/快取鏈可能修改或添加 Date。
3. 不規範回應導致解析失敗。
深層原因：
- 架構層面：時間來源非強一致。
- 技術層面：未做 header 驗證與降級策略。
- 流程層面：缺乏錯誤回饋與重試機制。

### Solution Design（解決方案設計）
解決策略：在取樣前檢查狀態碼與 Date 是否存在；無效時提示重試/更換端點；可選擇多端點測量，或回退至替代頁面/資源。

實施步驟：
1. 先檢狀態碼
- 實作細節：避免用 5xx/1xx 結果
- 所需資源：HttpStatusCode
- 預估時間：0.2 小時

2. 檢查 Date 存在性與格式
- 實作細節：rsp.Headers.Date.HasValue 與 TryParseExact
- 所需資源：解析程式
- 預估時間：0.3 小時

3. 提示與重試
- 實作細節：UI 提示、退回 GET 或其他 URL
- 所需資源：UI / 回退策略
- 預估時間：0.5 小時

關鍵程式碼/設定：
```csharp
if (!rsp.IsSuccessStatusCode)
    throw new HttpRequestException($"HTTP {(int)rsp.StatusCode}");

if (!rsp.Headers.Date.HasValue)
    throw new InvalidOperationException("Server response has no Date header.");

var serverUtc = rsp.Headers.Date.Value; // UTC

## Case #7: 服務端狀態碼例外處理（1xx/5xx）與安全回退

### Problem Statement（問題陳述）
業務場景：對時請求碰到 100/101（協商）、500/503（故障）等狀態碼時，Date 可缺失或不可靠；需安全終止或回退。
技術挑戰：避免使用不可靠時間、同時提供替代方案而不中斷流程。
影響範圍：誤導使用者、產生錯誤 offset。
複雜度評級：低

### Root Cause Analysis（根因分析）
直接原因：
1. RFC 容許某些狀態碼不帶 Date。
2. 故障時刻的 Date 不保證有效。
3. 同步流程未檢查狀態碼。
深層原因：
- 架構層面：請求恢復與回退機制缺失。
- 技術層面：狀態碼語義未對應邏輯。
- 流程層面：無指引與錯誤 UI。

### Solution Design（解決方案設計）
解決策略：屏蔽 1xx/5xx 結果；回退至 GET 或其他端點路徑；在 UI 顯示可行建議（稍後重試、換路徑）。

實施步驟：
1. 狀態碼判斷
- 實作細節：rsp.StatusCode 範圍過濾
- 所需資源：HTTP 基礎
- 預估時間：0.2 小時

2. 回退策略
- 實作細節：從 HEAD→GET（見 Case #8）、換 /health 或 /robots.txt
- 所需資源：HttpClient
- 預估時間：0.5 小時

3. UI 指引
- 實作細節：顯示清楚的建議與下一步
- 所需資源：UI
- 預估時間：0.3 小時

關鍵程式碼/設定：
```csharp
if ((int)rsp.StatusCode >= 500 || (int)rsp.StatusCode < 200)
{
    // 500+ or 1xx/非 2xx 視為不可靠
    // 回退建議：改 GET 或改路徑
    throw new HttpRequestException($"Unreliable status: {rsp.StatusCode}");
}

## Case #8: HEAD 不支援時的 GET 回退且不下載 body

### Problem Statement（問題陳述）
業務場景：部分網站不支援 HEAD，或對 HEAD 設限；需要以 GET 回退，但仍須避免下載內容，以維持輕量與快速。
技術挑戰：如何以 GET 只讀標頭即返回，不消耗流量與時間。
影響範圍：若錯用 GET 下載全頁，RTT 變大且負載上升。
複雜度評級：中

### Root Cause Analysis（根因分析）
直接原因：
1. HEAD 被封鎖或回應不規範。
2. GET 預設會下載內容。
3. 未善用 ResponseHeadersRead 或提早終止。
深層原因：
- 架構層面：缺乏回退策略。
- 技術層面：不熟悉 headers-only 讀取技巧。
- 流程層面：未在回退時保持輕量原則。

### Solution Design（解決方案設計）
解決策略：使用 GET + ResponseHeadersRead，在讀到標頭後立即計時與解析 Date，不讀取 Content，並及時 Dispose/取消以避免下載。

實施步驟：
1. 改用 GET + HeadersRead
- 實作細節：SendAsync(HttpMethod.Get, ResponseHeadersRead)
- 所需資源：HttpClient
- 預估時間：0.3 小時

2. 及時釋放
- 實作細節：不讀 Content，Dispose rsp 與 HttpClient
- 所需資源：C#
- 預估時間：0.2 小時

3. 路徑優化
- 實作細節：優先選擇小資源路徑
- 所需資源：站點觀察
- 預估時間：0.3 小時

關鍵程式碼/設定：
```csharp
var req = new HttpRequestMessage(HttpMethod.Get, "/");
var t0 = DateTimeOffset.UtcNow;
using var rsp = await client.SendAsync(req, HttpCompletionOption.ResponseHeadersRead);
var t3 = DateTimeOffset.UtcNow;

// 僅用標頭，不讀內容
var date = rsp.Headers.Date ?? throw new InvalidOperationException("No Date header");
// 之後立即 Dispose rsp 以避免下載 body

## Case #9: 多次取樣擇最小 RTT 降低最大誤差

### Problem Statement（問題陳述）
業務場景：單次取樣易受抖動影響，RTT 偶發增大使最大誤差過大；搶票前希望降低上界以提升信心。
技術挑戰：如何在不增加太多負載的前提下降低不確定性。
影響範圍：誤差上界偏大、判斷困難。
複雜度評級：中

### Root Cause Analysis（根因分析）
直接原因：
1. 網路抖動導致偶發高延遲。
2. 單樣本缺乏統計穩定性。
3. RTT/2 上界對大 RTT 敏感。
深層原因：
- 架構層面：缺少樣本策略。
- 技術層面：未實作多樣本選擇。
- 流程層面：未限制取樣數與節流。

### Solution Design（解決方案設計）
解決策略：連續取樣 N 次（例如 3–5 次），選擇 RTT 最小的一次作為對時依據（近似最接近對稱傳輸），或取多次中位數；並限制 N 以避免負載。

實施步驟：
1. 迭代取樣
- 實作細節：短時間內重複 HEAD 3–5 次
- 所需資源：HttpClient
- 預估時間：0.5 小時

2. 選擇策略
- 實作細節：取 RTT 最小或中位數
- 所需資源：Linq
- 預估時間：0.3 小時

3. 節流控制
- 實作細節：限制 N 與頻率
- 所需資源：設定項
- 預估時間：0.2 小時

關鍵程式碼/設定：
```csharp
async Task<(TimeSpan Offset, double MaxErrorMs)> SyncBestOfAsync(string url, int samples = 5)
{
    var results = new List<(TimeSpan offset, double err, double rtt)>();
    for (int i = 0; i < samples; i++)
    {
        var (o, e) = await SyncOnceAsync(url); // 參見 Case #1
        results.Add((o, e, e * 2)); // rtt = 2 * maxError
        await Task.Delay(100); // 小間隔，避免壓測
    }
    var best = results.OrderBy(r => r.rtt).First();
    return (best.offset, best.err);
}

## Case #10: 高頻時鐘渲染（30ms）與 Stopwatch 降漂移

### Problem Statement（問題陳述）
業務場景：UI 需每 30ms 更新顯示「伺服器時鐘」，若以 DateTime.Now 疊加 offset 直接更新，可能有系統 timer 漂移與抖動，導致顯示不穩。
技術挑戰：Windows 計時精度與 UI 計時器 jitter，如何讓顯示更穩定。
影響範圍：使用者信心下降，按鍵時機判斷受干擾。
複雜度評級：中

### Root Cause Analysis（根因分析）
直接原因：
1. UI Timer 精度有限（~15.6ms 基線）。
2. DateTime.Now 精度不穩定。
3. 每次取 Now 疊加 offset 累積誤差。
深層原因：
- 架構層面：顯示層未用高精度時間源。
- 技術層面：未使用 Stopwatch 追蹤 elapsed。
- 流程層面：更新節奏與顯示未分離。

### Solution Design（解決方案設計）
解決策略：同步成功時記錄基準本機 UTC 與伺服器 UTC，之後用 Stopwatch.Elapsed 增量計算；UI 30ms 更新僅負責顯示，時間源以 elapsed 計算，降低漂移。

實施步驟：
1. 建立基準
- 實作細節：baseLocalUtc、baseServerUtc 計入 offset
- 所需資源：SyncOnce 結果
- 預估時間：0.5 小時

2. 高精度計時
- 實作細節：Stopwatch.Start；serverNow = baseServerUtc + elapsed
- 所需資源：Stopwatch
- 預估時間：0.5 小時

3. UI 更新
- 實作細節：Timer 30ms 刷新顯示 serverNow
- 所需資源：WinForms/WPF
- 預估時間：0.5 小時

關鍵程式碼/設定：
```csharp
private Stopwatch _sw = new Stopwatch();
private DateTimeOffset _serverBaseUtc;

void StartDisplay(TimeSpan offset)
{
    _serverBaseUtc = DateTimeOffset.UtcNow + offset;
    _sw.Restart();

    uiTimer.Interval = 30; // ms
    uiTimer.Tick += (_, __) =>
    {
        var serverNow = _serverBaseUtc + _sw.Elapsed;
        labelClock.Text = serverNow.ToLocalTime().ToString("yyyy-MM-dd HH:mm:ss.fff");
    };
    uiTimer.Start();
}

## Case #11: 指標可視化：Offset 與最大誤差輔助決策

### Problem Statement（問題陳述）
業務場景：對時後，使用者需要快速理解「當前偏差」與「可能最大誤差」，以決定是否立刻搶購或重試對時，提升成功率。
技術挑戰：如何把抽象延遲轉成直觀指標，並做到低干擾的 UI 呈現。
影響範圍：決策品質與使用者信心。
複雜度評級：低

### Root Cause Analysis（根因分析）
直接原因：
1. 單顯示時鐘不足以傳達可靠性。
2. 使用者缺乏 RTT 概念。
3. 缺少明確「高/中/低風險」提示。
深層原因：
- 架構層面：UI 無指標層。
- 技術層面：未輸出 RTT/2。
- 流程層面：缺少操作建議。

### Solution Design（解決方案設計）
解決策略：在 UI 顯示 offset 與 max error；採顏色/圖示分級提示（綠/黃/紅），並提供建議（ex: 誤差>150ms 建議再取樣）。

實施步驟：
1. 指標計算
- 實作細節：offset 與 RTT/2
- 所需資源：前序結果
- 預估時間：0.2 小時

2. 視覺化
- 實作細節：顏色分級、圖示、提示語
- 所需資源：UI 控制項
- 預估時間：0.5 小時

3. 操作建議
- 實作細節：依閾值提供行動（重試、可用）
- 所需資源：文案
- 預估時間：0.3 小時

關鍵程式碼/設定：
```csharp
void UpdateIndicators(TimeSpan offset, double maxErrorMs)
{
    labelOffset.Text = $"時間差: {offset.TotalMilliseconds:F0} ms, 最大誤差值: {maxErrorMs:F0} ms";

    if (maxErrorMs <= 80) { labelOffset.BackColor = Color.LightGreen; }
    else if (maxErrorMs <= 150) { labelOffset.BackColor = Color.Khaki; }
    else { labelOffset.BackColor = Color.LightCoral; }
}

## Case #12: 節流與避封策略：一次對時、不頻繁抓取

### Problem Statement（問題陳述）
業務場景：搶票前若頻繁發送對時請求，可能造成目標站負載或觸發風險控制（封鎖 IP）。需要設計節流策略。
技術挑戰：在保持準確性的同時，將請求頻率降至最低，避免不必要的風險。
影響範圍：封鎖/黑名單、法務與道德風險、無法下單。
複雜度評級：低

### Root Cause Analysis（根因分析）
直接原因：
1. 過度輪詢導致負載。
2. HEAD/GET 請求過密。
3. 無最小間隔控制。
深層原因：
- 架構層面：無節流管理。
- 技術層面：缺乏時間戳限制。
- 流程層面：使用者操作缺少規範。

### Solution Design（解決方案設計）
解決策略：只在設定時計算一次；對時後以本地 offset 顯示；設定最小重試間隔（如 60s），提供「手動刷新」按鈕。

實施步驟：
1. 最小重試間隔
- 實作細節：lastSyncAt 與 Now 比對
- 所需資源：程式邏輯
- 預估時間：0.3 小時

2. 手動刷新
- 實作細節：UI 提供按鈕，顯示剩餘冷卻時間
- 所需資源：UI
- 預估時間：0.3 小時

3. 記錄次數
- 實作細節：當日對時次數限制
- 所需資源：設定
- 預估時間：0.2 小時

關鍵程式碼/設定：
```csharp
DateTimeOffset? _lastSyncAt;
TimeSpan _minInterval = TimeSpan.FromSeconds(60);

bool CanSync() => !_lastSyncAt.HasValue || DateTimeOffset.UtcNow - _lastSyncAt >= _minInterval;

async Task DoSyncAsync()
{
    if (!CanSync()) { MessageBox.Show("請稍後再試，避免過於頻繁。"); return; }
    var (offset, err) = await SyncOnceAsync(textUrl.Text);
    _lastSyncAt = DateTimeOffset.UtcNow;
    StartDisplay(offset);
}

## Case #13: 非同步 async/await 防止 UI 卡頓

### Problem Statement（問題陳述）
業務場景：對時時會發網路請求，若使用同步呼叫，UI 將卡死，影響操作與體驗，特別是在搶票前。
技術挑戰：以非同步執行對時並在完成後安全更新 UI。
影響範圍：UI 無回應、使用者誤操作、體驗差。
複雜度評級：低

### Root Cause Analysis（根因分析）
直接原因：
1. 網路 IO 阻塞 UI 執行緒。
2. 非同步回來後更新 UI 的執行緒上下文問題。
3. 缺少例外處理使 UI 更脆弱。
深層原因：
- 架構層面：未區分 UI 與 IO 工作。
- 技術層面：未用 async/await。
- 流程層面：缺少忙碌指示器。

### Solution Design（解決方案設計）
解決策略：在按鈕事件用 async void，await SendAsync，完成後回 UI 執行緒更新；提供 Loading 指示，並捕捉例外。

實施步驟：
1. 非同步呼叫
- 實作細節：await HttpClient.SendAsync
- 所需資源：C#
- 預估時間：0.2 小時

2. UI 更新
- 實作細節：await 自動回 UI 同步內容（WinForms）
- 所需資源：UI C#
- 預估時間：0.2 小時

3. 忙碌指示與錯誤提示
- 實作細節：Disable 按鈕、顯示 Spinner
- 所需資源：UI
- 預估時間：0.3 小時

關鍵程式碼/設定：
```csharp
private async void btnSync_Click(object sender, EventArgs e)
{
    try
    {
        btnSync.Enabled = false;
        var (offset, err) = await SyncOnceAsync(textUrl.Text);
        StartDisplay(offset);
        UpdateIndicators(offset, err);
    }
    catch (Exception ex)
    {
        MessageBox.Show("對時失敗：" + ex.Message);
    }
    finally
    {
        btnSync.Enabled = true;
    }
}

## Case #14: 網路不穩的例外處理與逾時設定

### Problem Statement（問題陳述）
業務場景：搶票高峰網路擁塞，請求可能逾時或失敗；需要合理逾時與錯誤提示，避免在關鍵時刻卡住。
技術挑戰：設定適當逾時、捕捉例外並提供可行建議。
影響範圍：對時失敗、浪費操作時間。
複雜度評級：低

### Root Cause Analysis（根因分析）
直接原因：
1. 預設逾時不適合高峰。
2. 未捕捉 Socket/HttpRequest 例外。
3. 無重試或回退。
深層原因：
- 架構層面：容錯缺失。
- 技術層面：不熟悉逾時/取消。
- 流程層面：無操作指引。

### Solution Design（解決方案設計）
解決策略：設置較短逾時（如 3s），捕捉各類例外，提供重試/回退建議；高峰時可延長或自適應。

實施步驟：
1. 逾時設定
- 實作細節：HttpClient.Timeout = TimeSpan.FromSeconds(3)
- 所需資源：HttpClient
- 預估時間：0.2 小時

2. 例外處理
- 實作細節：try-catch，區分逾時/解析錯誤/狀態碼
- 所需資源：C#
- 預估時間：0.3 小時

3. 用戶提示
- 實作細節：建議換路徑/稍後重試
- 所需資源：UI
- 預估時間：0.3 小時

關鍵程式碼/設定：
```csharp
using var client = new HttpClient { BaseAddress = baseUri, Timeout = TimeSpan.FromSeconds(3) };
try
{
    var (offset, err) = await SyncOnceAsync(baseUri.ToString());
    // ...
}
catch (TaskCanceledException)
{
    MessageBox.Show("連線逾時，請稍後再試或更換路徑。");
}
catch (HttpRequestException ex)
{
    MessageBox.Show("網路錯誤：" + ex.Message);
}
catch (Exception ex)
{
    MessageBox.Show("未知錯誤：" + ex.Message);
}

## Case #15: 跨系統時間不一致造成查詢錯誤（DB vs Web）之修復

### Problem Statement（問題陳述）
業務場景：應用程式與資料庫伺服器的系統時間差距大（小時級），導致時間條件查詢（如 createdate > getdate()）結果嚴重偏差，影響業務邏輯與報表。
技術挑戰：在運維未統一 NTP 的情況下，降低因時間不一致造成的邏輯錯誤。
影響範圍：查詢錯誤、資料不一致、決策失準。
複雜度評級：高

### Root Cause Analysis（根因分析）
直接原因：
1. Web 與 DB 各自時鐘漂移。
2. 業務邏輯混用不同來源時間。
3. 使用者端或應用端時間寫入到 DB。
深層原因：
- 架構層面：時間來源未統一（未強制 NTP/UTC）
- 技術層面：SQL 中使用 getdate() 與應用時間混雜
- 流程層面：缺乏時間治理規範

### Solution Design（解決方案設計）
解決策略：統一「權威時間源」為 DB 端（或 UTC），所有寫入以 DB 生成時間，查詢以 DB 時間函式（GETUTCDATE/SYSDATETIMEOFFSET）為準；儲存 UTC，顯示時轉本地。

實施步驟：
1. 寫入改用 DB 時間
- 實作細節：INSERT/UPDATE 時由 DB 端產生
- 所需資源：SQL/ORM
- 預估時間：1–2 小時

2. 查詢以 DB 時間為基準
- 實作細節：WHERE CreatedAt > GETUTCDATE()
- 所需資源：SQL 改造
- 預估時間：1 小時

3. 資料規範
- 實作細節：欄位用 datetimeoffset/UTC
- 所需資源：DB schema
- 預估時間：2–4 小時

關鍵程式碼/設定：
```sql
-- 儲存 UTC 時間
ALTER TABLE Orders ADD CreatedAtUtc datetime2 NOT NULL 
    CONSTRAINT DF_Orders_CreatedAtUtc DEFAULT (SYSUTCDATETIME());

-- 以 DB 時間為準的查詢
SELECT * FROM Orders WHERE CreatedAtUtc > SYSUTCDATETIME();

-- 寫入一律不由應用提供時間
INSERT INTO Orders(UserId, Amount) VALUES (@uid, @amt); -- CreatedAtUtc 走 DEFAULT