核心原則

「最小必要範圍」是 sanity 防線、不是優化選項。 縮 selector / observer / DOM 操作的範圍、目的不是為了讓程式跑更快、是為了讓行為可預測：不誤命中、不過度觸發、不被未來頁面結構變動打破。從具體放寬比從寬泛收緊容易得多 — 兩者的成本曲線完全不對稱。

為什麼是「sanity 防線」、不是「優化」

兩個概念常被混為一談

「縮範圍」聽起來像效能優化（少做一點工 = 快一點）— 這誤解掩蓋了它真正的價值。

把「縮範圍」當優化的後果：以為「現在沒效能問題、之後再縮」 — 但 sanity 防線錯過了第一行就追求的時機、未來補救成本更高。

寬範圍的代價不是「慢」

寬 selector / observer / 操作範圍的失敗模式：

四種代價都不是「慢」 — 都是「行為不可預測」。Sanity 防線守的是這個。

「從具體放寬」vs「從寬泛收緊」的不對稱性

兩個方向在表面上對稱、實際成本曲線完全不對稱：

從具體放寬（推薦）

1寫第一版：用最具體的 selector / 最小的 observer 範圍 / 最窄的操作邊界
2↓
3發現某個 case 沒覆蓋
4↓
5顯式評估「該放寬到什麼程度」
6↓
7擴大範圍、知道擴大後的影響範圍

每次擴大都是顯式決定 — 知道「我為什麼擴大、擴大到哪」。

從寬泛收緊（反推薦）

1寫第一版：用最寬的 selector / subtree observer / 全頁面操作
2↓
3某天發現某個 bug（誤命中、過度觸發、framework 衝突）
4↓
5不確定哪些地方是「故意要寬」、哪些是「意外寬了」
6↓
7試著縮、可能漏掉某些故意要寬的場景、引發新 bug

收緊時面對的問題：寬範圍的程式碼裡看不出「哪些是故意寬、哪些是意外寬」。原作者也不一定記得當初為什麼寫寬。

不對稱性的根源

這個不對稱不是工程偏好、是資訊量的差異：

• 從具體放寬：每次擴大時、有當前需求當證據（「為了 X case 才擴大」）
• 從寬泛收緊：縮的時候、不知道原本依賴哪些寬範圍特性

寫程式時的「具體 → 寬泛」走法保留了決策軌跡；「寬泛 → 具體」走法丟失了軌跡。

三類範圍的共同骨架

「最小必要範圍」原則跨三類獨立議題：

三者表現不同、機制不同、但底層都是同一條原則的應用 — 越寬越脆弱、越具體越穩定。

共通的設計工具

跨三類議題、設計「最小必要範圍」的工具有共通模式：

每個議題都有「起點 / 深度 / 過濾」三維度可顯式設計 — 同樣的設計骨架在不同情境重現。

應用辨識訊號

下次工作中、看到這些訊號該想到「最小必要範圍」：

不該套用「最小必要範圍」的情境

這條原則有適用邊界、不是所有「縮」都有意義：

核心判準：「最小必要範圍 = 滿足當前需求的最窄範圍」 — 不是極致最小、是「不再小就會漏」的點。盲目縮到「比需要還小」會犧牲覆蓋率、是另一種錯誤。

跟「2 次門檻」的協同

#42 2 次門檻 處理「失敗第 N 次該換策略」、本原則處理「第一次設計時範圍該多大」。兩者方向互補：

• 2 次門檻：失敗發生後、何時該升級處理層級
• 最小必要範圍：寫第一版時、就該追求 sanity 防線

如果第一版就遵循「最小必要範圍」、後續觸發 2 次門檻的機率會降低 — sanity 防線是預防、2 次門檻是補救。

對應的實作篇

每篇示範這個原則在不同議題的應用：

讀的時候從本篇出發、依議題挑實作篇。

判讀徵兆

核心原則：最小必要範圍守護的是「行為可預測」 — 寫的時候多想一點、debug 時少痛一點。寬範圍的代價不是慢、是出錯時定位困難 — 這也是為什麼這條原則在「沒效能瓶頸」的情境下仍然成立。

延伸到 stream 操作：#64 Feature 操作要跟 Source 同層合成 是本原則在 stream 領域的應用 — 「合成位置」就是「操作的範圍邊界」、選錯位置 = 範圍錯。寬範圍便利、窄範圍對齊、兩者反相關的更高層原則見 #67 寫作便利度跟意圖對齊反相關。