探索者

探索主題

Agent: 探索者 (explorer)
Confidence: 73%
Cost: $0.3957
Duration: 1m 32s
Task ID: 25cba893-748b-4c58-8364-5978162c0498

現在我有足夠的資訊了。讓我彙整探索報告。

探索主題

grammY Bot 框架的中介軟體設計模式

發現

  1. 我們的中介軟體層很扁平 — 目前 src/telegram/middleware/index.ts 只是 4 個 bot.use() 的線性堆疊，沒有使用 Composer 分組、errorBoundary 隔離、或 filter 條件路由。這是最基本的用法，缺乏結構化。

  2. Composer 是組織利器 — grammY 的 Composer 可以把相關中介軟體打包成獨立模組（如 adminComposer、chatComposer），各自有自己的 errorBoundary，互不干擾。我們目前的 errorHandlerMiddleware 是全局 try-catch，但用 bot.errorBoundary() 可以實現更細粒度的錯誤隔離。

  3. rate-limit 有狀態洩漏風險 — dailyCounts 用模組級 Map 存狀態，既無法測試（沒有 reset 機制），重啟也會遺失。grammY 的 session plugin 或注入式設計更適合。

  4. 可測試性幾乎為零 — 4 個中介軟體都直接 import config、logger 等全域依賴，無法在單元測試中替換。grammY 官方建議的 plugin 模式是用工廠函數（如 onlyAccept(str)）回傳 middleware，參數化後天然可測試。

  5. filter + use 鏈式可實現條件路由 — composer.filter(predicate).use(handler) 可以替代手動 if/else 判斷，讓中介軟體意圖更清晰。

有趣的連結

  • grammY 的 Composer 本身就是中介軟體——可遞迴組合，這和 React 的 component composition 思路一致
  • bot.errorBoundary() 類似 React 的 ErrorBoundary，可以包裹任意子樹做隔離
  • Lazy session 的 deferred loading 模式與我們專案的 Result<T> 模式有異曲同工之妙——都是延遲副作用

延伸問題

  • 如何用 Composer + 依賴注入重構我們的中介軟體層，使每個中介軟體可獨立單測？
  • 是否該為不同使用者群組（admin / 一般用戶 / 頻道）建立獨立的 Composer 子樹配上各自的 errorBoundary？

重要性：4/5

★ Insight ─────────────────────────────────────
具體改善方向：將 setupMiddleware 重構為 Composer-based 架構，每個功能區（auth、rate-limit、command routing）各自是一個 Composer，用 errorBoundary 隔離。中介軟體工廠函數接受依賴作為參數（如 createRateLimiter({ limit, store })），既可測試又可替換存儲後端。這不是理論——我們的 4 個中介軟體都能立即套用這個模式。
─────────────────────────────────────────────────