Pinia 管理数据看板筛选条件的核心是将「筛选配置」设计为可复用、可持久、可联动的业务状态；需单独建 useDashboardFilterStore，含结构化 state、语义化 getters、封装 actions，并统一处理维度加载、URL 同步与组件解耦。
Pinia 在数据看板中管理多维度筛选条件，核心是把「筛选配置」作为可复用、可持久、可联动的业务状态来设计，而不是简单存个对象。关键在于结构清晰、变更可控、组件解耦。
筛选状态应单独建 Store 模块
不要把筛选条件混在用户或布局 Store 里，新建专用 Store，例如 useDashboardFilterStore。它应包含：
-
state：用 ref 定义完整筛选对象，如
filters: ref({ timeRange: 'last7d', region: [], category: '', keyword: '' }) -
getters：提供语义化读取，比如
hasActiveFilter判断是否有生效条件，filterParams返回后端兼容格式（自动忽略空值、转换时间戳等） -
actions：封装操作逻辑，如
reset()、setTimeRange(range)、toggleRegion(code)，避免组件直接修改 state
支持动态加载与缓存的维度选项
像地区、分类这类下拉项通常来自接口，且可能层级深、数据量大。Store 中应一并管理：
- 用
ref<map any>>(new Map())</map>缓存已加载的维度列表，键为维度类型（如'region'） - 提供
loadDimension(type, params?)action，内部做防抖、重复请求拦截、错误重试 - 组件通过
watch或点击触发时调用该 action，不自行发请求
筛选变更需联动视图与 URL 同步
看板常需分享链接或刷新保留条件，Store 应主动参与路由和持久化：
- 在 action 中更新 state 后，同步调用
router.replace({ query: store.filterParams })，保持 URL 可 bookmark - 初始化时从
route.query恢复初始值，而非仅依赖默认 state - 搭配
pinia-plugin-persistedstate，按需持久化（如只存最近 3 次常用组合），避免 localStorage 膨胀
组件使用要职责分明
避免所有筛选控件都直接读写 Store —— 这会让 UI 和逻辑紧耦合：
- 筛选面板组件负责展示、输入、调用 Store 的 actions
- 图表/表格组件只订阅
store.filterParams，用于请求数据或本地过滤，不关心“怎么改” - 复杂联动（如选中某区域后自动清空子区域）放在 Store 的 action 内部处理，不散落在各组件 watch 中
