最近在學(xué)習(xí)React時，我動手搭建了一個企業(yè)級儀表盤——就是那種帶有側(cè)邊欄導(dǎo)航、數(shù)據(jù)表格、篩選器和權(quán)限控制的復(fù)雜界面。這個項目逼著我跳出了新手教程的舒適區(qū)，也讓我意識到一個痛點：教科書式的React寫法，在真實業(yè)務(wù)場景里根本撐不住。

以下是我踩坑后總結(jié)的三個架構(gòu)教訓(xùn)。

一、數(shù)據(jù)獲?。簭氖謩觙etch到RTK Query的質(zhì)變

一開始我的直覺很樸素：用useEffect調(diào)fetch，把數(shù)據(jù)存進useState。簡單頁面沒問題，直到"質(zhì)量檢查"表格需要支持標(biāo)簽切換和篩選器聯(lián)動——狀態(tài)管理瞬間變成 spaghetti code，loading邏輯到處復(fù)制粘貼。

切換到RTK Query后，最直觀的收益是不再需要手動管理加載狀態(tài)和緩存邏輯。

具體做法是把API邏輯抽離到獨立的slice文件，定義端點時直接聲明數(shù)據(jù)標(biāo)簽（tagTypes）。組件層簡化為一個hook調(diào)用：當(dāng)activeTab變化，請求自動觸發(fā)更新。沒有useEffect的依賴地獄，沒有重復(fù)的isLoading判斷，代碼行為終于"像儀表盤該有的樣子"。

二、布局架構(gòu)：三欄式設(shè)計與樣式分離原則

新手項目通常是整頁滾動，但企業(yè)UI要求導(dǎo)航始終可見、僅數(shù)據(jù)區(qū)滾動。我最終采用三欄結(jié)構(gòu)：固定頂部欄 + 固定側(cè)邊欄 + 可滾動內(nèi)容區(qū)。

關(guān)鍵認(rèn)知是布局樣式與組件樣式必須解耦。根布局只負(fù)責(zé)框架級規(guī)則（flex布局、高度計算、溢出控制），內(nèi)容組件絕不碰這些屬性。這個分離讓UI從"網(wǎng)頁感"躍遷到"工具感"——用戶感知不到實現(xiàn)細節(jié)，但交互體驗完全不同。

三、權(quán)限控制：從條件渲染到路由級防護

最初的做法很直接：{user.role === "admin" && }。但問題很快暴露：權(quán)限邏輯散落在幾十個組件里，新增角色需要全局搜索替換，測試時根本不知道哪里漏了判斷。

重構(gòu)方案是單一權(quán)限配置源 + 路由包裝器。所有菜單和路由的權(quán)限規(guī)則集中在一個配置文件，ProtectedRoute組件統(tǒng)一處理未登錄跳轉(zhuǎn)和無權(quán)訪問。新角色"Manager"上線時，只需改配置表，零組件入侵。

這三個決策的共同點？都不是React語法層面的技巧，而是把代碼組織方式對齊到產(chǎn)品形態(tài)。儀表盤不是放大的表單頁面，它的數(shù)據(jù)流動性、布局穩(wěn)定性、權(quán)限復(fù)雜性，都要求架構(gòu)層面提前回答"這段代碼明年誰維護"的問題。