模块化配置中心的核心是按业务域、ui层级和变更频率拆分配置，通过configregistry动态聚合，支持多环境/租户分层覆盖与运行时热更。
模块化配置中心的核心，不是把所有参数堆进一个 JSON 文件，而是按业务域、UI 层级和变更频率拆分配置，再通过轻量机制动态聚合与注入。关键在“可维护性”和“运行时可控”，而非单纯集中存储。
按 UI 职责划分配置模块
把全局 UI 参数（如主题色、圆角尺寸、字体比例、动效时长、暗色模式开关）从代码中剥离，按语义拆成独立模块：
- theme.json：只放视觉基础值（primaryColor、borderRadiusSm、fontSizeBase），不包含组件级样式逻辑
- typography.json：定义字号阶梯、行高、字重映射（如 "title-lg": { size: "1.5rem", weight: 700 }）
- motion.json：收拢 transition 和 animation 的持续时间、缓动函数（ease-out-cubic）、是否启用动效的布尔开关
- mode.json：仅存当前模式标识（"light" / "dark" / "auto"），由系统监听 prefers-color-scheme 触发更新，不存具体颜色值
每个模块独立版本管理，前端构建时可单独热更（例如通过 CDN 指向 versioned/theme-v2.json），避免一次全量发布引发意外。
用模块注册 + 运行时合并替代硬编码导入
不推荐在入口文件 import 所有配置然后 Object.assign 合并——这会让 tree-shaking 失效，且无法支持运行时切换。
- 设计一个 ConfigRegistry 类，提供 register(name, loader) 方法，loader 返回 Promise
- 各模块导出自己的异步加载函数（如 themeLoader = () => fetch('/conf/theme.json').then(r => r.json())）
- 主应用启动时调用 registry.loadAll()，自动并发加载已注册模块，并用深合并策略（浅合并会丢失嵌套结构）生成最终 config 对象
- 配合 Context 或 Pinia store 暴露 config，组件内用 useConfig().theme.primaryColor 即可响应式读取
支持多环境 + 多租户的配置分层机制
真实项目常需区分开发/测试/生产环境，或 SaaS 场景下不同客户使用不同 UI 风格。靠 if-else 切换配置源太脆弱，应引入分层覆盖规则：
- base 层：所有租户共用的基础参数（默认字体、基础间距）
- tenant 层：按租户 ID 加载（如 /conf/tenant-acme.json），覆盖 base 中指定字段
- user 层（可选）：用户自定义设置（如字体大小偏好），仅覆盖当前会话，不持久化到服务端
合并顺序为 base ← tenant ← user，后写入者优先。注意：只允许覆盖已有 key，新增 key 默认被忽略，防止误注入非法配置。
配套工具链让配置真正“活”起来
模块化配置的价值，只有配上可验证、可调试、可回滚的能力才落地：
- 写一个 config-validator.js 脚本，在 CI 中校验每个 JSON 是否符合 JSON Schema（例如 theme.primaryColor 必须是合法 hex 或 rgb 字符串）
- 在 DevTools 中暴露 window.$config 全局变量，点击可展开当前生效的完整配置树，并标注每个值来源（来自 tenant-acme.json 第 12 行）
- 提供简单 UI 控制台（仅开发环境），支持临时修改某个值并实时预览效果，刷新即还原，降低设计师协作门槛
不复杂但容易忽略。
