🎯 什麼情境該想到我
當你「一筆業務交易橫跨多個請求，想在提交時才用版本號偵測有沒有人動過同一筆資料」的時候。
⚙️ 怎麼用（步驟 / 公式）
意圖：不預先鎖定，而是在提交時偵測是否發生衝突——若有人在期間內改過同一筆資料就擋下，讓使用者重做。
做法要點：
- 每筆記錄帶一個版本號（或時間戳）。
- 讀取時記下版本號；提交時用「WHERE version = 讀到的版本」更新，並讓版本號 +1。
- 若更新影響列數為 0，代表期間被別人改過 → 衝突，回滾並提示重試。
- 適合衝突機率低的情境，並發度高。
🧪 我實際套用的紀錄
- （待填）
⚠️ 注意 / 什麼時候不適用
- 衝突頻繁時，使用者常做白工再重來，體驗差。
- 衝突要到最後提交才發現（已投入的編輯可能全丟）。
- 高衝突情境改用悲觀離線鎖較合適。
🔗 相關工具
- 悲觀離線鎖 Pessimistic Offline Lock（相對方案：事先鎖定避免衝突）
- 粗粒度鎖 Coarse-Grained Lock（把一組相關物件當一個單位一起做版本控制）
- 隱含鎖 Implicit Lock（把版本檢查交給框架自動處理，避免漏做）
- 企業應用架構模式