pinia 的 action 本身不构成独立作用域，其执行依赖 store 实例的响应式上下文和隐式创建的 effectscope；该 scope 在 store 初始化时建立，托管 computed、watch 和副作用，卸载时自动清理响应式更新，但不取消异步请求。
Pinia 的 action 本身不构成独立的作用域，它的执行环境完全依托于 store 实例的响应式上下文和其背后的 effectScope 层级结构。真正起作用域封装作用的是 store 创建时隐式建立的 scope，而非 action 函数体内部。
store 级 effectScope 是 action 的实际容器
每个通过 defineStore 创建的 store，在初始化时都会调用 setupStore，其中会创建一个专属的 effectScope()：
- 这个 scope 负责托管该 store 内所有
computed、watch和副作用逻辑（包括异步 action 中触发的响应式更新） - action 函数在调用时，其内部对
this.xxx的读写、watch的注册、computed的依赖收集，全部运行在这个 scope 的生命周期内 - 当 store 被卸载（如手动
store.$dispose()），该 scope 会被 stop，自动清理所有关联的响应式副作用——action 启动的 pending 请求不会被自动取消，但其后续的响应式赋值（如this.data = res）将不再触发更新
action 没有额外闭包或作用域隔离
action 是普通函数，定义在 store 对象上，它不自带作用域边界：
- 它能自由访问
this（即当前 store 实例），也能直接 import 并调用其他 store 的 action - 它不捕获外部变量形成闭包作用域；变量作用域仍遵循 JavaScript 词法作用域规则
- 所谓“封装”，是指逻辑组织层面的封装（把异步请求+状态更新打包进一个方法），不是运行时作用域隔离
全局 Pinia scope 提供统一销毁能力
整个 Pinia 实例自身也持有一个顶层 effectScope(true)：
- 所有 store 的专属 scope 都是它的子 scope
- 调用
pinia._e.stop()（例如在应用卸载时）可一次性停止全部 store 的响应式副作用，包括所有正在运行或已注册的 action 相关 effect - 这为 SSR 卸载、测试清理、微前端 store 隔离等场景提供了底层保障
实际开发中需注意的边界
虽然作用域由 effectScope 管理，但开发者仍需主动处理非响应式资源：
- 未 cancel 的
fetch或axios请求不属于 effectScope 管理范围，需手动 AbortController - 定时器（
setTimeout/setInterval）、事件监听器需在$onAction的onError/after或store.$dispose钩子中清理 -
$onAction订阅本身也注册在 store scope 下，因此也会随 store 卸载而自动失效
