主策略 + 補強策略：選擇不必互斥

2026-04-26

結論

多策略選擇（如 #59 五策略、#73 五匹配模式）預設不是單選。能疊加的策略應該疊加、互斥的才需要選。

最常見的疊加：root-cause 結構性修法 + 使用者感知補強（例如 multi-index 解層錯位 + UX hint 解 prefix-match 預期落差）— 解不同層、互不干擾、合在一起的覆蓋面 > 單選任一。

呈現多選項時容易進「適配性比較表 → 選最高分」的單選思維。這個思維對「互斥工具選擇」（Vue / React、Postgres / MySQL）成立、對「補強型策略」不成立：

兩者解的問題層不同：根因解了、使用者立刻感受到的混亂仍在；UX 蓋過去了、根因仍在累積技術債。預設單選 = 強迫使用者在「立即解使用者痛苦」與「長期解結構問題」之間二選一、其實兩個都該做。

某兩個策略 X + Y 可疊加 ⇔ 滿足以下全部：

X 動結構 / 資料 / 演算法、Y 動 UI / 訊息 / 預期管理。同層的兩個策略通常衝突（兩種 cache 策略、兩種 routing 策略），不同層的多半互補。

判讀：把問題分成「根因 / 訊號 / 補償」三層、每層挑 1 個策略 = 疊加組合。

X 加上 Y 不會放大彼此副作用、不會產生新 bug。例：multi-index（佔 build time）+ UX hint（佔畫面空間）— 兩個 cost 維度不同、不互相放大。

反例：fetch-until-quota（多次 round trip）+ aggressive prefetch（更多 round trip）— 同維度副作用會疊加、可能爆炸。

第二個策略的實作 + 維護成本 ≤ 它解的問題價值。如果 X 已經解掉 80% 問題、Y 解剩下 20% 但成本是 X 的兩倍 → Y 就是過度工程、不該疊加。

Structural 解根因、UX 解使用者當下混亂。即使 structural 還沒 ship、UX patch 可以先 ship 解眼前問題。

Defensive 處理失敗、Optimistic 處理成功 — 兩個 happy path 共存、不衝突。

「先 ship X 解眼前、Y 下輪做」是一種隱式疊加 — 不是放棄 Y、是延後到風險更可承受的 release window。判準見 #76 分批 ship。

#46 / #47 / #48 / #49 四張 selector 起點 pattern 卡乍看互斥（每個元件只能選一個起點）、實際在同一個 handler 內可疊加：

同一份 component code 可同時用 #46 + #49（外部 portal 用 document、內部用 closest）— 解不同 selector context、不衝突、增量成本低 = 滿足三條判準。

判讀：「這幾個 pattern 是同層次（互斥）還是不同 context（互補）？」不同 context = 疊加。

情境	為什麼
真正互斥（同 slot 只能放一個）	例：UI framework、DB engine、protocol — 選了就排他
維護成本不可接受	兩條 path 並存的 cognitive load > 收益
一致性比覆蓋面重要	例：UI 設計語言、API 慣例 — 多選會稀釋
探索期、還沒驗證	多選 = 多戰線、超過驗證能力

四類共通：疊加的代價 > 疊加的收益。其他情境都該先檢查「能不能疊加」。

核心：策略選擇問「能不能疊加」優先於「選哪個」 — 多數工程問題的最佳解是「多層次組合」、不是「找出唯一答案」。