怎样设计 Web Storage 的键名空间以支持多应用共存

Web Storage键名应采用“应用标识_模块_功能”分层命名并加版本号，统一前缀管理、封装自动注入工具，预留字段位支持环境与用户隔离，定期扫描清理陈旧键。

设计 Web Storage 的键名空间，核心是避免冲突、便于维护、支持演进。多应用共存时，不同子应用（如 admin-dashboard、customer-portal、mobile-web）可能共享同一域名，若都直接用 "theme" 或 "user" 作键名，极易覆盖彼此数据。

按应用+模块+语义分层命名

每个键名应体现“谁在用、用在哪、存什么”，推荐格式：应用标识_模块_功能，例如：

• admin-dashboard_ui_sidebar_collapsed
• customer-portal_form_draft_contact
• mobile-web_cache_product_list_v2

其中“v2”表示结构版本，为后续迁移留出余地；下划线分隔增强可读性，也规避了点号（.）在 JS 属性访问中的歧义。

统一前缀管理，禁止裸键名

严禁直接使用 localStorage.setItem("token", ...) 这类无上下文的写法。所有键名必须带作用域前缀，哪怕单应用初期也应养成习惯。可封装基础工具函数，自动注入前缀：

• 初始化时传入应用名（如 createStorage("admin-dashboard")）
• 调用 store.set("ui_sidebar_collapsed", true)，内部自动拼为 "admin-dashboard_ui_sidebar_collapsed"
• 避免硬编码字符串，降低拼写错误与重构成本

预留扩展位，兼容未来变更

键名结构需具备延展性。比如当前只需区分应用，未来可能需支持用户级隔离或环境区分（dev/staging/prod），可在设计时预留字段位：

• 当前：appname_module_key
• 扩展后：appname_env_userid_module_key（如 admin-dashboard_prod_u123_auth_token）
• 不建议用动态拼接（如 `${app}_${env}_${id}_...`），而应定义清晰的字段顺序与分隔规则

定期扫描与清理陈旧键

多应用长期运行后，旧版本键名可能残留（如 old-admin_theme 或 dashboard_v1_prefs）。建议在应用启动时执行轻量扫描：

• 匹配正则 ^admin-dashboard.*_v1$ 或 ^legacy-.*
• 对超过 90 天未更新的键（需值中含时间戳）发起清理
• 记录清理日志，不静默删除，便于问题回溯