平臺橫傾異常發生在火箭下降末段。
控制系統檢測到右舷浪湧，命令左側壓載艙排水、右側進水。理論上十六隻閥應按分配曲線同步動作，實際橫傾卻先朝相反方向增加。
兩秒後，姿態才被拉回。對普通船舶而言兩秒很短，對正準備落下的火箭而言，兩秒足以讓制導系統多做一輪側向修正。
火箭飛控日誌顯示，那次額外修正消耗的推進劑不多，卻把支腿預期落點向左推了二十七釐米。安全裕度被同時從平臺與火箭兩端吃掉，只看任何一邊都不會覺得嚴重。
平臺慣導、閥位和火箭相對位置原本使用三套時鐘。團隊先把它們統一到同一時間基準，才確認甲板反向傾斜發生在閥門實際動作之前，而不是資料對不齊造成的假順序。
事後單閥測試中，十六隻閥的開啟時間都在限值內。液壓泵輸出穩定，閥芯也沒有海水腐蝕卡滯。
周野要求重放毫秒級日誌。普通監控只每秒記一次位置，看上去所有閥同時到位；高速控制記錄裡，右側第四閥比左側第七閥晚了五十二毫秒。
五十二毫秒本身不至於造成零點四度橫傾，問題在於控制器看到初始姿態沒改善，又追加一次修正。第一批閥還沒完全動作，第二批命令已經壓上去。
液壓管路中的壓力波隨後反射，幾隻閥短暫越過目標開度。平臺不是沒有執行命令，而是執行得太積極，先欠一步，再多走一步。
控制團隊把責任歸到網路延遲。周野卻發現，網路時間戳差只有七毫秒，剩下四十五毫秒發生在閥的液壓響應裡。
每隻閥單獨動作時，蓄能器壓力充足；十六隻閥同時動作，遠端支路瞬間降壓，閥芯起步變慢。等主泵補上流量，延遲又突然消失。
為了復現這個瞬間，液壓組在臺架上讓十六隻閥按真實動作曲線開啟。只開十五隻時壓力谷仍不明顯，第十六隻加入後，瓶頸支路流速跨過臨界，區域性損失陡然增加。
他們把一隻近端閥與一隻遠端閥互換，延遲仍跟著管路位置而不是跟著閥走。十六隻合格閥終於洗清了“個別動作慢”的嫌疑。
這解釋了為什麼靜態單閥測試全部合格，也解釋了為什麼海況越複雜、同時動作越多，異常越容易出現。
林浩把管路畫成網路圖。四隻蓄能器按平均距離佈置，看似均勻，真正的同時流量路徑卻在右舷形成一個瓶頸彎頭。
彎頭內徑沒有變小，內壁也乾淨。問題來自三條支路在同一點匯合，壓力波到達後互相疊加，形成一次短暫反壓。
透明水力模型中，三股流在彎頭外側形成旋渦。旋渦只存在幾十毫秒，穩態流量測試根本看不見，卻剛好卡在閥芯起步階段。
若只把彎頭換得更大，現場需要切開主幹管並長時間停機。模型表明，短時本地供壓能繞過旋渦最強的視窗，主泵流動穩定後再接管更經濟。
陳大川聽完問：“十六隻閥都沒壞，合起來就會搶水？”
梁師傅說：“一人過門都不堵，十六個人一起衝，門還是那扇門。”
簡單提高主泵壓力會讓近端閥動作更猛，反而擴大超調。擴大整套管徑來不及，也會增加大量海上改造。
周野提出在四個關鍵閥組增加本地小容量液壓緩衝器。它們不承擔持續供油，只負責最初幾十毫秒，讓遠端閥先起步，再由主泵接管。
控制策略也從“等待平臺姿態變化”改為讀取閥端實際位移。第一批閥沒有完成規定行程前，不允許姿態控制器盲目疊加第二批命令。
姿態訊號仍參與控制，但被分成預測與校正兩層。閥端位移負責告訴系統命令是否真正落地，甲板傾角負責判斷水量分配是否達到效果，兩者不再互相替代。
當某組閥位與姿態變化矛盾時，系統優先進入限幅模式，不允許控制器繼續加碼。錯誤可以暫時不被完全糾正，卻不能在資訊不清時被放大。
為防網路中斷，每個閥組保留本地同步邏輯。收到同一動作序號後，四組先按預定曲線執行，事後再向中央控制器報告，而不是排隊等逐條命令。
系統掃描到平臺倉庫裡一批報廢起重機液壓蓄能器。殼體耐壓足夠，因介面標準不匹配被閒置，可重構成緊湊緩衝元件。
【檢測到可重構液壓儲能元件】
】制控環閉步同與衝緩地本組閥：標目【
】：點構重耗消計預【
】：點構重前當【
。秒毫二十五的鍵關最上不趕又，慢太放釋；題問擊衝變題問遲延把會，快太放釋若能蓄。認確有沒野周
。立溫室室驗實在只能不窗視秒毫十八。升上會又力充預能蓄，後熱曬太被板甲；慢變會應響流節，加增度黏溫低油。化變度溫上海對面須必還衝緩
。數引定固條一靠依能不而，換切被差隨流節級兩讓須必，區溫全顧兼法無口孔一單示顯果結。試測別分板甲溫高到晨清溫低從，艙控溫放架臺把隊團
。開踹時同後背從人被像閥隻六十讓能不卻，力口一那好備準先前來到的真湧浪在須必統系
