React Native中子组件状态更新为何触发父组件FeedScreen重渲染？

核心原因排查： #

• 子组件的mutation方法间接更新了父组件状态
  你传给FeedCard的triggerJoinActivityMutation或triggerOptOutMutation方法，大概率是在FeedScreen中定义的，且方法内部存在更新父组件状态的逻辑（比如刷新活动列表、修改父组件里和活动状态绑定的变量）。调用这些mutation时，你同时更新了子组件的isApiInProgress，但真正触发父组件重渲染的是mutation里的父组件状态更新操作。注释setIsApiInProgress后，可能mutation的执行逻辑被间接阻断（比如条件判断跳过了mutation调用），所以父组件不再重渲染。

• 父组件传递的props引用不稳定，引发连锁重渲染
  如果FeedScreen渲染FeedCard时，传递的props（比如回调函数、配置对象）是每次渲染都重新创建的（比如直接写onPress={() => {...}}、style={{ padding: 10 }}），即便子组件用了React.memo，也可能因props引用变化触发子组件重渲染。如果父组件的某个状态依赖子组件回调的返回值，或者回调里不小心捕获并更新了父组件状态，就会反向触发父组件重渲染。

• 组件嵌套逻辑存在隐藏关联
  少数情况下，父组件和子组件的状态通过上下文（Context）或第三方状态管理工具绑定，子组件更新状态时，父组件因订阅了相同状态源而触发重渲染。

排查建议： #

1. 检查triggerJoinActivityMutation和triggerOptOutMutation的实现，确认内部是否调用了FeedScreen的setState或useState更新函数。
2. 给FeedCard包裹React.memo，用useCallback缓存传递的回调函数、useMemo缓存传递的对象/数组，避免props引用频繁变化。
3. 在FeedScreen和FeedCard的渲染逻辑里分别添加console.log，打印重渲染日志，确认触发顺序和关联关系。

内容的提问来源于stack exchange，提问作者amit gupta