循環衝突（Cyclic Interaction）報錯的本質
在基於 Bethesda 引擎（如《上古卷軸》與《異塵餘生》系列）的模組體系中，無論是使用 Mod Organizer 2、Vortex 還是獨立的工具鏈，LOOT（Load Order Optimisation Tool，載入順序最佳化工具）都是玩家管理和自動排列外掛模組順序的核心基礎設施。然而，隨著模組清單中 .esm、.esp 和 .esl 檔案數量增加到數百個，玩家常常會遭遇一個徹底阻塞排序流程的致命紅色報錯：
Cyclic interaction detected between plugins: "PluginA.esp" -> "PluginB.esp" -> "PluginC.esp" -> "PluginA.esp"
一旦出現此報錯，LOOT 將立即中止排序。現有的載入順序被強行凍結在未經最佳化的未知狀態，新加入的相容性修補檔無法就位，前置覆蓋關係也無法滿足。如果玩家在這種死鎖狀態下強行啟動遊戲，缺失主檔案或排序倒置的外掛模組幾乎必然導致遊戲在主選單崩潰（CTD），或在運行中引發嚴重的任務與指令碼邏輯損壞。
理解循環相依性形成的圖論底層邏輯以及 LOOT 的規則仲裁機制，能夠讓玩家在無需清空設定或重裝大型模組整合包的情況下，精準切斷衝突節點。
LOOT 排序背後的圖論與拓撲排序
LOOT 確定外掛模組順序並非依靠模糊的經驗推測，而是嚴格遵循圖論中的數學計算。
LOOT 的排序核心將玩家當前的全部外掛模組建模為一個有向無環圖（Directed Acyclic Graph，簡稱 DAG）：
- 頂點（Node / Vertex）： 遊戲 Data 目錄下啟用的每一個外掛模組檔案都被視為圖中的一個獨立節點。
- 有向邊（Directed Edge）： 規則中規定的「外掛模組 A 必須排在外掛模組 B 之前載入」，在數學圖模型中被表示為一條從節點 A 指向節點 B 的單向箭頭（$A \rightarrow B$）。
為了將成百上千個具有交叉相依性的外掛模組輸出為一個一維線性的排序清單（即從 00 到 FE 的載入序號），LOOT 必須對該圖執行拓撲排序（Topological Sort）。拓撲排序演算法的定義是：將圖中的所有頂點排成一個線性序列，使得對於圖中的任意一條有向邊 $u \rightarrow v$，頂點 $u$ 在序列中都出現在頂點 $v$ 的前面。
圖論的一個根本定理是：有向圖能夠成功進行拓撲排序的充要條件是該圖不包含任何有向環（即必須為無環圖 DAG）。
一旦規則鏈條中出現了「外掛模組 A 必須在 B 之前（$A \rightarrow B$）」、「外掛模組 B 必須在 C 之前（$B \rightarrow C$）」，同時又存在「外掛模組 C 必須在 A 之前（$C \rightarrow A$）」的矛盾，整個有向圖就會形成一個首尾閉合的環路。在這種情況下，數學上不存在任何一種能夠同時滿足所有條件的線性排列方案。LOOT 偵測到這種無法自洽的邏輯閉環後，便會拋出「Cyclic interaction detected」並終止流程。
規則分級：硬規則與軟規則的碰撞
要排查循環衝突，必須理解 LOOT 在構建外掛模組圖時處理的兩類優先級完全不同的規則：
1. 硬規則（Hard Rules，不可打破的剛性約束）
硬規則是 LOOT 必須絕對遵從的底層結構要求。如果硬規則之間發生矛盾並閉合成環，排序必定宣告失敗。硬規則包括：
- 主檔案標記（Master Flag）： 帶有
.esm標誌的外掛模組必須排在所有未標記主檔案的普通.esp之前。 - 內部檔案頭主檔案相依性（Header Masters）： 若
Plugin B的內部檔案頭（File Header）中的MAST（Master Files）欄位將Plugin A列為其前置，則Plugin A在物理上必須早於Plugin B載入，否則引擎啟動時會直接閃退。 - 遊戲官方硬編碼順序： 官方核心檔案（如
Skyrim.esm、Update.esm、Fallout4.esm）擁有引擎寫死的固定載入位置，必須排在所有第三方內容前。 - 使用者自訂「在其後載入」規則（User "Load After" Rules）： 玩家在 LOOT 詮釋資料編輯器中手動指定的相依性規則被視為最高優先級的硬規則。
- 先決條件詮釋資料（Requirements Metadata）： 官方主清單中標記為硬性前置的關係。
2. 軟規則（Soft Rules，可彈性忽略的建議約束）
軟規則用於指導日常衝突的最佳覆蓋順序，但在威脅到圖的整體可排序性時會被自動放棄：
- 分組規則（Group Rules）： LOOT 將外掛模組劃分為層次化的分組（如 Core、Bug Fixes、UI、Late Loaders）。如果某個分組規則與底層主檔案的硬規則發生衝突，LOOT 會自動忽略該分組約束以避免形成循環。
- 重疊規則（Overlap Rules）： LOOT 透過掃描兩個外掛模組是否修改了相同的內部紀錄或資產來計算覆蓋偏好。當重疊規則與硬規則衝突時，重疊規則會被自動捨棄。
正因為 LOOT 已經具備自動捨棄軟規則循環的容錯能力，幾乎所有頑固的循環相依性報錯，本質上都是硬規則之間的不可調和衝突——尤其是內部檔案頭主檔案相依性與使用者自訂「在其後載入」規則之間的直接衝突。
引發循環衝突的三大典型場景
在實際模組安裝過程中，循環相依性報錯絕大多數可以歸納為以下三種具體原因：
場景一：相容性修補檔之間的互相前置死鎖
當玩家安裝了多個大型模組的跨界相容性修補檔時最容易出現此類問題。
- Mod A 相依前置底包 X。
- Mod B 相依前置底包 Y。
- 修補檔作者製作了
Patch1.esp來平衡 A 與 B，但在打包時疏忽大意，讓Patch1.esp把Patch2.esp列為了前置主檔案；而另一位作者製作的Patch2.esp內部又把Patch1.esp（或其中間相依項）列為了前置主檔案。 兩者在物理上都要求對方先於自己載入，直接構成底層檔案頭的相互相依死鎖。
場景二：使用者自訂規則與檔案頭主檔案硬衝突
玩家在參考某些陳舊的網路攻略或自行調試時，在 LOOT 的外掛模組編輯器中手動添加了強制排序規則。 例如：
- 玩家手動設定：強制
Weapon_Patch.esp必須排在Weather_Mod.esp之後載入。 - 然而，
Weather_Mod.esp本身或其前置框架，在其內部檔案頭中恰恰引用了Weapon_Patch.esp作為其底層主檔案之一。 玩家的主觀規則與外掛模組客觀存在的檔案頭相依性形成反向對衝，強行閉合出一條衝突環路。
場景三：ESM 標記外掛模組非法引用普通 ESP 前置
Bethesda 引擎底層要求所有帶 ESM 標記的外掛模組必須排在所有普通 ESP 之前。如果某位模組作者將外掛模組標記為 ESM（或 ESL 格式），但其開發時卻錯誤地引用了一個未經 ESM 化的普通 .esp 作為前置主檔案：
- 主檔案相依性規則要求：普通 ESP 必須排在 ESM 之前載入。
- 引擎主檔案標記規則要求：ESM 必須排在普通 ESP 之前載入。 這兩條硬規則在 LOOT 內部發生正面衝突，直接觸發循環報錯。
五步系統排查與修復流程
根據 365Finds 的評估，絕大多數循環相依性報錯並非源於 LOOT 官方主清單的邏輯缺陷，而是由玩家過度疊加的「在其後載入」自訂規則，或是第三方修補檔作者在製作時誤將彼此標記為主檔案所致；優先清理自訂詮釋資料並透過 xEdit 排查真實紀錄參照，能在不重裝大型整合包的前提下解決 90% 以上的排序死鎖。
請按照以下由淺入深的步驟逐步解開死鎖：
第一步：精確抄錄報錯中的衝突環路
當 LOOT 彈出循環衝突警告時，仔細閱讀警告視窗中的文字內容（或查看主介面頂部的狀態卡片）。報錯會明確列出閉環的完整鏈路。
例如：
Back cycle: ModAlpha.esp, ModBeta.esp, PatchGamma.esp, ModAlpha.esp
將環路中涉及的每一個外掛模組名稱記錄下來。發生邏輯閉環的問題絕對僅存在於這幾個被點名的外掛模組之間。
第二步：審查並清空衝突外掛模組的使用者詮釋資料
在動用高級修改工具之前，首先排查是否是人工設定的自訂規則引發了衝突：
- 在 LOOT 主介面左側或中間的外掛模組清單中，找到上述環路中涉及的外掛模組。
- 點擊外掛模組條目右側的三點圖示（⋮），選擇編輯詮釋資料（Edit Metadata）。
- 檢查**在其後載入（Load After）分頁與分組（Group）**分頁。
- 如果發現存在帶有使用者自訂標記的條目，點擊右側的垃圾桶圖示刪除所有手動的「在其後載入」規則。
- 點擊核取記號圖示保存詮釋資料。
- 點擊 LOOT 頂部的排序按鈕重新運行排序。如果報錯消失，說明問題純粹是人工規則衝突引起的。
第三步：在 xEdit 中檢查底層物理檔案頭
如果清空使用者詮釋資料後依然報錯，說明死鎖刻錄在外掛模組本身的物理檔案頭中：
- 透過模組管理器啟動 xEdit（如 SSEEdit、FO4Edit 等）。
- 在彈出的外掛模組選擇視窗中，右鍵選擇「Select None」，然後僅僅勾選衝突環路中涉及的那幾個外掛模組（以及遊戲官方的基礎 ESM）。只載入極簡清單可以大幅提升讀取速度並避免干擾。
- 等待背景載入完成後，在左側導航欄中展開這幾個外掛模組，點擊每個外掛模組頂部的第一條基礎紀錄：
File Header（檔案頭）。 - 在右側視窗中，找到
Master Files (MAST)子紀錄。 - 對照環路名單，核對它們的主檔案前置引用：
ModAlpha.esp的檔案頭裡是否包含了PatchGamma.esp？PatchGamma.esp的檔案頭裡是否包含了ModBeta.esp？ModBeta.esp的檔案頭裡是否包含了ModAlpha.esp？
第四步：使用「Clean Masters」剔除虛假前置
很多時候，修補檔作者在 Creation Kit 中製作修補檔時順手載入了不相干的模組，導致外掛模組被誤加上了無用主檔案標籤，但修補檔內根本沒有修改該主檔案的任何紀錄：
- 在 xEdit 左側，右鍵點擊懷疑帶有冗餘主檔案的修補檔外掛模組。
- 在右鍵選單中選擇 Clean Masters（清理主檔案）。
- xEdit 會全面掃描該外掛模組的所有數據紀錄。如果該外掛模組實際上並沒有引用該主檔案中的任何 FormID，xEdit 會安全地將多餘的主檔案條目從
MAST頭中永久抹除。 - 按
Ctrl + S保存被修改的外掛模組並退出 xEdit。
第五步：處理真實的互斥修補檔衝突
如果執行「Clean Masters」後沒有變化，說明該外掛模組確實同時修改了環路中其他外掛模組的數據：
- 這通常意味著玩家在安裝模組時，誤將同一修補檔的不同互斥分支同時裝進了遊戲（例如在 FOMOD 安裝器中同時勾選了「獨立版修補檔」與「整合版修補檔」）。
- 在模組管理器中停用或重新安裝相關模組，剔除多餘的互斥修補檔檔案。
- 重新打開 LOOT 點擊排序。此時有向無環圖恢復健康，拓撲排序順利執行，玩家即可安全套用生成的載入順序。