遊戲存檔的原子性：為什麼停電不會讓存檔壞掉
把這個概念搬到遊戲存檔上，理想狀態是這樣的：玩家按下存檔後，磁碟上只會存在兩種結果——「舊的存檔」或「新的存檔」。絕對不會出現第三種「兩個混在一起」或「只有一半」的狀態。只要能做到這一點，理論上不論何時斷電，玩家最差也只是損失這次的進度，而不會連舊存檔都一起賠進去。
要達成這件事，核心手法其實只有一個：不要直接覆蓋原本的檔案。先寫到一個暫存位置，確認寫完、確認資料真的落地了，再用一個「不可分割的動作」把新檔案換上去。這個「換上去」的動作，就是原子性的關鍵所在。在 POSIX 系統中，這個動作叫做 rename()；在 Windows 上則是 MoveFileEx() 搭配 MOVEFILE_REPLACE_EXISTING，或是更高階的 ReplaceFile()。這些系統呼叫的特殊之處在於，它們在檔案系統層面被保證為原子操作：要嘛你看到舊檔，要嘛你看到新檔，中間沒有過渡狀態。
為什麼「寫到一半」是最可怕的狀態
很多玩家有個誤解，以為壞檔是「檔案消失」。實際上更常見、也更棘手的情況是檔案看起來好好的，大小也對，遊戲卻在載入時崩潰或跳出「存檔已損毀」。這是因為遊戲在讀取時會做結構驗證，例如檢查標頭（magic number）、版本號、資料長度、校驗碼。一旦發現內容不符合預期，就判定存檔無效。
而「寫到一半」正是最容易產出這種半成品檔案的路徑。假設遊戲採用最天真的作法——直接把新資料覆蓋到舊檔案的位置——那麼在寫入過程中斷電，你就會得到一個「前半段是新資料、後半段是舊資料」的縫合怪。這種檔案的長度可能剛好正確，甚至連標頭都正確，但內部的索引指標會全部錯位，讀取時直接爆炸。更糟的是，舊存檔也被這波覆蓋破壞了，等於一次事故毀掉兩個進度。
這就是為什麼原子寫入的價值如此巨大：它把「可能產生無限多種壞檔」的風險，壓縮成「只有兩種結果」的確定性。
三、遊戲引擎與主機平台怎麼做到原子存檔
理解了原理之後，我們來看看實務上遊戲開發者怎麼做。不同的引擎、不同的平台，策略略有差異，但大方向高度一致：備份、暫存、驗證、替換。
策略一：雙緩衝與備份檔機制
最常見也最直觀的做法，是同時維護兩份以上的存檔槽。流程大約是：遊戲先把新進度寫入 save.tmp，寫完後強制刷新，接著把現有的 save.dat 改名為 save.bak，最後把 save.tmp 改名為 save.dat。這樣一來，即使在某個中間步驟斷電，你至少還會擁有一個可用的檔案——可能是舊的 save.bak，也可能是新的 save.dat。
這個機制最大的優點是實作簡單、跨平台容易，而且對玩家友善：即使真的出事，還有備份可以救。缺點是它並非嚴格意義上的「單一原子操作」，因為中間涉及多次改名，仍然存在極小的風險窗口。不過對絕大多數單機遊戲來說，這個等級的保護已經綽綽有餘。
不少日系 RPG 與獨立遊戲就採用這種「輪替式存檔槽」設計，玩家會看到存檔列表一次出現十幾個檔案，其實背後就是這個邏輯的延伸。輪替的槽位越多，救援的成功率越高。
策略二：日誌式寫入（Write-Ahead Logging）
另一種更嚴謹的做法借鏡了資料庫的預寫日誌。概念是：在真正修改主存檔之前，先把「我打算做什麼」寫進一份日誌檔，並且確保日誌已經完整落盤。等主存檔修改完成後，再把日誌標記為已完成。如果過程中斷電，下次啟動時遊戲會讀取日誌，判斷上次的操作是否完成：若未完成，就依照日誌內容「重做（redo）」或「復原（undo）」。
這種做法的好處是能夠處理更複雜的存檔結構，例如開放世界遊戲常常需要一次更新多個區塊的狀態。寫入日誌的代價則是效能開銷與實作複雜度，因此多半出現在大型專案或需要頻繁自動存檔的遊戲中。
策略三：複製即寫入與檔案系統快照
在較新的平台上，開發者還可以直接倚賴檔案系統的能力。複製即寫入（Copy-on-Write，CoW）檔案系統如 ZFS、Btrfs、APFS 在修改資料時，並不會就地覆蓋舊區塊，而是把新資料寫到全新的區塊，最後再原子性地更新指標。這使得「建立一個存檔快照」變成幾乎零成本的動作。
對於支援這種機制的平台，遊戲可以每次存檔都建立一個快照，玩家甚至能回溯到任何一個歷史時間點。這在傳統檔案系統上是難以想像的奢侈。不過要注意，CoW 保證的是檔案系統層級的一致性，遊戲本身的資料結構若寫得不夠嚴謹，仍可能在邏輯上產生矛盾狀態，所以開發者依然需要做好校驗與版本管理。
策略四：校驗碼與雜湊驗證
原子性解決了「寫到一半」的問題，但無法防止「寫完了但內容錯了」。因此成熟的存檔格式幾乎都會附帶校驗碼（checksum），例如 CRC32、Adler-32，或是更強韌的 MD5、SHA-256。遊戲在載入時會重新計算一次，與存檔中記錄的值比對，不一致就判定為損毀。
校驗碼的價值不只是防斷電，也能防記憶卡壞軌、雲端同步錯亂、甚至防玩家手動修改數值。有些遊戲還會對存檔做簽章或加密，進一步提高竄改門檻。對玩家而言，看到「存檔驗證失敗」的訊息雖然沮喪，但至少你知道問題出在哪，不會傻傻地載入一個會讓遊戲崩潰的檔案。
四、硬體與檔案系統層的保命設計
遊戲引擎做得再好，如果腳下的地基不穩，一切仍是空中樓閣。所幸現代作業系統與儲存裝置在這方面下了非常多功夫。
磁碟快取與 FUA、Flush 指令
前面提過，硬碟與 SSD 都有自己的寫入快取。這對效能是好事，對資料安全卻是潛在威脅。為此，儲存介面提供了幾種控制手段：Flush Cache 指令要求裝置把所有暫存資料寫進媒體；FUA（Force Unit Access） 則是在單次寫入指令中直接標明「這筆資料必須立刻落地，不准快取」。
作業系統在處理 fsync() 時，背後就是送出這些指令。值得注意的是，部分廉價的 USB 隨身碟與外接硬碟會忽略或謊報這些指令——它們回報「已完成」，實際上資料還在 DRAM 裡。這種裝置在停電時幾乎必死。這也是為什麼存檔放在內接硬碟或 SSD 上，通常比放在便宜隨身碟上安全得多。
日誌式檔案系統的 journal
現代主流的檔案系統——Linux 的 ext4、XFS，Windows 的 NTFS，macOS 的 APFS——幾乎都是日誌式（journaling）或有類似機制。它們在變更中繼資料之前，會先把意圖寫進日誌區。若中途斷電，下次掛載時系統可以重播日誌，把檔案系統修復到一致的狀態。
但這裡有個非常重要的細節：日誌保護的是檔案系統結構，不是你的檔案內容。也就是說，日誌能確保「不會出現指向不存在區塊的檔案」這種災難，但它不保證「檔案裡的每個位元組都是最新的」。以 ext4 的預設模式 data=ordered 為例，它保證資料區塊會在中繼資料提交前先寫出，這大幅降低了「檔案大小正確但內容為零」的機率，但嚴格來說仍不是完整的使用者資料日誌。若要達到最高保證，得使用 data=journal 模式，代價是效能明顯下降。
至於 NTFS，它的日誌同樣只管中繼資料。歷史上有段時期，Windows 的延遲寫入機制在斷電後確實容易產生「大小正確、內容全零」的檔案，這也是老玩家「停電必壞檔」印象的重要來源之一。近年的版本在這方面已改善不少，但開發者若沒有正確呼叫刷新指令，風險依然存在。
SSD 的斷電保護與消費級的現實
你可能聽過某些 SSD 標榜「斷電保護（Power Loss Protection, PLP）」。這是透過板上的電容，在偵測到供電中斷的瞬間，提供足夠電力讓控制器把 DRAM 快取中的資料寫入快閃記憶體。這項功能主要出現在企業級產品，因為資料中心的斷電損失極高。
遺憾的是，絕大多數消費級 SSD 與遊戲主機內建的儲存裝置，並沒有完整的 PLP。它們仰賴的是檔案系統的日誌與遊戲本身的原子寫入機制來兜底。這也解釋了為什麼「主機比較不容易壞檔」——並不是硬體特別神，而是主機平台對存檔流程有較嚴格的一致性要求，加上存檔通常會保留多份雲端與本機備份。
五、主機平台與雲端同步的特殊做法
如果你主要在家用主機上玩遊戲，可能會發現存檔損毀的災情相對少見。這不是錯覺。
首先，主機的系統軟體通常會把存檔視為受保護的系統資料，由平台層統一管理寫入流程，開發者不能隨便用最原始的方式直接寫檔。這種「平台代管」的做法，等於把原子性的責任從個別遊戲轉移到經過嚴格測試的系統層。
其次，主機普遍支援雲端存檔同步。以 Steam Cloud 為例，它在同步時會比對時間戳與雜湊值，並保留一定程度的版本歷史。若本機存檔損毀，玩家通常可以從雲端取回較早的版本。PlayStation Plus 與 Nintendo Switch Online 也有類似的雲端備份服務。
不過雲端同步是把雙面刃。最經典的災難情境是：本機存檔在某次異常關機後損毀，遊戲啟動時讀不到存檔，於是以「全新進度」覆蓋，接著雲端同步偵測到「本機版本較新」，忠實地把壞掉的進度上傳，順便把雲端的好檔案蓋掉。這類案例在玩家社群中時有所聞。因此，聰明的玩家會養成定期手動上傳備份、或關閉自動同步後再進行高風險操作的習慣。
六、玩家能做的自我保護：實用檢查清單
技術層面的機制再完善，玩家的使用習慣仍是最後一道防線。以下幾點是筆者認為最值得建立的習慣，特別是對於動輒上百小時的長篇 RPG 或模擬經營類遊戲。
七、常見誤解與 Q&A
誤解一：存檔壞掉一定是硬碟壞了
其實不然。在現代系統上，硬體故障導致的壞檔比例並沒有想像中高。更常見的元凶是：存檔途中程式崩潰、系統當機、使用者強制關閉電源、遊戲本身的存檔邏輯有 bug、或是存檔編輯工具與模組（mod）造成格式不相容。硬碟壞軌通常會伴隨其他症狀，例如讀取變慢、系統卡頓、其他檔案也出現異常。若只有單一存檔損毀，優先懷疑軟體因素。
誤解二：多存幾個檔就一定安全
多槽存檔當然比單槽安全，但如果所有槽位都寫在同一顆硬碟、同一個資料夾，那麼硬碟掛掉時它們會一起消失。真正的備份強調「3-2-1 原則」：至少三份資料、兩種不同媒體、一份異地存放。對玩家來說，最實務的版本就是「本機多槽 + 外接硬碟 + 雲端」三者並行。
誤解三：雲端同步就萬無一失
雲端服務本身相當可靠，但同步邏輯是以「版本新舊」為判斷依據，而不是「內容好壞」。如果壞掉的檔案時間戳比較新，雲端很可能會把它當成正確版本上傳。因此，雲端是備份的一環，而不是備份的全部。
誤解四：現在的遊戲都有原子存檔，所以停電沒差
大型商業作品與主機平台的存檔流程確實相當嚴謹，但並非所有遊戲都如此。獨立遊戲、老遊戲、或是移植品質不佳的作品，仍有可能採用天真的直接覆蓋寫法。此外，即使遊戲本身做得好，若儲存裝置謊報刷新指令、或作業系統在異常關機時攔截了部分寫入，風險依然存在。原子性大幅降低機率，但不能保證零風險。
八、結語：原子性是一種對玩家的尊重
回到最初的問題：停電會不會讓存檔壞掉？答案是——在設計良好的系統上，幾乎不會；在粗糙的實作上，隨時會。原子性不是什麼高深莫測的黑魔法，它的核心思想樸素得驚人：不要破壞唯一的副本，先把新的做好、驗證好，再一口氣換上去。這個原則幾十年來支撐著銀行轉帳、資料庫交易，也默默守護著你那個在異世界冒險了三百小時的角色。
下次當你按下存檔、看到畫面角落轉起小小的圖示時，不妨想像一下背後正在發生的事：資料被序列化、寫入暫存檔、強制刷新到快閃記憶體、校驗碼逐位元組比對、然後一個原子性的改名動作，把嶄新的世界狀態封存起來。這一切只花了零點幾秒，卻是無數工程師在檔案系統、韌體、遊戲引擎裡層層堆疊出來的成果。
也希望這篇文章能讓雅寶社區 · 頂客論壇的朋友們，在面對「存檔損毀」這個遊戲生涯中最令人心碎的關鍵字時，多一分理解，少一分無助。願你的每一次存檔都順利落地，願你的每一段冒險都不會因為一場突如其來的停電而化為烏有。如果真的不幸遇到，別忘了先深呼吸，然後去翻翻那個你可能從來沒注意過的 .bak 檔案——它很可能就是你的救星。