1. 從“多頁”到“單頁”為什么我們需要SPA如果你在2010年左右開始接觸Web開發(fā)那時(shí)的體驗(yàn)和今天截然不同。每次點(diǎn)擊一個(gè)鏈接瀏覽器都會(huì)“白屏”一下然后整個(gè)頁面刷新服務(wù)器會(huì)返回一個(gè)完整的、全新的HTML文檔。這種模式被稱為“多頁應(yīng)用”。它的優(yōu)點(diǎn)是簡(jiǎn)單、直接對(duì)搜索引擎友好但缺點(diǎn)也顯而易見用戶體驗(yàn)割裂每次交互都伴隨著頁面重載大量的重復(fù)內(nèi)容如導(dǎo)航欄、頁腳被反復(fù)傳輸和渲染浪費(fèi)了帶寬和計(jì)算資源。單頁應(yīng)用的出現(xiàn)正是為了解決這些問題。它本質(zhì)上是一個(gè)Web應(yīng)用但在用戶首次訪問時(shí)只加載一個(gè)初始的HTML頁面。之后的所有交互都通過JavaScript動(dòng)態(tài)地更新當(dāng)前頁面的內(nèi)容而無需向服務(wù)器請(qǐng)求完整的頁面。這帶來了幾個(gè)核心優(yōu)勢(shì)極致的流暢體驗(yàn)應(yīng)用切換視圖時(shí)沒有頁面重載的“白屏”和閃爍操作反饋幾乎是瞬時(shí)的感覺更像一個(gè)桌面或移動(dòng)原生應(yīng)用。前后端分離SPA通常與RESTful API或GraphQL API配合前端客戶端和后端服務(wù)器完全解耦。后端只負(fù)責(zé)提供數(shù)據(jù)接口前端負(fù)責(zé)所有UI渲染和交互邏輯。這使得團(tuán)隊(duì)可以并行開發(fā)技術(shù)棧選擇也更靈活。狀態(tài)持久化由于頁面不刷新應(yīng)用的復(fù)雜狀態(tài)如用戶填寫的表單、購物車內(nèi)容、復(fù)雜的UI狀態(tài)可以一直保留在客戶端內(nèi)存中不會(huì)被意外清除。然而天下沒有免費(fèi)的午餐。SPA在帶來卓越體驗(yàn)的同時(shí)也引入了全新的復(fù)雜性。一個(gè)簡(jiǎn)單的“Hello World”SPA和支撐起千萬級(jí)日活的商業(yè)級(jí)SPA其內(nèi)部架構(gòu)天差地別。隨著功能模塊的增加代碼如何組織路由如何管理狀態(tài)如何同步性能如何保障這些都是SPA架構(gòu)設(shè)計(jì)必須直面的挑戰(zhàn)。本文的上半部分我們將深入探討構(gòu)建一個(gè)高效、可擴(kuò)展SPA的核心架構(gòu)思想與關(guān)鍵設(shè)計(jì)決策。2. SPA的核心架構(gòu)模式MVC、MVVM與Flux的演進(jìn)要理解SPA的架構(gòu)首先要理解其代碼組織模式。多年來前端社區(qū)演化出了幾種主流的架構(gòu)模式它們定義了數(shù)據(jù)、視圖和邏輯之間的關(guān)系。2.1 MVC經(jīng)典的起點(diǎn)MVC模式大家都很熟悉Model模型管理應(yīng)用的數(shù)據(jù)和業(yè)務(wù)邏輯View視圖負(fù)責(zé)數(shù)據(jù)的展示Controller控制器接收用戶輸入?yún)f(xié)調(diào)Model和View的更新。在早期的jQuery時(shí)代我們其實(shí)就在不自覺中使用著MVC。數(shù)據(jù)Model可能是一個(gè)全局的JavaScript對(duì)象DOM元素就是View而一堆綁定在按鈕點(diǎn)擊事件上的$.ajax和操作DOM的代碼就是Controller。問題在于這種模式下的依賴關(guān)系往往是混亂的。View可以直接操作ModelModel的變化也可能直接觸發(fā)DOM操作導(dǎo)致“面條式”代碼難以維護(hù)。當(dāng)應(yīng)用規(guī)模變大時(shí)數(shù)據(jù)流會(huì)變得難以追蹤。2.2 MVVM數(shù)據(jù)驅(qū)動(dòng)的現(xiàn)代實(shí)踐MVVM模式可以看作是MVC的一種進(jìn)化它更加強(qiáng)調(diào)數(shù)據(jù)與視圖的自動(dòng)同步。其核心是ViewModel它是一個(gè)特殊的對(duì)象充當(dāng)了View和Model之間的“粘合劑”。Model代表純數(shù)據(jù)狀態(tài)。View基于HTML的模板聲明式地描述UI應(yīng)該是什么樣子。ViewModel它持有Model的數(shù)據(jù)并通過數(shù)據(jù)綁定機(jī)制將數(shù)據(jù)“暴露”給View。當(dāng)ViewModel中的數(shù)據(jù)發(fā)生變化時(shí)View會(huì)自動(dòng)更新反之當(dāng)用戶在View中輸入時(shí)變化也會(huì)自動(dòng)反映到ViewModel中?，F(xiàn)代前端框架如Vue.js和Angular的核心思想就是MVVM。以Vue為例你定義一個(gè)data對(duì)象Model在模板View中使用{{}}或指令綁定這些數(shù)據(jù)。Vue內(nèi)部會(huì)創(chuàng)建一個(gè)響應(yīng)式系統(tǒng)ViewModel監(jiān)聽data的變化并自動(dòng)計(jì)算出需要更新的最小DOM范圍。開發(fā)者幾乎不需要手動(dòng)操作DOM只需關(guān)心數(shù)據(jù)的狀態(tài)。這極大地提升了開發(fā)效率和代碼的可維護(hù)性。注意雖然React官方并未宣稱自己是MVVM但其“狀態(tài)驅(qū)動(dòng)視圖”的思想與MVVM一脈相承。useState、useReducer等Hook管理的狀態(tài)就是“Model”JSX是“View”而React的渲染機(jī)制和setState函數(shù)共同扮演了同步更新的角色。2.3 Flux與單向數(shù)據(jù)流應(yīng)對(duì)復(fù)雜狀態(tài)管理的答案MVVM解決了視圖與數(shù)據(jù)的同步問題但在大型應(yīng)用中當(dāng)多個(gè)組件都需要修改或依賴同一份數(shù)據(jù)時(shí)數(shù)據(jù)流依然可能變得混亂。組件A修改了數(shù)據(jù)組件B和C如何知道并更新這就是狀態(tài)共享和數(shù)據(jù)流的挑戰(zhàn)。Facebook提出的Flux架構(gòu)及其具體實(shí)現(xiàn)如Redux、Vuex/Pinia給出了一個(gè)清晰的答案單向數(shù)據(jù)流。Flux的核心概念很簡(jiǎn)單View用戶界面。Action描述“發(fā)生了什么”的普通對(duì)象。例如{ type: ADD_TODO, text: Learn SPA }。Dispatcher在Redux中演化為Store的dispatch方法接收Action并將其派發(fā)到Store。Store持有整個(gè)應(yīng)用的狀態(tài)其更新邏輯是純函數(shù)Reducer。Store接收到Action后會(huì)根據(jù)Action的類型和負(fù)載計(jì)算出新的狀態(tài)。最關(guān)鍵的原則是數(shù)據(jù)的流動(dòng)是單向的。View不能直接修改Store只能通過派發(fā)Action來表達(dá)意圖。Store更新后通知所有訂閱了狀態(tài)變化的View進(jìn)行更新。這個(gè)閉環(huán)使得任何狀態(tài)變化都可預(yù)測(cè)、可追蹤、可調(diào)試。你可以記錄每一個(gè)Action和狀態(tài)快照輕松實(shí)現(xiàn)“時(shí)間旅行調(diào)試”。在實(shí)際項(xiàng)目中對(duì)于中大型SPA我強(qiáng)烈建議在項(xiàng)目早期就引入基于Flux思想的狀態(tài)管理庫。它帶來的約束和清晰度在項(xiàng)目后期會(huì)回報(bào)以巨大的可維護(hù)性紅利。對(duì)于Vue技術(shù)棧Pinia是目前更現(xiàn)代、更簡(jiǎn)潔的選擇對(duì)于ReactRedux ToolkitRTK極大地簡(jiǎn)化了Redux的使用。3. 路由設(shè)計(jì)SPA的導(dǎo)航基石在MPA中路由由服務(wù)器控制URL對(duì)應(yīng)一個(gè)具體的物理文件。而在SPA中路由完全由前端JavaScript控制。URL的變化不再導(dǎo)致頁面刷新而是觸發(fā)前端路由庫執(zhí)行相應(yīng)的回調(diào)函數(shù)加載對(duì)應(yīng)的組件、獲取必要的數(shù)據(jù)、更新頁面視圖。這就是客戶端路由。3.1 兩種路由模式Hash與History前端路由主要有兩種實(shí)現(xiàn)模式Hash模式利用URL中的哈希部分#。例如http://example.com/#/about。當(dāng)哈希變化時(shí)瀏覽器不會(huì)向服務(wù)器發(fā)起請(qǐng)求但會(huì)觸發(fā)hashchange事件前端路由庫監(jiān)聽此事件并更新視圖。它的兼容性極好甚至支持IE8。History模式利用HTML5 History APIpushState,replaceState。它允許我們操作瀏覽器的會(huì)話歷史棧從而改變URL如變成http://example.com/about而不刷新頁面。這使URL看起來更“干凈”更像一個(gè)真實(shí)的服務(wù)器路徑。但有一個(gè)至關(guān)重要的坑你需要配置你的服務(wù)器將所有前端路由即那些不是靜態(tài)資源或API的路徑都重定向到你的入口HTML文件通常是index.html否則用戶直接訪問/about或在/about頁面刷新時(shí)服務(wù)器會(huì)返回404。實(shí)操心得對(duì)于新項(xiàng)目無腦選擇History模式并記得配置服務(wù)器如Nginx的try_files或Node.js/Express的app.get(*, ...)。Hash模式通常只在需要兼容非常古老的瀏覽器或者在不方便配置服務(wù)器的特殊環(huán)境下使用。3.2 動(dòng)態(tài)路由與路由守衛(wèi)現(xiàn)代路由庫如Vue Router、React Router提供了強(qiáng)大的功能動(dòng)態(tài)路由允許路徑中包含參數(shù)如/user/:id。在組件內(nèi)你可以通過$route.params.id或useParams()鉤子獲取這個(gè)id然后根據(jù)它去加載對(duì)應(yīng)的用戶數(shù)據(jù)。這是構(gòu)建詳情頁、個(gè)人中心等功能的基石。嵌套路由讓UI界面和URL結(jié)構(gòu)保持對(duì)應(yīng)。例如/settings/profile和/settings/security可以共享一個(gè)父級(jí)Settings布局組件只在子區(qū)域切換內(nèi)容。這使代碼組織更清晰。路由守衛(wèi)這是實(shí)現(xiàn)權(quán)限控制、數(shù)據(jù)預(yù)加載的關(guān)鍵鉤子。你可以在進(jìn)入路由前、離開路由時(shí)、甚至路由更新時(shí)執(zhí)行邏輯。全局前置守衛(wèi)適合做登錄狀態(tài)校驗(yàn)。如果用戶未登錄且試圖訪問需要權(quán)限的頁面可以重定向到登錄頁。路由獨(dú)享守衛(wèi)可以為某個(gè)特定路由定義邏輯。組件內(nèi)守衛(wèi)在Vue中可以在組件內(nèi)使用beforeRouteEnter、beforeRouteUpdate等選項(xiàng)。一個(gè)常見的模式是在進(jìn)入一個(gè)需要數(shù)據(jù)的頁面如文章詳情頁的路由守衛(wèi)中先發(fā)起API請(qǐng)求獲取數(shù)據(jù)待數(shù)據(jù)返回后再渲染組件或者展示一個(gè)加載狀態(tài)。這比在組件mounted或useEffect中獲取數(shù)據(jù)用戶體驗(yàn)更連貫避免了組件先渲染空狀態(tài)再閃爍填充數(shù)據(jù)的情況。4. 組件化設(shè)計(jì)構(gòu)建可復(fù)用的UI樂高組件化是SPA開發(fā)的靈魂。它將UI拆分成獨(dú)立、可復(fù)用、可組合的代碼單元。一個(gè)好的組件化設(shè)計(jì)能極大提升開發(fā)效率和代碼質(zhì)量。4.1 組件的劃分原則原子設(shè)計(jì)理論如何劃分組件一個(gè)實(shí)用的指導(dǎo)思想是原子設(shè)計(jì)理論。它將組件抽象為五個(gè)層次原子最基本的構(gòu)成單元如按鈕、輸入框、圖標(biāo)。它們本身沒有業(yè)務(wù)含義高度可復(fù)用。分子由原子組合而成的簡(jiǎn)單組件如一個(gè)搜索框輸入框按鈕、一個(gè)表單字段標(biāo)簽輸入框錯(cuò)誤提示。有機(jī)體相對(duì)復(fù)雜的、構(gòu)成界面一部分的組件如一個(gè)商品卡片、一個(gè)導(dǎo)航欄、一個(gè)評(píng)論列表。模板將多個(gè)有機(jī)體放置在布局中定義頁面的骨架結(jié)構(gòu)但內(nèi)容可能是占位的。它關(guān)注的是頁面的底層結(jié)構(gòu)而非最終內(nèi)容。頁面將真實(shí)的內(nèi)容數(shù)據(jù)填入模板后形成的特定實(shí)例。在實(shí)際開發(fā)中我們通常關(guān)注前三個(gè)層次。劃分組件的核心原則是單一職責(zé)和高內(nèi)聚低耦合。一個(gè)組件應(yīng)該只做一件事并且把它做好。如果一個(gè)組件變得過于龐大、難以理解或者一部分邏輯似乎可以在別處復(fù)用就是時(shí)候考慮拆分了。4.2 組件間的通信Props、Events與狀態(tài)提升組件之間如何交換數(shù)據(jù)和信息主要有以下幾種方式Props向下傳遞父組件通過屬性Props將數(shù)據(jù)傳遞給子組件。這是最基礎(chǔ)、最常用的單向數(shù)據(jù)流。Events向上傳遞子組件通過自定義事件Events通知父組件內(nèi)部發(fā)生的變化。父組件監(jiān)聽這些事件并做出響應(yīng)。狀態(tài)提升當(dāng)多個(gè)兄弟組件需要共享同一狀態(tài)時(shí)將這個(gè)狀態(tài)定義在它們最近的共同父組件中然后通過Props傳遞給它們。這是解決簡(jiǎn)單共享問題的有效方式。Provide/InjectVue或 ContextReact用于跨越多層級(jí)的組件傳遞數(shù)據(jù)避免“Prop逐級(jí)透?jìng)鳌钡穆闊Ｋ喈?dāng)于一個(gè)組件樹范圍內(nèi)的“全局”數(shù)據(jù)。狀態(tài)管理庫對(duì)于復(fù)雜的、全局的、多個(gè)不相關(guān)組件需要訪問的狀態(tài)使用如Pinia或Redux等狀態(tài)管理庫是更專業(yè)的選擇。設(shè)計(jì)決策示例假設(shè)我們有一個(gè)“用戶儀表盤”頁面包含用戶信息卡片和通知列表。UserCard和NotificationList可以設(shè)計(jì)為獨(dú)立的“有機(jī)體”組件。用戶數(shù)據(jù)如姓名、頭像可以從父組件DashboardPage通過Props傳遞給UserCard。如果UserCard里有一個(gè)“編輯資料”按鈕點(diǎn)擊后應(yīng)該觸發(fā)一個(gè)事件如edit-profile由DashboardPage監(jiān)聽并打開一個(gè)模態(tài)框。這樣打開模態(tài)框的邏輯可能涉及路由或全局狀態(tài)就由父級(jí)控制UserCard保持純粹。通知數(shù)據(jù)可能來自一個(gè)全局的StoreNotificationList組件直接從中訂閱數(shù)據(jù)。因?yàn)橥ㄖ赡茉趹?yīng)用的多個(gè)地方被更新如標(biāo)記已讀使用全局狀態(tài)管理更合適。4.3 渲染策略CSR、SSR與SSG的選擇這是SPA架構(gòu)中一個(gè)至關(guān)重要的、影響性能和SEO的決策點(diǎn)。客戶端渲染即典型的SPA模式。瀏覽器下載一個(gè)近乎空的HTML和巨大的JavaScript包由JS執(zhí)行后渲染出完整頁面。優(yōu)點(diǎn)后續(xù)交互極快用戶體驗(yàn)流暢開發(fā)體驗(yàn)好熱更新等。缺點(diǎn)首屏加載慢需要等待JS下載、解析、執(zhí)行對(duì)SEO不友好早期搜索引擎爬蟲可能無法執(zhí)行JS導(dǎo)致抓取不到內(nèi)容。雖然現(xiàn)代爬蟲如Google已能較好執(zhí)行JS但仍有延遲和不確定性。服務(wù)器端渲染為了解決CSR的缺點(diǎn)SSR應(yīng)運(yùn)而生。對(duì)于首次訪問的請(qǐng)求服務(wù)器會(huì)執(zhí)行你的前端應(yīng)用代碼在服務(wù)器上生成完整的HTML字符串然后發(fā)送給瀏覽器。瀏覽器能立即展示有內(nèi)容的頁面。之后瀏覽器再加載JS接管頁面使其成為一個(gè)正常的、可交互的SPA。這個(gè)過程稱為“注水”。優(yōu)點(diǎn)極佳的首屏性能完美的SEO支持。缺點(diǎn)服務(wù)器壓力大每個(gè)頁面請(qǐng)求都需要服務(wù)器實(shí)時(shí)渲染開發(fā)復(fù)雜度高需要考慮代碼的同構(gòu)運(yùn)行即既能在Node.js環(huán)境運(yùn)行又能在瀏覽器運(yùn)行對(duì)服務(wù)器性能敏感。靜態(tài)站點(diǎn)生成在構(gòu)建時(shí)而非請(qǐng)求時(shí)就預(yù)先將頁面渲染成靜態(tài)HTML文件。這些文件可以直接由CDN分發(fā)速度極快安全性高服務(wù)器成本極低。優(yōu)點(diǎn)無與倫比的性能和安全非常適合內(nèi)容相對(duì)固定、不依賴用戶實(shí)時(shí)數(shù)據(jù)的網(wǎng)站如博客、文檔、營銷頁。缺點(diǎn)數(shù)據(jù)更新時(shí)需要重新構(gòu)建。對(duì)于用戶個(gè)性化數(shù)據(jù)如“我的訂單”仍需在客戶端動(dòng)態(tài)獲取。如何選擇如果你的應(yīng)用是高度交互的管理后臺(tái)對(duì)SEO無要求CSR是最簡(jiǎn)單直接的選擇。如果你的應(yīng)用是面向公眾的內(nèi)容型網(wǎng)站如新聞、電商列表頁SSR或SSG是必須的。Next.jsReact、Nuxt.jsVue等元框架讓SSR/SSG的開發(fā)體驗(yàn)變得友好?？梢圆捎没旌喜呗詫?duì)首頁、產(chǎn)品頁等關(guān)鍵SEO頁面使用SSR/SSG對(duì)用戶后臺(tái)等私密頁面使用CSR。Next.js的“增量靜態(tài)再生”等功能很好地支持了這種混合模式。5. 狀態(tài)管理深度實(shí)踐以Redux Toolkit為例理解了Flux思想后我們以目前React生態(tài)最推薦的狀態(tài)管理方案——Redux Toolkit為例看看如何在實(shí)際項(xiàng)目中優(yōu)雅地管理狀態(tài)。RTK封裝了Redux的繁瑣樣板代碼提供了更簡(jiǎn)潔的API。5.1 創(chuàng)建Slice狀態(tài)與邏輯的集合在RTK中核心概念是createSlice。它允許你在一塊代碼中定義一片狀態(tài)的初始值、Reducer函數(shù)和Action創(chuàng)建器。// features/todos/todosSlice.js import { createSlice } from reduxjs/toolkit; const initialState { items: [], status: idle, // idle | loading | succeeded | failed error: null }; const todosSlice createSlice({ name: todos, initialState, reducers: { // “普通”Reducer同步更新狀態(tài) addTodo: (state, action) { // 在RTK中可以直接“修改”state因?yàn)樗鼉?nèi)部使用了Immer庫 state.items.push(action.payload); }, toggleTodo: (state, action) { const todo state.items.find(t t.id action.payload); if (todo) { todo.completed !todo.completed; } }, }, // 可以額外定義處理其他Action類型的Reducer extraReducers: (builder) { // 通常在這里處理異步Thunk Action的結(jié)果 } }); // 自動(dòng)生成的Action創(chuàng)建器 export const { addTodo, toggleTodo } todosSlice.actions; // Slice的Reducer export default todosSlice.reducer;createSlice會(huì)自動(dòng)根據(jù)你定義的reducers生成對(duì)應(yīng)的Action創(chuàng)建器。調(diào)用addTodo(newTodo)就會(huì)返回一個(gè){ type: todos/addTodo, payload: newTodo }的Action對(duì)象。5.2 異步邏輯與Thunk在實(shí)際應(yīng)用中大部分狀態(tài)變化都源于異步操作如調(diào)用API。RTK推薦使用createAsyncThunk來處理異步邏輯。// features/todos/todosSlice.js (續(xù)) import { createSlice, createAsyncThunk } from reduxjs/toolkit; import { fetchTodosApi } from ./todosApi; // 假設(shè)的API函數(shù) // 創(chuàng)建異步Thunk export const fetchTodos createAsyncThunk( todos/fetchTodos, async (_, { rejectWithValue }) { try { const response await fetchTodosApi(); return response.data; // 此返回值將作為action.payload } catch (error) { return rejectWithValue(error.message); // 錯(cuò)誤信息將作為action.payload } } ); const todosSlice createSlice({ name: todos, initialState, reducers: { /* ... 同步reducers ... */ }, extraReducers: (builder) { builder .addCase(fetchTodos.pending, (state) { state.status loading; }) .addCase(fetchTodos.fulfilled, (state, action) { state.status succeeded; state.items action.payload; }) .addCase(fetchTodos.rejected, (state, action) { state.status failed; state.error action.payload; }); } });createAsyncThunk會(huì)生成三個(gè)Action類型pending開始、fulfilled成功、rejected失敗。我們?cè)趀xtraReducers中處理這些Action來更新加載狀態(tài)、存儲(chǔ)數(shù)據(jù)或錯(cuò)誤信息。5.3 在組件中使用Hooks與性能在React組件中我們使用react-redux提供的Hooks來與Store交互。// components/TodoList.js import React, { useEffect } from react; import { useSelector, useDispatch } from react-redux; import { fetchTodos, toggleTodo } from ../features/todos/todosSlice; const TodoList () { const dispatch useDispatch(); // 從Store中選擇所需的狀態(tài) const { items, status, error } useSelector((state) state.todos); useEffect(() { if (status idle) { dispatch(fetchTodos()); } }, [status, dispatch]); const handleToggle (id) { dispatch(toggleTodo(id)); }; if (status loading) return divLoading.../div; if (status failed) return divError: {error}/div; return ( ul {items.map(todo ( li key{todo.id} onClick{() handleToggle(todo.id)} {todo.text} - {todo.completed ? Done : Pending} /li ))} /ul ); };性能優(yōu)化提示useSelector默認(rèn)使用進(jìn)行引用相等性檢查。如果Selector返回一個(gè)新的對(duì)象例如state ({ items: state.todos.items, status: state.todos.status })每次調(diào)用都會(huì)導(dǎo)致組件重新渲染即使實(shí)際數(shù)據(jù)沒變。有幾種解決方案多次調(diào)用useSelector選擇原始值。使用shallowEqual作為第二個(gè)參數(shù)進(jìn)行淺比較。使用reselect或RTK內(nèi)置的createSelector創(chuàng)建記憶化的Selector只有在輸入狀態(tài)改變時(shí)才重新計(jì)算。5.4 結(jié)構(gòu)化Store特性文件夾模式對(duì)于大型應(yīng)用如何組織Store代碼至關(guān)重要。推薦使用“特性文件夾”模式。即按照功能特性feature來組織代碼每個(gè)特性文件夾包含其相關(guān)的Slice、組件、API調(diào)用等。src/ ├── app/ │ ├── store.js // 配置和創(chuàng)建Store │ └── hooks.js // 封裝類型安全的useSelector/useDispatch可選 ├── features/ │ ├── todos/ // “待辦事項(xiàng)”特性 │ │ ├── todosSlice.js │ │ ├── todosApi.js │ │ └── components/ │ ├── auth/ // “認(rèn)證”特性 │ │ ├── authSlice.js │ │ └── ... │ └── ... └── ...在app/store.js中使用configureStore組合所有Slice的Reducer。// app/store.js import { configureStore } from reduxjs/toolkit; import todosReducer from ../features/todos/todosSlice; import authReducer from ../features/auth/authSlice; export const store configureStore({ reducer: { todos: todosReducer, auth: authReducer, }, });這種結(jié)構(gòu)清晰地將業(yè)務(wù)邏輯隔離便于團(tuán)隊(duì)協(xié)作和代碼維護(hù)。每個(gè)特性都是自包含的可以獨(dú)立開發(fā)、測(cè)試和理解。