<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Fail-Safe on Tarragon</title><link>https://tarrragon.github.io/blog/tags/fail-safe/</link><description>Recent content in Fail-Safe on Tarragon</description><generator>Hugo -- gohugo.io</generator><language>zh-TW</language><copyright>Tarragon (CC BY 4.0)</copyright><lastBuildDate>Fri, 17 Jul 2026 00:00:00 +0800</lastBuildDate><atom:link href="https://tarrragon.github.io/blog/tags/fail-safe/index.xml" rel="self" type="application/rss+xml"/><item><title>Fail-Safe Default（安全預設）</title><link>https://tarrragon.github.io/blog/ux-design/knowledge-cards/fail-safe-default/</link><pubDate>Fri, 17 Jul 2026 00:00:00 +0800</pubDate><guid>https://tarrragon.github.io/blog/ux-design/knowledge-cards/fail-safe-default/</guid><description>&lt;p>Fail-safe 預設的核心概念是「保護機制本身故障時，系統選擇倒向哪個方向」。確認對話框沒渲染、事件沒綁上、回應逾時 — 這些故障發生時系統仍要做一個決定：把故障當同意（執行）或當拒絕（不執行）。安全預設的原則是倒向不可逆性低的那邊：不清空可以重試、清空無法還原。這是 &lt;a href="https://tarrragon.github.io/blog/ux-design/knowledge-cards/gate/" data-link-title="Gate（UX）" data-link-desc="說明使用者操作流程中「必須通過才能繼續」的關卡，以及成功/失敗/不確定三條路徑的設計責任">Gate&lt;/a> 的第二層設計 — gate 攔使用者、fail-safe 管 gate 自己壞掉的情況。&lt;/p>
&lt;h2 id="概念位置">概念位置&lt;/h2>
&lt;p>Fail-safe 預設與 &lt;a href="https://tarrragon.github.io/blog/ux-design/knowledge-cards/ux-fallback/" data-link-title="Fallback（UX）" data-link-desc="說明 gate 未通過時使用者的替代路徑，和 backend fallback（server-side 降級）的語意區別">UX Fallback&lt;/a> 的分工：fallback 是給使用者的替代路徑（主路徑失敗後使用者往哪走）、fail-safe 是系統自己的預設方向（保護機制失效時系統做什麼）— 前者是使用者可見的路、後者是程式碼裡的 else 分支。安全領域的對應概念是 fail-open vs fail-closed：破壞性操作的確認機制要 fail-closed（故障即拒絕）。&lt;/p>
&lt;h2 id="可觀察訊號與例子">可觀察訊號與例子&lt;/h2>
&lt;p>需要檢查 fail-safe 的訊號是「保護邏輯存在、但它的故障分支沒人設計過」。實戰正面案例：匯入覆蓋模式的確認 Modal 在 DOM 缺失時一律視為未確認、預設不清空書庫（&lt;a href="https://tarrragon.github.io/blog/ux-design/cases/destructive-import-fail-safe-confirm/" data-link-title="U.C12 匯入空檔會清空書庫 — 破壞性操作的確認與安全預設" data-link-desc="設計會覆蓋 / 清空既有資料的操作時使用。破壞性操作 gate 有兩層：確認使用者意圖、加上確認機制本身故障時的安全預設 — 故障要倒向不可逆性低的那邊">U.C12&lt;/a>）。反向的檢查問句：確認元件不存在時、你的程式碼走哪個分支？&lt;/p>
&lt;h2 id="設計責任">設計責任&lt;/h2>
&lt;p>Fail-safe 的設計責任是為每個保護機制（確認對話框、權限檢查、二次驗證）顯式寫下故障分支的方向。程式碼層的掃描訊號：確認邏輯的 else / null / timeout 分支最終呼叫的是「執行」還是「中止」— 分支缺失或走向執行的，就是故障會靜默放行破壞的候選。&lt;/p></description><content:encoded><![CDATA[<p>Fail-safe 預設的核心概念是「保護機制本身故障時，系統選擇倒向哪個方向」。確認對話框沒渲染、事件沒綁上、回應逾時 — 這些故障發生時系統仍要做一個決定：把故障當同意（執行）或當拒絕（不執行）。安全預設的原則是倒向不可逆性低的那邊：不清空可以重試、清空無法還原。這是 <a href="/blog/ux-design/knowledge-cards/gate/" data-link-title="Gate（UX）" data-link-desc="說明使用者操作流程中「必須通過才能繼續」的關卡，以及成功/失敗/不確定三條路徑的設計責任">Gate</a> 的第二層設計 — gate 攔使用者、fail-safe 管 gate 自己壞掉的情況。</p>
<h2 id="概念位置">概念位置</h2>
<p>Fail-safe 預設與 <a href="/blog/ux-design/knowledge-cards/ux-fallback/" data-link-title="Fallback（UX）" data-link-desc="說明 gate 未通過時使用者的替代路徑，和 backend fallback（server-side 降級）的語意區別">UX Fallback</a> 的分工：fallback 是給使用者的替代路徑（主路徑失敗後使用者往哪走）、fail-safe 是系統自己的預設方向（保護機制失效時系統做什麼）— 前者是使用者可見的路、後者是程式碼裡的 else 分支。安全領域的對應概念是 fail-open vs fail-closed：破壞性操作的確認機制要 fail-closed（故障即拒絕）。</p>
<h2 id="可觀察訊號與例子">可觀察訊號與例子</h2>
<p>需要檢查 fail-safe 的訊號是「保護邏輯存在、但它的故障分支沒人設計過」。實戰正面案例：匯入覆蓋模式的確認 Modal 在 DOM 缺失時一律視為未確認、預設不清空書庫（<a href="/blog/ux-design/cases/destructive-import-fail-safe-confirm/" data-link-title="U.C12 匯入空檔會清空書庫 — 破壞性操作的確認與安全預設" data-link-desc="設計會覆蓋 / 清空既有資料的操作時使用。破壞性操作 gate 有兩層：確認使用者意圖、加上確認機制本身故障時的安全預設 — 故障要倒向不可逆性低的那邊">U.C12</a>）。反向的檢查問句：確認元件不存在時、你的程式碼走哪個分支？</p>
<h2 id="設計責任">設計責任</h2>
<p>Fail-safe 的設計責任是為每個保護機制（確認對話框、權限檢查、二次驗證）顯式寫下故障分支的方向。程式碼層的掃描訊號：確認邏輯的 else / null / timeout 分支最終呼叫的是「執行」還是「中止」— 分支缺失或走向執行的，就是故障會靜默放行破壞的候選。</p>
]]></content:encoded></item></channel></rss>