pinia 的 action 环境隔离核心在于构建干净“沙盒”，通过按需创建带唯一 id 的 store 实例、禁止跨 store 直接引用、显式注入依赖、合理使用 $onaction、规避异步中 this 污染及及时清理资源来保障多实例、多标签页等场景下的状态与副作用边界清晰。
Pinia 的 action 执行环境隔离，核心不是“让 action 彼此不干扰”，而是控制它所依赖的上下文、状态边界和副作用范围。 它解决的是多实例、多标签页、跨组件调用或第三方集成时，action 意外共享 state、loading、错误处理逻辑或 API 实例的问题。关键不在 action 本身，而在它运行时所处的“沙盒”是否干净。
按需创建独立 Store 实例
避免全局单例 store 被多个业务模块共用。尤其在多标签页、动态表单或可复用组件场景下：
- 使用
defineStore创建工厂函数，而非直接导出 store 实例 - 每个标签页/模块调用时传入唯一 ID 或配置，生成专属 store
- 配合
pinia.unmountStore(id)或手动清理，确保卸载时释放资源（如未完成请求、定时器）
例如：const tabStore = useTabStore(`order-${id}`)，state 和 actions 都只作用于该 tab 上下文。
禁止跨 store 直接引用，改用显式注入
当一个 action 需要调用其他 store 的能力（如用户权限校验、API client），不要在 action 内部 import { useUserStore } 并直接调用 —— 这会绑定到默认 pinia 实例，破坏隔离性。
- 在父级组件或入口层，通过
provide/inject向子组件注入当前上下文所需的 store 实例 - action 接收注入的依赖作为参数，或从
this上读取（需在 setup 中绑定） - 第三方组件库中若需 Pinia，应检测
getActivePinia()，缺失时不自动创建，而是抛错引导消费方正确挂载
用 $onAction 控制副作用作用域
$onAction 默认随组件生命周期自动销毁，这是天然的环境隔离机制。但若误设 detached: true，就可能让 loading、日志等副作用泄漏到其他模块。
- 除非明确需要全局监听（如统一错误上报），否则不传第二个参数，让订阅与组件绑定
- 若需跨组件共享 loading 状态，应通过专用 store（如
uiStore）管理，并在$onAction中仅更新该 store 的字段，而非操作 DOM 或 ref - 避免在
$onAction回调里直接修改非当前 store 的 state，防止隐式耦合
异步 action 中规避 this 引用污染
在 async action 内部，若使用 setTimeout、Promise.then 或第三方回调，需注意 this 是否仍指向当前 store 实例 —— 尤其当 store 被卸载后回调才执行，可能引发内存泄漏或报错。
- 优先使用
async/await保证执行流可控 - 对需延迟执行的逻辑，加一层判断：
if (!this.$state) return - 涉及定时器或事件监听时，在 action 开始时保存 abort controller 或清理函数，并在 store 卸载钩子中统一释放
