"Lifecycle"
- SDK 公開 API 設計
init / event / error / metric / flush / close 六個方法構成 SDK 的完整生命週期 — 跨平台共用相同 API 介面
- 四類事件的完整定義
Event / Error / Metric / Lifecycle 四類事件各自的語意、觸發時機和典型用途 — 分類是監控體系的統一語言
- Flutter 平台適配
Isolate 安全、Platform channel 攔截、app lifecycle 事件 — Flutter SDK 的平台特殊考量
- 5.6 Platform Lifecycle Contract
說明 runtime、startup、readiness、liveness、shutdown 與 drain 如何組成平台生命週期合約。
- 感測器生命週期管理
產品生命週期的五個階段各啟用什麼感測器 — feature flag 整合、取樣率動態調整、感測器開關的可觀察性
- Hands-on：LLM 運行中 + 結束的資源管理
RAM / 磁碟 / port 三個 dimension 的觀察跟釋放、Ollama keep_alive 跟 ComfyUI 兩種 lifecycle 對比、實測釋放數字
- Startup Probe
保護慢啟動服務不被 liveness probe 過早重啟的探針
- 7.B5 Detection Engineering Lifecycle
把偵測規則視為可維護資產，建立從來源、測試、調校到退場的完整生命週期
- 手寫 dispose() 沒有呼叫者 — Notifier 的依賴與清理都歸 build() 管
Notifier 用建構子注入依賴、或手寫 dispose() 釋放 Timer 與訂閱時使用。Notifier 的建構與銷毀都由容器管理——UI 不會呼叫 dispose()、掛在方法上的清理等於沒掛；依賴在 build() 內 ref.watch、清理在 ref.onDispose 註冊。
- await 回來的時候、頁面已經關了 — UnmountedRefException 與 16 個不抽象的檢查點
長 async 流程的每個 await 都是一個 gap：等待期間使用者可能離開、Notifier 被 dispose、回來再寫 state 就炸 UnmountedRefException。修法是每個 gap 後檢查 ref.mounted——而且刻意不抽成 helper：明確的檢查點讓 review 看得見哪個 gap 有守。含「評估必跑、可決定不重構」的技術債處置。
- 桌子跟購物車是兩個聚合 — 從「提前結帳」推導生命週期解耦
兩個業務資源該綁死成一對一、還是解耦成獨立生命週期加綁定關係——判準是有沒有業務操作需要其中一方獨立存活。以 POS 的提前結帳、純佔桌、外賣單推導桌位與購物車的聚合邊界，含組合空間大於業務空間時的非法組合封鎖。