WordPress Interactivity API为何需要Context？与State的区别及场景

核心区别 #

• 作用域本质：
  • State是全局命名空间下的状态容器，哪怕用lock: true创建私有State，它依然全局存在，生命周期和页面绑定，只有页面刷新才会销毁。
  • Context是组件树局部作用域的状态容器，生命周期和所属组件实例绑定：组件挂载时Context初始化，组件销毁时Context自动回收，不会在全局残留。
• 访问逻辑：
  • State通过store()注册的命名空间全局访问，不管组件在树的哪个位置，都能直接获取对应命名空间的State。
  • Context默认是组件树内部的局部状态，虽然可以通过getContext("namespace")跨组件树访问，但这是针对插件注册的根组件Context，本质还是和该插件的组件实例绑定，并非真正的全局状态。

Context的核心优势 #

• 自动生命周期管理：无需手动清理，组件销毁时Context自动回收，避免全局状态冗余。
• 组件实例状态隔离：同一页面中多个相同组件实例的Context相互独立，不会互相干扰（比如多个Tabs组件各自维护自己的激活项）。
• 简化组件间状态传递：嵌套较深的组件树中，不用通过层层props传递状态，子组件可以直接获取父组件或根组件的Context。
• 无全局命名污染：不需要为每个组件创建独立的私有State命名空间，减少全局命名冲突风险。

优先使用Context的场景 #

1. 可复用组件的内部状态：比如Tabs、Accordion、模态框这类组件，每个实例需要独立维护自己的状态（当前激活项、展开状态等），用Context可以避免全局State的命名冲突，且实例销毁后自动清理状态。
2. 组件树局部共享状态：比如某个页面区块内的多个子组件需要共享状态（比如表单的临时输入状态、筛选器的选中状态），这些状态不需要全局访问，用Context比私有State更轻量，且随区块组件销毁自动回收。
3. 避免props drilling：当组件嵌套层级较深，需要在子组件中访问父组件的状态时，用Context可以跳过中间组件的props传递，代码更简洁。
4. 插件级局部状态：开发插件时，若状态仅和插件渲染的组件树相关，用插件命名空间的Context比私有State更合适，状态会随插件组件的卸载而消失，不会残留全局状态。

适合用State的场景 #

• 当状态需要全局访问（比如用户登录状态、站点全局配置），或者需要在多个不相关的组件树间共享时，优先用State。
• 当状态需要持久化（比如通过localStorage同步），或者生命周期和页面一致时，用State更合适。

内容的提问来源于stack exchange，提问作者Byeongin Yoon