Pinia 管理系统配置需独立建模、区分静态/动态配置：通过 app/config.store.ts 封装，首次在启动阶段异步加载，支持节流与重试；更新按语义分类处理，配合 provide/inject 实现只读透传。
Pinia 处理系统配置参数的全局缓存与更新，核心在于两点：一是把配置当作**可复用、可响应、可隔离**的状态来管理；二是明确区分“静态配置”和“动态配置”的加载时机与更新机制。它不是简单地把 config 对象塞进 store，而是要兼顾首次加载、后续刷新、多组件订阅、类型安全和副作用控制。
配置状态应独立建模，不混入业务 store
系统配置（如 API 基础地址、主题色、语言包开关、权限白名单、菜单结构等）属于应用级元数据，生命周期长、变更频率低、被大量组件读取。建议单独建立 app/config.store.ts：
- state 定义为函数返回对象，保障 SSR 或多实例场景下的状态隔离
- 使用 defineStore 显式命名，例如
useConfigStore - 避免在其他 store（如 user 或 order）里直接 import 并修改 config 状态——这会破坏模块边界
首次加载走异步初始化，支持防抖与失败重试
配置通常来自后端接口（如 /api/v1/config），不能依赖组件挂载时才拉取。推荐在应用启动阶段（如 main.ts 或 router.beforeEach 中）主动触发：
- 在 store 内定义
fetchConfig()action，内部调用 API 并赋值给 state - 加 loading 和 error 状态字段，方便 UI 层反馈（比如骨架屏或错误提示）
- 对重复调用做简单节流（例如 5 秒内不再发起），防止路由频繁切换导致多次请求
- 失败时保留旧配置，并提供
retry()方法供手动恢复
更新机制要区分“热更新”与“全量刷新”
不是所有配置都适合实时响应式更新。需按语义分类处理：
- 只读型配置（如版本号、版权信息）：加载一次即可，无需监听变更
-
影响 UI 的配置（如主题色、语言、布局模式）：用
watch监听 state 变化，触发 CSS 变量注入或 i18n locale 切换 -
影响逻辑的配置（如权限开关、功能灰度标识）：配合
computed或 getter 派生出布尔判断，让业务组件通过configStore.canAccess('order:export')这类语义化方法消费 -
需要强制刷新的配置（如菜单结构变化）：提供
refreshMenu()类 action，内部调用router.addRoute()动态注册，而非仅改 state
配合 provide/inject 实现轻量跨层级透传
对于高频读取但极少修改的配置项（如 baseURL、locale），可在根组件用 provide 注入已解构的响应式字段，避免每个组件都调用 useConfigStore()：
- 在 App.vue setup 中：
const config = useConfigStore(); provide('config', readonly(config.$state)) - 子组件中：
const config = inject('config') as ToReadonly<configstate></configstate> - 注意：仅用于只读场景；写操作仍必须走 store action，保持单向数据流清晰
