題幹與適用場景
Go 1.25 新增 runtime/trace.FlightRecorder，持續把最近的執行追蹤視窗保存在記憶體中，並在偵測到問題時產生快照。它適合長期執行服務中的罕見事件，因為等症狀出現後才開始完整追蹤通常已經太晚。
假設服務有延遲觸發器、有界診斷預算和用於保存追蹤檔案的物件儲存。設計必須避免無界記憶體、重複快照、敏感資料洩漏和緩慢的事故路徑。
面試官考察點
面試官關注正確的生命週期：建立記錄器、啟動一次、觸發有界 WriteTo，並在關閉時停止。強回答會討論單記錄器限制、單寫入快照、年齡與大小設定、取樣、去識別和背壓。
普通回答只說「延遲升高就開啟追蹤」。強回答會說明滾動視窗為何必須提前運行，以及如何防止觸發器製造快照風暴。
回答前需要釐清的問題
- 什麼延遲或錯誤訊號觸發快照？訊號有多嘈雜？
- 同時可能有多少執行個體觸發？是否有全域捕捉預算？
- 什麼視窗年齡和位元組大小符合記憶體與事故延遲預算？
- 追蹤檔案是否含請求資料、憑證或租戶識別？
- 快照在哪裡上傳、保留、加密和審計存取？
如果訊號很嘈雜，應先加入取樣和冷卻。如果無法保護追蹤內容，應限制記錄器範圍或採用更安全的診斷訊號。
30 秒回答框架
「我會為每個程序運行一個有界配置的 FlightRecorder，只在取樣並去抖後的 SLO 違規時觸發快照。WriteTo 由單一寫入器串行執行，請求路徑只入隊並快速返回。我會對檔案去識別或加密，限制全域捕捉量，監控記錄器錯誤和上傳延遲，並在關閉時安全停止。」
分步驟深入解答
- 建立並啟動一次。 用有界視窗建構
FlightRecorderConfig，呼叫Start，把啟動失敗作為指標暴露。 - 選擇視窗。 根據診斷間隔和記憶體預算選擇最小年齡和緩衝大小。視窗越大，上下文越多，但記憶體和上傳成本也越高。
- 設計觸發器。 使用延遲、錯誤或健康訊號，加入取樣、冷卻、程序配額和全域配額，不能讓每個請求都呼叫
WriteTo。 - 串行快照。
WriteTo只允許一個並發寫入器。使用有界通道排隊，合併或丟棄重複任務，保持熱路徑非阻塞。 - 保護資料。 把追蹤視為敏感運維資料，傳輸和儲存加密，限制保留和存取，事件元資料不能複製原始載荷到日誌。
- 安全營運。 記錄成功率、位元組數、耗時、丟棄觸發、上傳失敗和記錄器狀態。優雅關閉時停止，並確認進行中的寫入完成。
替代方案包括受控測試的開始/停止追蹤、回答 CPU 或堆問題的 profile，以及補充業務上下文的結構化日誌。症狀罕見且證據發生在偵測前時，flight recorder 最有價值。
高品質示範回答
「我會為每個程序啟動一個五秒有界視窗，並根據記憶體限制確定大小。取樣後的 p99 違規每個執行個體每分鐘最多入隊一次，全域配額防止事故填滿物件儲存。工作執行緒串行呼叫 WriteTo，加密追蹤並非同步上傳；請求路徑只記錄已請求捕捉。我會暴露捕捉錯誤、丟棄觸發、上傳延遲和位元組數，並優雅停止記錄器，確保並行寫入完成。」
常見錯誤
- 錯誤表現： 告警後才啟動追蹤 → 失敗原因： 觸發前證據已遺失 → 修正方法： 持續運行有界滾動視窗。
- 錯誤表現： 每個請求都產生快照 → 失敗原因： 並發寫入和儲存風暴會壓垮服務 → 修正方法： 取樣、去抖並使用單寫入器。
- 錯誤表現： 忽略追蹤敏感性 → 失敗原因： 運維證據可能暴露租戶資料 → 修正方法： 加密、限制、去識別並短期保留。
- 錯誤表現： 假設
Start或WriteTo不會失敗 → 失敗原因： 事故中捕捉會靜默消失 → 修正方法： 暴露明確指標和降級行為。
追問及應對
兩個 goroutine 同時呼叫 WriteTo 怎麼辦？
透過單一捕捉工作執行緒串行化。並發寫入時 API 會返回錯誤，應合併觸發而不是緊密重試。
如何選擇緩衝區大小？
從根因到偵測的時間間隔開始，限制每程序和全域記憶體，再用代表性追蹤量驗證遺失上下文是否可接受。
快照會阻塞請求路徑嗎？
不要同步寫入慢速網路目的地。排隊有界任務，把快照寫入受控緩衝或檔案，再帶逾時非同步上傳並定義丟棄策略。
關閉期間怎麼處理？
停止接受新捕捉，呼叫 Stop，等待進行中的寫入完成，再關閉上傳路徑，並記錄最終快照是完成還是有意丟棄。