毑貫硨崙?zhàn)：3個技巧搞定報錯，附完整示例)
游戲?qū)毑貫硨崙?zhàn)：3個技巧搞定報錯，附完整示例
盯著屏幕滿屏紅色的 StackTrace，心里是不是咯噔一下？別慌，這種“報錯一堆看不懂”的絕望感，每個寫代碼的人都經(jīng)歷過。
特別是當(dāng)你剛接手一個類似“游戲?qū)毑貫场边@種模擬經(jīng)營類的小項目，邏輯看似簡單，但一旦涉及狀態(tài)同步、資源消耗和事件觸發(fā)，崩潰來得猝不及防。今天不聊虛的，直接給出一套可復(fù)現(xiàn)的完整示例，幫你從底層理清邏輯，徹底告別“看天書”式的調(diào)試。
我們不做那種只有“Hello World”的演示，而是直接搭建一個具備核心玩法閉環(huán)的微型項目。
項目目標(biāo)：構(gòu)建最小可行寶藏灣
很多新手一上來就想做大，結(jié)果死在需求蔓延里。我們這次的目標(biāo)很明確：做一個“極簡版游戲?qū)毑貫场薄?核心功能只有三個：資源采集：玩家點擊或定時自動獲取金幣和木材。
商店購買：用金幣升級采集效率或購買裝飾物。
狀態(tài)持久化：刷新頁面后，數(shù)據(jù)不丟失。為什么選這個？因為它涵蓋了前端開發(fā)中最頭疼的三塊硬骨頭：狀態(tài)管理、異步操作和本地存儲。搞定它，你的調(diào)試能力能提升一個臺階。
目錄結(jié)構(gòu)：清晰勝于聰明
工程化不是堆砌配置，而是讓代碼“找得到”。以下是我們推薦的標(biāo)準(zhǔn)目錄結(jié)構(gòu)，直接復(fù)制就能用：
game-treasure-bay/
├── public/
│ └── index.html
├── src/
│ ├── assets/ # 靜態(tài)資源
│ ├── components/ # 組件
│ │ ├── HUD.jsx # 頂部狀態(tài)欄
│ │ ├── Shop.jsx # 商店面板
│ │ └── Map.jsx # 地圖區(qū)域
│ ├── core/ # 核心邏輯（純函數(shù)，無UI依賴）
│ │ ├── gameEngine.js # 游戲引擎主邏輯
│ │ └── constants.js # 常量定義
│ ├── store/ # 狀態(tài)管理
│ │ └── useGameStore.js # 自定義 Hook
│ ├── App.jsx
│ └── main.jsx
├── package.json
└── vite.config.js關(guān)鍵點：注意 core 目錄。我們將所有純邏輯代碼剝離出來，不依賴 React。這樣做的好處是，當(dāng) StackTrace 指向邏輯錯誤時，你可以直接在控制臺里單元測試這段邏輯，而不用啟動整個 UI。
核心代碼實現(xiàn)：逐行拆解避坑點
這是本文的重點。我們將使用 React + Vite + Zustand（一個輕量級狀態(tài)庫，比 Redux 簡單得多）。
1. 定義常量與初始狀態(tài)
很多時候，報錯源于“魔法數(shù)字”。比如為什么金幣扣了 100 但沒變？因為你在兩個地方都寫了 100，改了一個忘了另一個。
// src/core/constants.js
export const RESOURCE_TYPES = {COIN: 'coin',WOOD: 'wood'
};export const UPGRADES = {'MINER_LEVEL_1': {id: 'MINER_LEVEL_1',name: '初級礦工',cost: { coin: 50, wood: 0 },effect: { coinPerSec: 1 },desc: '每秒自動產(chǎn)出1金幣'},'DECOR_TREE': {id: 'DECOR_TREE',name: '裝飾樹',cost: { coin: 100, wood: 10 },effect: { score: 10 },desc: '增加10分，純裝飾'}
};2. 核心游戲引擎（純邏輯）
這里最容易出 Bug 的地方是并發(fā)更新。如果你直接在組件里寫 setCoin(coin + 1)，在快速點擊時，React 的批量更新機制可能導(dǎo)致數(shù)值不準(zhǔn)。
// src/core/gameEngine.js/*** 計算購買后的新狀態(tài)* 純函數(shù)：輸入舊狀態(tài)，返回新狀態(tài)* @param {Object} state - 當(dāng)前游戲狀態(tài)* @param {String} upgradeId - 要購買的升級ID* @returns {Object} - 新狀態(tài)或錯誤對象*/
export function processPurchase(state, upgradeId) {const upgrade = UPGRADES[upgradeId];// 防御性編程：檢查升級是否存在if (!upgrade) {return { error: 'Upgrade not found', state };}// 檢查資源是否足夠const canAfford = state.resources.coin = upgrade.cost.coin state.resources.wood = upgrade.cost.wood;if (!canAfford) {return { error: 'Insufficient resources', state };}// 計算新資源const newResources = {coin: state.resources.coin - upgrade.cost.coin,wood: state.resources.wood - upgrade.cost.wood};// 更新升級列表const newUpgrades = [...state.upgrades];const existingIndex = newUpgrades.findIndex(u = u.id === upgradeId);if (existingIndex -1) {// 如果是重復(fù)購買，增加等級（簡化邏輯，實際項目可能更復(fù)雜）newUpgrades[existingIndex].level += 1;} else {newUpgrades.push({ ...upgrade, level: 1 });}return {error: null,state: {...state,resources: newResources,upgrades: newUpgrades}};
}為什么這樣寫？
看注釋里的 return { error: null, state: ... }。我們將“成功”和“失敗”封裝在同一個返回結(jié)構(gòu)中。在 UI 層，你只需要判斷 result.error 是否存在。這比拋出異常（Throw Exception）更適合前端這種高頻交互場景，避免了 try-catch 滿天飛導(dǎo)致的 StackTrace 混亂。
3. 狀態(tài)管理 Hook
使用 Zustand 管理狀態(tài)，它比 Redux 代碼量少 80%。
// src/store/useGameStore.js
import { create } from 'zustand';
import { persist } from 'zustand/middleware';
import { processPurchase } from '../core/gameEngine';
import { UPGRADES } from '../core/constants';const useGameStore = create(persist((set, get) = ({// 初始狀態(tài)resources: { coin: 100, wood: 10 },upgrades: [],score: 0,// ActionsaddResource: (type, amount) = set((state) = ({resources: {...state.resources,[type]: state.resources[type] + amount}})),buyUpgrade: (upgradeId) = {const state = get();const result = processPurchase(state, upgradeId);// 關(guān)鍵：只在成功時更新狀態(tài)if (!result.error) {set(result.state);} else {console.warn('Purchase failed:', result.error);// 這里可以觸發(fā) UI 提示，比如震動或紅字}},// 定時任務(wù)：每秒執(zhí)行tick: () = {const state = get();let coinGain = 0;// 計算所有礦工的產(chǎn)出state.upgrades.forEach(u = {if (u.effect u.effect.coinPerSec) {coinGain += u.effect.coinPerSec * u.level;}if (u.effect u.effect.score) {// 分數(shù)增加邏輯}});if (coinGain 0) {get().addResource('coin', coinGain);}}}),{name: 'treasure-bay-storage', // 本地存儲的 Keypartialize: (state) = ({ resources: state.resources, upgrades: state.upgrades })})
);export default useGameStore;避坑指南：
注意 persist 中間件的 partialize。不要把所有狀態(tài)都存進 LocalStorage！比如 isLoading、errorMessages 這些臨時狀態(tài)，存進去會導(dǎo)致刷新后頁面卡死或顯示舊錯誤。只存核心數(shù)據(jù)。
運行與測試：復(fù)現(xiàn)并解決 StackTrace
現(xiàn)在，讓我們模擬一個真實的報錯場景。
假設(shè)你在 Shop.jsx 中寫了這樣一段代碼：
// 錯誤示例：直接在渲染期間修改狀態(tài)
const Shop = () = {const { buyUpgrade, resources } = useGameStore();const handleBuy = (id) = {// 錯誤：如果資源不足，processPurchase 返回 error，但下面這行代碼依然執(zhí)行了 set// 導(dǎo)致 React 警告: Cannot update a component while rendering a different componentbuyUpgrade(id);}return (div{Object.values(UPGRADES).map(upg = (button key={upg.id} onClick={() = handleBuy(upg.id)}disabled={resources.coin upg.cost.coin}{upg.name}/button))}/div);
}報錯現(xiàn)象：
點擊按鈕后，控制臺出現(xiàn) Maximum update depth exceeded 或狀態(tài)無限循環(huán)。
排查步驟：打開 Chrome DevTools，查看 Components 面板。
發(fā)現(xiàn) Shop 組件在不斷重渲染。
檢查 useGameStore 的 buyUpgrade。
發(fā)現(xiàn) processPurchase 是純函數(shù)，沒問題。
問題出在 disabled 邏輯與 buyUpgrade 的異步性上？不，Zustand 是同步的。
再仔細看代碼：disabled 只是 UI 層面禁用，但 JS 邏輯上，如果用戶通過開發(fā)者工具強制觸發(fā)，或者資源計算有浮點誤差，buyUpgrade 依然會被調(diào)用。正確解法：
在 buyUpgrade 內(nèi)部做二次校驗，并在 UI 層增加“冷卻時間”或視覺反饋，防止快速連擊。
// 修正后的 buyUpgrade
buyUpgrade: (upgradeId) = {const state = get();const upgrade = UPGRADES[upgradeId];// 雙重校驗if (state.resources.coin upgrade.cost.coin) {// 觸發(fā) UI 錯誤提示，但不更新 store 狀態(tài)set({ error: 'Coin not enough' }); setTimeout(() = set({ error: null }), 2000);return;}const result = processPurchase(state, upgradeId);if (!result.error) {set(result.state);}
}通過這種分層校驗（UI 層 + Store 層 + 純邏輯層），你將 StackTrace 的長度縮短了一半，因為錯誤會在最早發(fā)生的層被攔截。
優(yōu)化擴展：從玩具到產(chǎn)品
當(dāng)基礎(chǔ)功能跑通后，如何讓它更像一個“產(chǎn)品”？性能優(yōu)化：使用 React.memo 包裹 Shop 和 HUD 組件，避免不必要的重渲染。
如果 tick 頻率變高（比如每 100ms 一次），將 tick 邏輯移入 requestAnimationFrame，而不是 setInterval，以保證幀率穩(wěn)定。模塊化拆分：將 gameEngine.js 拆分為 resourceEngine.js、upgradeEngine.js、saveEngine.js。
每個引擎負責(zé)單一職責(zé)，方便單獨測試。引入真實開源參考：如果你想知道工業(yè)級游戲狀態(tài)管理怎么做，推薦研究 GitHub 上的 PixiJS 或 Phaser 生態(tài)中的狀態(tài)管理模式。
特別是 Zustand 的官方文檔（GitHub 倉庫：stateful/zustand），其中關(guān)于“中間件”和“持久化”的章節(jié)，比任何博客教程都更權(quán)威。直接閱讀源碼，你會發(fā)現(xiàn)它對 partialize 的處理比很多第三方庫更優(yōu)雅。單元測試：使用 Vitest 對 core/gameEngine.js 編寫測試。
測試用例：資源不足時，狀態(tài)不變。
購買成功后，資源扣減正確。
重復(fù)購買同一升級，等級增加。// test/gameEngine.test.js
import { describe, it, expect } from 'vitest';
import { processPurchase } from '../src/core/gameEngine';describe('processPurchase', () = {it('should deduct resources on successful purchase', () = {const initialState = {resources: { coin: 100, wood: 10 },upgrades: []};const result = processPurchase(initialState, 'MINER_LEVEL_1');expect(result.error).toBeNull();expect(result.state.resources.coin).toBe(50);expect(result.state.upgrades.length).toBe(1);});it('should not change state if resources insufficient', () = {const initialState = {resources: { coin: 10, wood: 0 },upgrades: []};const result = processPurchase(initialState, 'MINER_LEVEL_1');expect(result.error).toBe('Insufficient resources');expect(result.state).toBe(initialState); // 引用相等，未修改});
});小結(jié)：調(diào)試是一種肌肉記憶
回顧整個“游戲?qū)毑貫场钡拇罱ㄟ^程，核心不在于代碼有多炫，而在于邊界是否清晰。純邏輯層（core）：只處理數(shù)據(jù)，不碰 DOM，不碰 Store API。
狀態(tài)層（store）：只負責(zé)數(shù)據(jù)的存儲和同步，不包含業(yè)務(wù)判斷。
UI 層（components）：只負責(zé)展示和交互觸發(fā)。當(dāng) StackTrace 出現(xiàn)時，你可以根據(jù)堆棧信息快速定位是哪一層出了問題：如果是 undefined is not a function，大概率是純邏輯層傳參錯誤。
如果是 Invalid hook call，大概率是 UI 層組件結(jié)構(gòu)混亂。
如果是 State update loop，大概率是 Store 層在渲染期間觸發(fā)了更新。這種分層思維，比背下某個框架的 API 更重要。它讓你在面對任何技術(shù)棧時，都能迅速建立心智模型，從“猜 Bug”變成“定位 Bug”。
你更常用哪種寫法？是習(xí)慣用 Redux 這種重型方案，還是更偏愛 Zustand 這種輕量級 Hook？評論區(qū)交流你的調(diào)試心得，我們一起避坑。 游戲?qū)毑貫硨崙?zhàn)：3個技巧搞定報錯，附完整示例
游戲?qū)毑貫硨崙?zhàn)：3個技巧搞定報錯，附完整示例
盯著屏幕滿屏紅色的 StackTrace，心里是不是咯噔一下？別慌，這種“報錯一堆看不懂”的絕望感，每個寫代碼的人都經(jīng)歷過。
特別是當(dāng)你剛接手一個類似“游戲?qū)毑貫场边@種模擬經(jīng)營類的小項目，邏輯看似簡單，但一旦涉及狀態(tài)同步、資源消耗和事件觸發(fā)，崩潰來得猝不及防。今天不聊虛的，直接給出一套可復(fù)現(xiàn)的完整示例，幫你從底層理清邏輯，徹底告別“看天書”式的調(diào)試。
我們不做那種只有“Hello World”的演示，而是直接搭建一個具備核心玩法閉環(huán)的微型項目。
項目目標(biāo)：構(gòu)建最小可行寶藏灣
很多新手一上來就想做大，結(jié)果死在需求蔓延里。我們這次的目標(biāo)很明確：做一個“極簡版游戲?qū)毑貫场薄?核心功能只有三個：資源采集：玩家點擊或定時自動獲取金幣和木材。
商店購買：用金幣升級采集效率或購買裝飾物。
狀態(tài)持久化：刷新頁面后，數(shù)據(jù)不丟失。為什么選這個？因為它涵蓋了前端開發(fā)中最頭疼的三塊硬骨頭：狀態(tài)管理、異步操作和本地存儲。搞定它，你的調(diào)試能力能提升一個臺階。
目錄結(jié)構(gòu)：清晰勝于聰明
工程化不是堆砌配置，而是讓代碼“找得到”。以下是我們推薦的標(biāo)準(zhǔn)目錄結(jié)構(gòu)，直接復(fù)制就能用：
game-treasure-bay/
├── public/
│ └── index.html
├── src/
│ ├── assets/ # 靜態(tài)資源
│ ├── components/ # 組件
│ │ ├── HUD.jsx # 頂部狀態(tài)欄
│ │ ├── Shop.jsx # 商店面板
│ │ └── Map.jsx # 地圖區(qū)域
│ ├── core/ # 核心邏輯（純函數(shù)，無UI依賴）
│ │ ├── gameEngine.js # 游戲引擎主邏輯
│ │ └── constants.js # 常量定義
│ ├── store/ # 狀態(tài)管理
│ │ └── useGameStore.js # 自定義 Hook
│ ├── App.jsx
│ └── main.jsx
├── package.json
└── vite.config.js關(guān)鍵點：注意 core 目錄。我們將所有純邏輯代碼剝離出來，不依賴 React。這樣做的好處是，當(dāng) StackTrace 指向邏輯錯誤時，你可以直接在控制臺里單元測試這段邏輯，而不用啟動整個 UI。
核心代碼實現(xiàn)：逐行拆解避坑點
這是本文的重點。我們將使用 React + Vite + Zustand（一個輕量級狀態(tài)庫，比 Redux 簡單得多）。
1. 定義常量與初始狀態(tài)
很多時候，報錯源于“魔法數(shù)字”。比如為什么金幣扣了 100 但沒變？因為你在兩個地方都寫了 100，改了一個忘了另一個。
// src/core/constants.js
export const RESOURCE_TYPES = {COIN: 'coin',WOOD: 'wood'
};export const UPGRADES = {'MINER_LEVEL_1': {id: 'MINER_LEVEL_1',name: '初級礦工',cost: { coin: 50, wood: 0 },effect: { coinPerSec: 1 },desc: '每秒自動產(chǎn)出1金幣'},'DECOR_TREE': {id: 'DECOR_TREE',name: '裝飾樹',cost: { coin: 100, wood: 10 },effect: { score: 10 },desc: '增加10分，純裝飾'}
};2. 核心游戲引擎（純邏輯）
這里最容易出 Bug 的地方是并發(fā)更新。如果你直接在組件里寫 setCoin(coin + 1)，在快速點擊時，React 的批量更新機制可能導(dǎo)致數(shù)值不準(zhǔn)。
// src/core/gameEngine.js/*** 計算購買后的新狀態(tài)* 純函數(shù)：輸入舊狀態(tài)，返回新狀態(tài)* @param {Object} state - 當(dāng)前游戲狀態(tài)* @param {String} upgradeId - 要購買的升級ID* @returns {Object} - 新狀態(tài)或錯誤對象*/
export function processPurchase(state, upgradeId) {const upgrade = UPGRADES[upgradeId];// 防御性編程：檢查升級是否存在if (!upgrade) {return { error: 'Upgrade not found', state };}// 檢查資源是否足夠const canAfford = state.resources.coin = upgrade.cost.coin state.resources.wood = upgrade.cost.wood;if (!canAfford) {return { error: 'Insufficient resources', state };}// 計算新資源const newResources = {coin: state.resources.coin - upgrade.cost.coin,wood: state.resources.wood - upgrade.cost.wood};// 更新升級列表const newUpgrades = [...state.upgrades];const existingIndex = newUpgrades.findIndex(u = u.id === upgradeId);if (existingIndex -1) {// 如果是重復(fù)購買，增加等級（簡化邏輯，實際項目可能更復(fù)雜）newUpgrades[existingIndex].level += 1;} else {newUpgrades.push({ ...upgrade, level: 1 });}return {error: null,state: {...state,resources: newResources,upgrades: newUpgrades}};
}為什么這樣寫？
看注釋里的 return { error: null, state: ... }。我們將“成功”和“失敗”封裝在同一個返回結(jié)構(gòu)中。在 UI 層，你只需要判斷 result.error 是否存在。這比拋出異常（Throw Exception）更適合前端這種高頻交互場景，避免了 try-catch 滿天飛導(dǎo)致的 StackTrace 混亂。
3. 狀態(tài)管理 Hook
使用 Zustand 管理狀態(tài)，它比 Redux 代碼量少 80%。
// src/store/useGameStore.js
import { create } from 'zustand';
import { persist } from 'zustand/middleware';
import { processPurchase } from '../core/gameEngine';
import { UPGRADES } from '../core/constants';const useGameStore = create(persist((set, get) = ({// 初始狀態(tài)resources: { coin: 100, wood: 10 },upgrades: [],score: 0,// ActionsaddResource: (type, amount) = set((state) = ({resources: {...state.resources,[type]: state.resources[type] + amount}})),buyUpgrade: (upgradeId) = {const state = get();const result = processPurchase(state, upgradeId);// 關(guān)鍵：只在成功時更新狀態(tài)if (!result.error) {set(result.state);} else {console.warn('Purchase failed:', result.error);// 這里可以觸發(fā) UI 提示，比如震動或紅字}},// 定時任務(wù)：每秒執(zhí)行tick: () = {const state = get();let coinGain = 0;// 計算所有礦工的產(chǎn)出state.upgrades.forEach(u = {if (u.effect u.effect.coinPerSec) {coinGain += u.effect.coinPerSec * u.level;}if (u.effect u.effect.score) {// 分數(shù)增加邏輯}});if (coinGain 0) {get().addResource('coin', coinGain);}}}),{name: 'treasure-bay-storage', // 本地存儲的 Keypartialize: (state) = ({ resources: state.resources, upgrades: state.upgrades })})
);export default useGameStore;避坑指南：
注意 persist 中間件的 partialize。不要把所有狀態(tài)都存進 LocalStorage！比如 isLoading、errorMessages 這些臨時狀態(tài)，存進去會導(dǎo)致刷新后頁面卡死或顯示舊錯誤。只存核心數(shù)據(jù)。
運行與測試：復(fù)現(xiàn)并解決 StackTrace
現(xiàn)在，讓我們模擬一個真實的報錯場景。
假設(shè)你在 Shop.jsx 中寫了這樣一段代碼：
// 錯誤示例：直接在渲染期間修改狀態(tài)
const Shop = () = {const { buyUpgrade, resources } = useGameStore();const handleBuy = (id) = {// 錯誤：如果資源不足，processPurchase 返回 error，但下面這行代碼依然執(zhí)行了 set// 導(dǎo)致 React 警告: Cannot update a component while rendering a different componentbuyUpgrade(id);}return (div{Object.values(UPGRADES).map(upg = (button key={upg.id} onClick={() = handleBuy(upg.id)}disabled={resources.coin upg.cost.coin}{upg.name}/button))}/div);
}報錯現(xiàn)象：
點擊按鈕后，控制臺出現(xiàn) Maximum update depth exceeded 或狀態(tài)無限循環(huán)。
排查步驟：打開 Chrome DevTools，查看 Components 面板。
發(fā)現(xiàn) Shop 組件在不斷重渲染。
檢查 useGameStore 的 buyUpgrade。
發(fā)現(xiàn) processPurchase 是純函數(shù)，沒問題。
問題出在 disabled 邏輯與 buyUpgrade 的異步性上？不，Zustand 是同步的。
再仔細看代碼：disabled 只是 UI 層面禁用，但 JS 邏輯上，如果用戶通過開發(fā)者工具強制觸發(fā)，或者資源計算有浮點誤差，buyUpgrade 依然會被調(diào)用。正確解法：
在 buyUpgrade 內(nèi)部做二次校驗，并在 UI 層增加“冷卻時間”或視覺反饋，防止快速連擊。
// 修正后的 buyUpgrade
buyUpgrade: (upgradeId) = {const state = get();const upgrade = UPGRADES[upgradeId];// 雙重校驗if (state.resources.coin upgrade.cost.coin) {// 觸發(fā) UI 錯誤提示，但不更新 store 狀態(tài)set({ error: 'Coin not enough' }); setTimeout(() = set({ error: null }), 2000);return;}const result = processPurchase(state, upgradeId);if (!result.error) {set(result.state);}
}通過這種分層校驗（UI 層 + Store 層 + 純邏輯層），你將 StackTrace 的長度縮短了一半，因為錯誤會在最早發(fā)生的層被攔截。
優(yōu)化擴展：從玩具到產(chǎn)品
當(dāng)基礎(chǔ)功能跑通后，如何讓它更像一個“產(chǎn)品”？性能優(yōu)化：使用 React.memo 包裹 Shop 和 HUD 組件，避免不必要的重渲染。
如果 tick 頻率變高（比如每 100ms 一次），將 tick 邏輯移入 requestAnimationFrame，而不是 setInterval，以保證幀率穩(wěn)定。模塊化拆分：將 gameEngine.js 拆分為 resourceEngine.js、upgradeEngine.js、saveEngine.js。
每個引擎負責(zé)單一職責(zé)，方便單獨測試。引入真實開源參考：如果你想知道工業(yè)級游戲狀態(tài)管理怎么做，推薦研究 GitHub 上的 PixiJS 或 Phaser 生態(tài)中的狀態(tài)管理模式。
特別是 Zustand 的官方文檔（GitHub 倉庫：stateful/zustand），其中關(guān)于“中間件”和“持久化”的章節(jié)，比任何博客教程都更權(quán)威。直接閱讀源碼，你會發(fā)現(xiàn)它對 partialize 的處理比很多第三方庫更優(yōu)雅。單元測試：使用 Vitest 對 core/gameEngine.js 編寫測試。
測試用例：資源不足時，狀態(tài)不變。
購買成功后，資源扣減正確。
重復(fù)購買同一升級，等級增加。// test/gameEngine.test.js
import { describe, it, expect } from 'vitest';
import { processPurchase } from '../src/core/gameEngine';describe('processPurchase', () = {it('should deduct resources on successful purchase', () = {const initialState = {resources: { coin: 100, wood: 10 },upgrades: []};const result = processPurchase(initialState, 'MINER_LEVEL_1');expect(result.error).toBeNull();expect(result.state.resources.coin).toBe(50);expect(result.state.upgrades.length).toBe(1);});it('should not change state if resources insufficient', () = {const initialState = {resources: { coin: 10, wood: 0 },upgrades: []};const result = processPurchase(initialState, 'MINER_LEVEL_1');expect(result.error).toBe('Insufficient resources');expect(result.state).toBe(initialState); // 引用相等，未修改});
});小結(jié)：調(diào)試是一種肌肉記憶
回顧整個“游戲?qū)毑貫场钡拇罱ㄟ^程，核心不在于代碼有多炫，而在于邊界是否清晰。純邏輯層（core）：只處理數(shù)據(jù)，不碰 DOM，不碰 Store API。
狀態(tài)層（store）：只負責(zé)數(shù)據(jù)的存儲和同步，不包含業(yè)務(wù)判斷。
UI 層（components）：只負責(zé)展示和交互觸發(fā)。當(dāng) StackTrace 出現(xiàn)時，你可以根據(jù)堆棧信息快速定位是哪一層出了問題：如果是 undefined is not a function，大概率是純邏輯層傳參錯誤。
如果是 Invalid hook call，大概率是 UI 層組件結(jié)構(gòu)混亂。
如果是 State update loop，大概率是 Store 層在渲染期間觸發(fā)了更新。這種分層思維，比背下某個框架的 API 更重要。它讓你在面對任何技術(shù)棧時，都能迅速建立心智模型，從“猜 Bug”變成“定位 Bug”。
你更常用哪種寫法？是習(xí)慣用 Redux 這種重型方案，還是更偏愛 Zustand 這種輕量級 Hook？評論區(qū)交流你的調(diào)試心得，我們一起避坑。