1. 这不是又一个“状态管理教程”，而是我在三个 RN 项目里踩完坑后重写的 MobX 实战手册
MobX 和 React Native 的组合，听起来很顺——响应式、自动追踪、写法简洁。但真正把它用稳、用透、用到上线不翻车，远不是npm install mobx mobx-react-lite然后照抄官网 demo 就能搞定的。我带团队做过三个中型 RN App：一个跨境物流调度系统（iOS/Android 双端，日活 8w+），一个医疗问诊轻应用（离线优先，强依赖本地状态同步），还有一个教育类互动课件平台（大量动画 + 高频状态切换）。这三个项目全量采用 MobX v6+ + React Native 0.72+ 技术栈，从早期用observer包裹整个Screen导致重绘失控，到后来把useLocalObservable和makeAutoObservable拆解到组件粒度，再到最终在SafeAreaProvider下精准控制状态更新边界——每一步都是拿线上崩溃率和用户卡顿反馈换来的经验。
你搜“MobX React Native”看到的大多是“5分钟上手”“告别 Redux”这类标题党内容，它们没告诉你：RN 的FlatList渲染机制和 MobX 的 autorun 执行时机存在天然错位；SafeAreaProvider不只是个 UI 组件，它会劫持useSafeAreaInsets的订阅链路，而这个链路一旦被 MobX 的reaction错误包裹，就会引发无限循环；更没人提@observable.ref和@observable.shallow在 RN 的Animated.Value或Reanimated节点上的行为差异——这些细节，才是决定你项目是“跑得动”还是“跑得稳”的分水岭。这篇文章不讲概念，不列 API，只说我在真实项目里怎么选、怎么配、怎么调、怎么防。如果你正准备用 MobX 做 RN 新项目，或者正在重构一个卡顿严重的旧项目，这篇就是你该打印出来贴在显示器边上的操作清单。
2. 为什么是 MobX？而不是 Zustand、Jotai，甚至不是 Redux Toolkit？
2.1 核心判断逻辑：状态变更频率 × 视图响应精度 × 团队认知成本
很多人选状态库，第一反应是“哪个最火”或“哪个配置最简单”。但在 RN 场景下，这三者必须拉到同一张表里算账。我用一个真实对比表格说明：
| 维度 | MobX v6+ | Zustand v4+ | Redux Toolkit v2+ |
|---|---|---|---|
| 高频状态变更（如拖拽、滑动、实时音视频） | ✅ 自动最小化重绘，@action内部批量合并，实测 60fps 下 CPU 占用比 Zustand 低 18%（A12 芯片真机数据） | ⚠️set()默认浅合并，高频调用易触发多余 re-render；需手动useCallback+shallow优化，代码侵入性强 | ❌dispatch+createSlice天然函数调用开销，即使useSelector加shallowEqual，在FlatList子项中仍易因引用变化导致整列重绘 |
| 视图响应精度（如局部动画、条件渲染区块） | ✅observer组件内自动建立细粒度依赖图，改一个@observable字段，只更新用到它的 JSX 片段；配合useLocalObservable可实现组件级状态隔离 | ✅useStore+selector也能做到，但 selector 函数需严格纯函数，RN 中常因props引用变化导致 selector 重执行 | ⚠️useSelector依赖state引用，createEntityAdapter等工具虽好，但对FlatList的data数组做增删时，state.items引用必变，除非用skip选项，否则无法避免重绘 |
| 团队上手成本（3人以上协作） | ⚠️ 需理解observable/action/computed语义，但 RN 开发者普遍熟悉 class component 生命周期，@action类比componentDidUpdate很自然 | ✅createStore语法极简，但多人协作时易出现set(state => ({...state, x: y}))和set({x: y})混用，导致不可预测的引用问题 | ❌immer的produce虽好，但新手常写state.x = y忘加return state，或在extraReducers里直接push数组，引发静默错误 |
提示：我们最终放弃 Zustand 的关键原因，是在医疗项目中遇到一个致命场景：患者填写表单时，后台需实时校验字段并返回错误提示。Zustand 的 store 是单例，多个表单页共用同一 store 实例，
set()调用会广播给所有监听者。我们不得不为每个页面加useEffect清理subscribe，而 RN 的useFocusEffect在页面切出时有延迟，导致切页瞬间校验结果错乱。MobX 的useLocalObservable天然支持组件实例级状态，observer组件卸载时自动清理 reaction，这个问题根本不存在。
2.2 MobX 在 RN 生态中的不可替代性：与SafeAreaProvider的深度协同
React Native 0.71+ 强制要求使用SafeAreaProvider，而它的核心能力是通过SafeAreaContext向子组件注入insets（顶部/底部安全区偏移值）。很多教程教你这样用：
const MyScreen = () => { const insets = useSafeAreaInsets(); return <View style={{ paddingTop: insets.top }} />; };但问题来了：useSafeAreaInsets返回的是一个reactive object（内部基于useContext+useMemo实现），它的变化会触发组件重渲染。如果这个组件同时是 MobXobserver，且你在@action中修改了其他状态，就可能形成隐式依赖闭环。
我们在线上发现过一个典型 case：在物流调度页，用户点击“开始导航”按钮，触发@action startNavigation()，该 action 内部既更新了isNavigating: true，又调用了mapRef.animateToRegion()。而该页面的SafeAreaProvider正好在地图组件上方嵌套，insets变化（比如横竖屏切换）会触发observer组件重绘，重绘时又重新执行startNavigation()—— 因为@action被错误地放在了 render 函数体内（新手常见错误）。MobX 的解决方案非常干净：用useLocalObservable创建仅与当前组件生命周期绑定的状态对象，并将insets作为computed属性接入：
const MyScreen = observer(() => { const localStore = useLocalObservable(() => ({ isNavigating: false, // computed 属性，自动响应 insets 变化，但不触发自身重绘 get safeTop() { return useSafeAreaInsets().top; }, startNavigation() { this.isNavigating = true; // 此处调用 map 动画，不会因 insets 变化而重复执行 } })); return ( <View style={{ paddingTop: localStore.safeTop }}> <Button onPress={localStore.startNavigation} /> </View> ); });这个模式的关键在于：useSafeAreaInsets()调用被移到computed内部，MobX 的computed是惰性求值的，只有当safeTop被 JSX 使用时才执行，且其依赖（insets）变化时，MobX 会精确通知style属性更新，而非整个组件。这是 Zustand 或 Redux 无法原生支持的精细控制力。
2.3 为什么不是 MobX v5？v6 的makeAutoObservable是 RN 开发者的救命稻草
MobX v5 要求显式声明observable、action、computed，代码像这样：
class Store { @observable count = 0; @action increment = () => { this.count++ }; @computed get doubleCount() { return this.count * 2; } }在 RN 中，这种写法有两个硬伤：一是@action箭头函数在 class 中无法被 MobX 正确绑定this（尤其在FlatList的renderItem中传参调用时）；二是@observable字段必须提前声明，而 RN 组件常需动态生成状态（如表单字段根据后端 schema 渲染），v5 的extendObservable已废弃，v6 的makeAutoObservable则完美解决：
// RN 表单动态字段场景 const createFormStore = (schema: FieldSchema[]) => { const store = { fields: {} as Record<string, string>, errors: {} as Record<string, string>, // 动态初始化所有字段 initFields() { schema.forEach(field => { this.fields[field.key] = field.defaultValue || ''; this.errors[field.key] = ''; }); }, updateField(key: string, value: string) { this.fields[key] = value; this.validateField(key); }, validateField(key: string) { // ...校验逻辑 this.errors[key] = isValid ? '' : '格式错误'; } }; // 一行代码，自动将所有方法标记为 action，所有字段为 observable makeAutoObservable(store); store.initFields(); // 立即初始化 return store; };makeAutoObservable的底层是Proxy+defineProperty，它能在运行时动态拦截属性访问，这对 RN 的动态 UI 构建（如 TabBar 标签数由后端配置决定）至关重要。我们曾用 v5 实现类似功能，不得不写一堆for...in循环 +extendObservable，代码臃肿且易出错。v6 的makeAutoObservable让动态状态管理回归“声明即使用”的直觉，这才是 RN 开发者需要的简化。
3. 核心细节解析：从SafeAreaProvider到observer组件的完整链路
3.1SafeAreaProvider的真实工作原理：它不只是个 Context Provider
很多 RN 开发者以为SafeAreaProvider就是个简单的Context.Provider，把insets对象塞进去完事。实际上，它的核心是SafeAreaContext，而这个 context 的 value 是一个reactive object，其内部结构如下：
interface SafeAreaInsets { top: number; right: number; bottom: number; left: number; frame: { x: number; y: number; width: number; height: number }; // iOS 16+ 新增 } // SafeAreaContext 的 value 类型 type SafeAreaContextValue = { insets: SafeAreaInsets; // 关键：这是一个可被 MobX 追踪的 reactive 对象 // 它的 getter 方法被 Proxy 拦截，每次访问都会注册依赖 getInset: (side: 'top' | 'bottom' | 'left' | 'right') => number; };这意味着，当你调用useSafeAreaInsets().top，MobX 的reaction会自动记录这个访问，并在insets.top变化时触发更新。但这里有个陷阱：useSafeAreaInsets是一个 hook，不能在computed外部直接调用。如果你这样写：
// ❌ 错误：hook 调用在 computed 外部，MobX 无法追踪 const MyComponent = observer(() => { const insets = useSafeAreaInsets(); // 这里调用，但不在 computed 内 const store = useLocalObservable(() => ({ get paddingTop() { return insets.top; // 依赖外部变量，MobX 不知道要追踪谁 } })); });MobX 会认为paddingTop依赖的是insets这个常量引用，而非insets.top的值，导致insets.top变化时paddingTop不更新。正确做法是把useSafeAreaInsets()调用封装进computed：
const MyComponent = observer(() => { const store = useLocalObservable(() => ({ // ✅ 正确：computed 内部调用 hook，MobX 自动建立依赖链 get paddingTop() { return useSafeAreaInsets().top; } })); return <View style={{ paddingTop: store.paddingTop }} />; });注意：
useSafeAreaInsets()在computed内调用是安全的，因为 MobX 的computed执行环境允许 hook 调用（MobX v6+ 已适配 React Concurrent Mode）。但切记不要在@action或普通函数中调用，那会违反 React Hook 规则。
3.2observer组件的渲染边界：为什么你的 FlatList 还在疯狂重绘？
observer的核心能力是“自动最小化重绘”，但它不是魔法。它的生效前提是：组件的 JSX 中，所有用到的@observable字段，都必须来自同一个 MobX store 实例，且该实例未被意外解构。
我们在线上物流项目中遇到过一个经典问题：FlatList的data来自store.orders，但renderItem中却这样写：
// ❌ 错误：解构破坏了 observable 代理 const renderItem = ({ item }) => { const { id, status } = item; // item 是 observable 对象，解构后 id/status 变成普通值 return ( <OrderCard id={id} // 传入普通字符串，MobX 无法追踪 status={status} // 传入普通字符串，状态变化不触发重绘 onUpdateStatus={handleUpdate} /> ); }; <FlatList data={store.orders} renderItem={renderItem} />;结果是：store.orders[0].status改变时，OrderCard完全不更新。因为id和status在解构那一刻就脱离了 MobX 的代理链。正确做法是保持 observable 对象的完整性，让子组件自己去读取字段：
// ✅ 正确：item 保持 observable 引用，子组件用 observer 包裹 const OrderCard = observer(({ item }: { item: Order }) => { return ( <View> <Text>ID: {item.id}</Text> {/* MobX 自动追踪 item.id */} <Text>Status: {item.status}</Text> {/* MobX 自动追踪 item.status */} <Button onPress={() => item.updateStatus('shipped')} /> </View> ); }); const renderItem = ({ item }) => ( <OrderCard item={item} /> // 传入整个 observable 对象 ); <FlatList data={store.orders} renderItem={renderItem} />;这个模式的关键在于：OrderCard必须是observer，且item的类型Order必须是makeAutoObservable创建的类实例（或observable.object创建的对象）。这样，item.id的每次访问都会被 MobX 记录为依赖，item.updateStatus()修改id时，OrderCard才能精准重绘。
3.3@observable.refvs@observable.shallow：处理 RN 复杂对象的生死线
RN 中大量使用第三方库对象：Animated.Value、Reanimated.SharedValue、MapView的region对象、Camera的onBarCodeScanned返回的Barcode对象。这些对象要么是 class 实例，要么是复杂嵌套结构，MobX 默认的@observable会尝试递归转换它们，导致崩溃或内存泄漏。
@observable.ref：告诉 MobX “别碰这个值，就当它是不可变的原始值”。适用于Animated.Value这类内部有复杂 setter/getter 的对象。MobX 只追踪引用是否变化，不深入其内部。@observable.shallow：告诉 MobX “只转换第一层属性，不要递归”。适用于region: { latitude, longitude, latitudeDelta }这种扁平对象，你希望region.latitude变化时触发更新，但不想 MobX 去管region.latitude.toString()这种衍生操作。
我们医疗项目中有一个实时定位模块，需要监听MapView的onRegionChangeComplete事件并更新 store：
// ❌ 错误：默认 @observable 会尝试转换 MapView 的 region 对象，导致 crash class LocationStore { @observable region = { latitude: 0, longitude: 0, latitudeDelta: 0.01 }; onRegionChange(region: Region) { this.region = region; // region 是 MapView 的 native 对象，MobX 无法安全转换 } } // ✅ 正确：用 @observable.shallow 处理扁平 region class LocationStore { @observable.shallow region = { latitude: 0, longitude: 0, latitudeDelta: 0.01 }; onRegionChange(region: Region) { // 浅拷贝，只更新第一层属性，MobX 安全追踪 this.region = { ...region }; } } // ✅ 正确：用 @observable.ref 处理 Animated.Value class AnimationStore { @observable.ref animatedValue = new Animated.Value(0); startAnimation() { Animated.timing(this.animatedValue, { toValue: 1, duration: 300, useNativeDriver: true, }).start(); } }实操心得：
@observable.ref是 RN 项目中最常被低估的装饰器。我们曾用@observable直接包裹Reanimated.SharedValue<number>，结果在 Android 上频繁触发JNI ERROR (app bug): local reference table overflow。换成@observable.ref后，问题消失。记住口诀：“第三方库对象，一律ref；扁平配置对象，优先shallow”。
4. 实操过程：从零搭建一个稳定、可维护的 MobX + RN 项目
4.1 初始化：mobx+mobx-react-lite+@babel/plugin-proposal-decorators的黄金组合
RN 0.72+ 默认使用 Metro，不支持@decorator语法（如@observable），必须手动配置 Babel。这不是可选项，是必选项。步骤如下：
- 安装核心包：
npm install mobx mobx-react-lite # 或 yarn add mobx mobx-react-lite- 安装 Babel 插件（关键！）：
npm install --save-dev @babel/plugin-proposal-decorators- 修改
babel.config.js：
module.exports = { presets: ['module:metro-react-native-babel-preset'], plugins: [ // 必须放在 presets 之后，且启用 legacy 模式 ['@babel/plugin-proposal-decorators', { legacy: true }], // 可选：如果要用 @observer 装饰器（不推荐，用函数调用更清晰） // ['@babel/plugin-proposal-class-properties', { loose: true }] ], };注意：
legacy: true是必须的。MobX v6 的装饰器设计基于 TC39 Stage 2 提案，而 Metro 的默认 preset 只支持 Stage 3。不加legacy: true，@observable会被忽略，状态完全不响应。
- 验证配置：创建一个测试 store：
// stores/testStore.ts import { makeAutoObservable } from 'mobx'; class TestStore { count = 0; constructor() { makeAutoObservable(this); // 推荐，比装饰器更可控 } increment() { this.count++; } } export const testStore = new TestStore();在组件中使用：
import { observer } from 'mobx-react-lite'; import { testStore } from './stores/testStore'; const TestComponent = observer(() => { return ( <View> <Text>Count: {testStore.count}</Text> <Button title="Add" onPress={testStore.increment} /> </View> ); });如果点击按钮count正常更新，说明配置成功。如果没反应，90% 是 Babel 插件没生效或legacy: true缺失。
4.2SafeAreaProvider的正确集成位置：根组件层级的三重保障
SafeAreaProvider必须包裹整个 RN 应用，且要确保它在 MobX 的Provider（如果有）之上。标准结构如下：
// App.tsx import { SafeAreaProvider } from 'react-native-safe-area-context'; import { NavigationContainer } from '@react-navigation/native'; import { Provider as MobXProvider } from 'mobx-react'; import { myRootStore } from './stores/rootStore'; // ✅ 正确顺序：SafeAreaProvider 最外层，确保所有子组件都能访问 insets const App = () => { return ( <SafeAreaProvider> {/* 第一层：安全区 */} <MobXProvider store={myRootStore}> {/* 第二层：MobX store */} <NavigationContainer> {/* 第三层：路由 */} <MainStack /> </NavigationContainer> </MobXProvider> </SafeAreaProvider> ); }; export default App;为什么这个顺序不能颠倒？因为SafeAreaProvider的insets是通过Context注入的，如果MobXProvider在外层，SafeAreaProvider的Context就无法被 MobX 组件捕获。我们曾把SafeAreaProvider放在NavigationContainer内部，结果TabBar的safeAreaInsets.bottom在某些安卓机型上始终为 0，原因是TabBar组件被NavigationContainer的Context隔离了。
提示：
SafeAreaProvider的initialSafeAreaInsets属性可以预设初始值，避免首次渲染时布局跳动。我们设置为{ top: 0, right: 0, bottom: 0, left: 0 }，等insets真实计算完成再更新，UI 更平滑。
4.3useLocalObservable的实战模板：每个屏幕一个独立状态域
useLocalObservable是 RN 中最被低估的 Hook。它创建的状态对象与组件生命周期完全绑定，组件卸载时自动清理所有 reaction，彻底杜绝内存泄漏。我们为每个Screen组件定义标准模板：
// screens/HomeScreen.tsx import { observer, useLocalObservable } from 'mobx-react-lite'; import { View, Text, Button } from 'react-native'; import { useSafeAreaInsets } from 'react-native-safe-area-context'; interface HomeStore { isLoading: boolean; error: string | null; data: string[]; loadData(): Promise<void>; clearError(): void; } const HomeScreen = observer(() => { // ✅ 用 useLocalObservable 创建组件专属 store const store = useLocalObservable<HomeStore>(() => ({ isLoading: false, error: null, data: [], // computed 属性：安全区顶部偏移 get paddingTop() { return useSafeAreaInsets().top; }, // action 方法：加载数据 async loadData() { this.isLoading = true; this.error = null; try { // 模拟 API 调用 const res = await fetch('/api/home'); this.data = await res.json(); } catch (err) { this.error = err instanceof Error ? err.message : '未知错误'; } finally { this.isLoading = false; } }, // action 方法：清除错误 clearError() { this.error = null; } })); // 组件挂载时自动加载 useEffect(() => { store.loadData(); }, []); return ( <View style={{ flex: 1, paddingTop: store.paddingTop }}> {store.isLoading && <Text>加载中...</Text>} {store.error && ( <View> <Text>{store.error}</Text> <Button title="重试" onPress={store.loadData} /> </View> )} <FlatList data={store.data} keyExtractor={(item) => item} renderItem={({ item }) => <Text>{item}</Text>} /> </View> ); }); export default HomeScreen;这个模板的要点：
useLocalObservable的泛型<HomeStore>明确类型，TypeScript 友好；get paddingTop()是computed，自动响应SafeAreaInsets变化；loadData()是async action，MobX 会自动处理 Promise 状态（isLoading更新无需手动 try/catch）；useEffect中调用store.loadData()，组件卸载时store自动销毁，reaction 全部清理。
4.4FlatList性能优化：getItemLayout+PureComponent+observer三件套
FlatList是 RN 性能杀手，MobX 能帮它续命。我们总结出一套“三件套”组合拳：
getItemLayout预计算布局：避免滚动时反复测量，强制开启removeClippedSubviews。PureComponent包裹renderItem：防止父组件重绘时子项无谓刷新。observer包裹renderItem：让子项只响应自身状态变化。
// components/OrderItem.tsx import { observer, useLocalObservable } from 'mobx-react-lite'; import { View, Text, TouchableOpacity } from 'react-native'; // ✅ observer 包裹，只响应自身状态 const OrderItem = observer(({ order }: { order: Order }) => { const store = useLocalObservable(() => ({ isExpanded: false, toggleExpand() { this.isExpanded = !this.isExpanded; } })); return ( <TouchableOpacity onPress={store.toggleExpand}> <View> <Text>订单号: {order.id}</Text> <Text>状态: {order.status}</Text> {store.isExpanded && ( <View> <Text>收货地址: {order.address}</Text> <Text>商品列表: {order.items.join(', ')}</Text> </View> )} </View> </TouchableOpacity> ); }); // ✅ PureComponent 包裹，防止父组件重绘 const PureOrderItem = React.memo(OrderItem); // 在 FlatList 中使用 <FlatList data={store.orders} keyExtractor={(item) => item.id} // ✅ getItemLayout 预计算高度 getItemLayout={(_, index) => ({ length: 80, // 固定高度 offset: 80 * index, index, })} // ✅ 使用 PureComponent renderItem={({ item }) => <PureOrderItem order={item} />} // ✅ 强制开启剪裁 removeClippedSubviews={true} />实测数据：在 200 条订单的列表中，未优化时滚动帧率约 32fps；启用三件套后稳定 58fps（iPhone 12 Pro）。关键在于
getItemLayout让FlatList跳过 layout 测量，PureComponent阻断父级重绘传播，observer确保子项只在order.status或isExpanded变化时更新。
5. 常见问题与排查技巧实录：那些让你凌晨三点还在看 Logcat 的 Bug
5.1 问题速查表：高频崩溃与卡顿场景及解决方案
| 现象 | 可能原因 | 排查命令/技巧 | 解决方案 |
|---|---|---|---|
组件不更新，@action调用后 UI 静止 | observer未包裹组件；或@action写在非 store 类中 | console.log(mobx.isObservable(store.field))检查字段是否被代理 | 确保组件用observer()包裹；@action必须在makeAutoObservable的类或useLocalObservable的对象中定义 |
SafeAreaProvider的insets始终为 0 | SafeAreaProvider未包裹根组件；或useSafeAreaInsets()在computed外调用 | console.log(useSafeAreaInsets())在根组件中打印 | 检查App.tsx结构，确保SafeAreaProvider是最外层；insets访问必须在computed或observer组件内 |
FlatList滚动卡顿，CPU 占用飙升 | renderItem中解构了item；或data数组被@observable深度转换 | console.log(store.orders)查看数组是否为ObservableArray | 用@observable.shallow声明data字段；renderItem传入完整item，子组件用observer自行读取 |
| 内存泄漏，应用后台运行后崩溃 | useLocalObservable创建的 store 未随组件卸载；或reaction未手动清理 | adb shell dumpsys meminfo your.package.name查看WebView或Observer实例数 | 严格使用useLocalObservable；避免在useEffect中创建未清理的reaction（useLocalObservable自动清理） |
Animated.Value修改后不触发重绘 | 用@observable直接包裹Animated.Value，导致代理失败 | console.log(mobx.isObservable(store.animatedValue))返回false | 改用@observable.ref装饰Animated.Value字段 |
5.2 独家避坑技巧：三个让我少熬 20 个夜的真实经验
技巧一：用mobx-react-lite的useObserver替代observer高阶组件，规避 HOC 嵌套陷阱
很多教程教你在组件外层套observer(MyComponent)，这在简单场景没问题，但遇到React.memo+observer嵌套时，会因memo的props浅比较失败，导致observer失效。我们改用useObserverHook：
// ❌ 传统 observer HOC，与 memo 冲突 const MyComponent = memo(({ data }) => { return <Text>{data}</Text>; }); export default observer(MyComponent); // ✅ useObserver Hook，无嵌套问题 const MyComponent = memo(({ data }) => { return useObserver(() => ( <Text>{data}</Text> )); });useObserver的优势是：它在组件内部创建一个微型observer，不改变组件签名，与memo、forwardRef完全兼容。我们在教育课件项目中，所有动画组件都用此模式，彻底解决了FlatList子项因memo比较失败导致的重绘问题。
技巧二：@computed的缓存失效策略——用keepAlive: true防止高频计算
@computed默认是惰性求值，但某些场景（如FlatList的getItemLayout）需要高频访问，反复计算@computed会浪费性能。MobX 提供keepAlive: true选项：
class ListStore { @observable items = []; // ✅ keepAlive: true，计算结果缓存，直到依赖变化 @computed({ keepAlive: true }) get totalHeight() { return this.items.reduce((sum, item) => sum + item.height, 0); } }我们物流项目中，totalHeight被FlatList的scrollToEnd方法频繁调用，开启keepAlive后，CPU 占用下降 12%。
技巧三：reaction的手动清理——useEffect中创建，必须return cleanup
虽然useLocalObservable自动清理，但有时你需要手动创建reaction（如监听AppState变化）：
// ❌ 错误：未清理 reaction，组件卸载后仍执行 useEffect(() => { reaction( () => AppState.currentState, (state) => { if (state === 'background') store.saveDraft(); } ); }, []); // ✅ 正确：reaction 返回 cleanup 函数，useEffect 自动调用 useEffect(() => { const disposer = reaction( () => AppState.currentState, (state) => { if (state === 'background') store.saveDraft(); } ); return disposer; // 关键！ }, []);MobX 的reaction返回一个disposer函数，useEffect的 cleanup 机制会自动调用它。漏掉这行，组件卸载后reaction仍在后台运行，store.saveDraft()可能访问已销毁的 store，引发崩溃。
5.3 线上监控：用mobx.spy捕获状态变更风暴
当线上用户反馈“点按钮没反应”或“页面卡死”，光看日志不够。我们用mobx.spy在开发环境注入监控：
// utils/mobxMonitor.ts import { spy } from 'mobx'; export const setupMobXMonitor = () => { spy((event) => { // 过滤出高频 action，如 1 秒内超过 5 次 if (event.type === 'action' && event.name.includes('update')) { const now = Date.now(); const lastTime = window.lastActionTime || 0; if (now - lastTime < 1000) { window.actionCount = (window.actionCount || 0) + 1; if (window.actionCount > 5) { console.warn('⚠️ 高频 action 风暴:', event); // 上报监控系统 reportToSentry('HighFrequencyAction', event); } } window.lastActionTime = now; } }); };在App.tsx中调用：
useEffect(() => { if (__DEV__) { setupMobXMonitor(); } }, []);这个监控帮我们揪出了一个隐藏 Bug：医疗
