觀察

電子書庫總覽 Chrome 擴充功能（book_overview_v1）的匯入功能出錯時（檔案格式錯誤、內容不合法），錯誤顯示複用了 popup 的通用 errorContainer — 這個容器是為擴充功能執行層錯誤設計的，帶「重新載入擴充功能」按鈕。使用者回饋指出：Chrome Web Store 上架版對「匯入錯誤」不該出現 reload extension 按鈕（commit 72cd5f370）。

修復：建匯入專屬的 importErrorContainer，只有「關閉」按鈕（沒有 retry / reload）— 匯入錯誤的正確下一步是換一個檔案再試，不是重載執行環境；同時把文案集中到 IMPORT_MESSAGES 常數、移除對通用錯誤處理器的依賴。

判讀

1. 錯誤有層級、行動也有層級。檔案格式錯誤是資料層、訊息通道斷線是通訊層、service worker 崩潰是執行環境層。行動同樣分層：換檔案重試（資料層）、重新連線（通訊層）、重載擴充功能（執行環境層）。對位原則：行動解決的層級 = 錯誤發生的層級。層級過重的行動不解決問題（重載擴充功能不會讓壞檔案變好）、還附帶代價（狀態遺失、流程中斷）。

2. 通用錯誤容器是不對位的結構性來源。為最嚴重錯誤設計的容器（帶最重的行動）被所有錯誤複用時，輕錯誤自動繼承重行動。錯誤 UI 的複用要以「行動相容」為邊界、不是以「都是錯誤」為邊界。

3. 使用者會照著按鈕走。錯誤畫面上的按鈕是系統給的行動建議，使用者傾向直接採納 — 不對位的按鈕等於系統主動引導使用者做無效且有代價的操作。

策略

1. 對每個錯誤 UI 的行動清單問一句：這個行動解決的層級，等於這個錯誤發生的層級嗎？過重（重載 / 重啟 / 重裝出現在資料層錯誤）與過輕（執行環境崩潰只給「關閉」）都是缺口。

2. 錯誤容器按行動分組：行動集合不同的錯誤用不同容器 / 元件，避免複用時行動一起被繼承。

3. 文案與行動集中管理：錯誤訊息散在 HTML 各處時，行動不對位很難被掃描發現；集中成常數表後「哪類錯誤配哪些行動」一眼可查。

下一步路由

• 錯誤訊息的診斷與行動職責 → 錯誤訊息撰寫原則
• 重試行動的設計 → Retry 機制 UX
• 對照案例（行動缺失 — 只有重試沒有退路）→ U.C1 五個狀態零個退出路徑