題幹與適用場景
團隊升級至 Python 3.14，想把日誌、HTML 郵件與查詢構造中的 f-string 串接改成 t-string。請說明 t-string 的執行結果、如何處理插值、哪些場景不能直接套用，以及如何漸進發布。
面試官考察點
考察你是否理解 t-string 是結構化模板，不是自動轉義器；能否區分展示層編碼、SQL 參數化與日誌欄位化；能否設計版本相容、靜態檢查、基準與回滾。
回答前需要釐清的問題
先確認目標輸出是 HTML、日誌還是 SQL，因為每種上下文的編碼邊界不同。再確認最低 Python 版本、依賴是否能解析新語法，以及團隊是否需要保留可在執行期組合的模板物件。最後定義安全門檻：注入測試、日誌敏感欄位、延遲與錯誤率。
30 秒回答
「t-string 在求值時產生 Template，保留靜態片段與 Interpolation，便於先檢查結構再渲染。它不會替應用場景完成 HTML 轉義或 SQL 參數化，所以我會讓渲染器依上下文編碼，資料庫繼續使用參數綁定。先在獨立模組用 3.14 執行，加入型別、注入與相容性測試，影子流量驗證後小比例發布，並保留 f-string 或舊渲染器回滾。」
分步驟深入解答
先確認語意與版本
t-string 使用 t 前綴，語法類似 f-string，但結果是 Template；插值表達式已求值，靜態文字與插值物件仍可檢查。執行環境與工具鏈必須支援 Python 3.14 與 PEP 750。
將模板與渲染分層
模板只描述結構，渲染函式負責目標上下文。HTML 使用成熟轉義器，SQL 使用驅動參數，不能把 Template 直接串成 SQL；日誌優先輸出結構化欄位。
設計插值策略
限制插值表達式只讀取無副作用值，避免在模板執行網路呼叫或改變狀態。對每個 Interpolation 記錄名稱、轉換標記與格式說明，拒絕未知欄位或危險型別。
處理相容性
舊直譯器無法解析 t 前綴，不能只靠執行期分支。將 t-string 程式碼隔離在 3.14 套件或服務，CI 同時跑語法檢查與依賴矩陣；跨版本函式庫可在邊界傳遞普通資料結構。
驗證安全與效能
覆蓋 HTML 屬性、腳本、日誌換行與 SQL 注入樣本，確認編碼發生在最後一步。比較 f-string、模板渲染器與參數化查詢的 p95 延遲、配置次數與錯誤率。
漸進發布與回滾
先離線快照比對，再影子流量，最後 1% 至 10% 金絲雀。保留舊路徑開關，監控模板解析錯誤、敏感欄位洩漏與輸出差異；任一門檻失敗立即回退。
高品質示範回答
我會把 t-string 視為可檢查的模板中間表示，而非安全渲染器。先確認 Python 3.14 與工具鏈覆蓋，再限制插值為無副作用值；HTML、日誌、SQL 各自使用對應的轉義、欄位化與參數綁定。透過注入與快照測試建立基線，影子流量和小比例發布驗證效能及錯誤率，保留舊渲染器作為回滾路徑。
常見錯誤
以為 t-string 自動防注入
Template 只保留結構，不知道目標上下文；必須在 HTML、SQL、日誌邊界使用專用安全機制。
把 Template 直接轉成 SQL
這仍可能把值當成程式碼；應使用驅動參數綁定並單獨傳遞參數。
在插值表達式執行副作用
模板渲染可能重複發生，副作用會造成難測的順序問題；先計算資料再渲染。
忽略舊直譯器
3.13 及更早版本不能解析語法；隔離 3.14 模組或服務並設定 CI 矩陣。
追問及應對
t-string 與 f-string 的核心差異？
f-string 直接產生字串；t-string 產生包含靜態片段與插值紀錄的 Template，可後續檢查與客製渲染。
能否用它取代 SQL 查詢構造？
不能。查詢值繼續參數化，識別符使用白名單映射；t-string 只可協助組織展示模板。
如何防止敏感資料進入日誌？
渲染前按欄位名與型別做策略檢查，拒絕密碼、令牌等欄位，並對輸出做脫敏測試。
如何支援 3.13 客戶端？
將 t-string 邏輯放在獨立服務，透過 JSON 資料傳遞結果；舊客戶端不解析新語法。