開場當(dāng)你興致勃勃地打開編輯器，按下保存鍵，期待熱重載的奇跡發(fā)生——結(jié)果編輯器直接崩潰，或者資源根本沒更新。這一幕在從零自研引擎時幾乎無法避免。最初我在 Linux 上用 inotify 跑通了文件監(jiān)控，信心滿滿移植到 Windows，發(fā)現(xiàn)ReadDirectoryChangesW的行為模式完全不同；再到 macOS，F(xiàn)SEvents 又是一套獨(dú)立 API。三套代碼、三種語義、三種坑位——這不是偶然，而是三套 API 在內(nèi)核里各自長在完全不同的機(jī)制上。更麻煩的是，資源管線、游戲邏輯、序列化系統(tǒng)全都依賴這個監(jiān)聽器，它吐出一個錯誤事件，上層一切跟著翻車。下面先講清「為什么三個系統(tǒng)長得不一樣」，再逐個拆坑，最后給出一套能用的抽象層設(shè)計。一、為什么三套 API 差異這么大文件監(jiān)控不是"操作系統(tǒng)提供的標(biāo)準(zhǔn)功能"，而是各內(nèi)核在不同歷史背景下長出來的不同機(jī)制，理解它們的出身，才能理解行為的差異：Linux inotify：掛在 inode 上的觀察點(diǎn)（watch）。你監(jiān)視的是"這個目錄這個 inode 上發(fā)生的事件"，所以它天然不遞歸——子目錄是另一個 inode，想監(jiān)視得自己挨個加 watch。事件帶 cookie 字段，專門為配對 rename 設(shè)計。Windows ReadDirectoryChangesW：基于目錄變更通知 + IRP（I/O Request Packet）。你提交一個緩沖區(qū)給系統(tǒng)，系統(tǒng)把變更記錄填進(jìn)去還給你。它天然