web storage键名应采用“应用标识_模块_功能”分层命名并加版本号，统一前缀管理、封装自动注入工具，预留字段位支持环境与用户隔离，定期扫描清理陈旧键。
设计 Web Storage 的键名空间，核心是避免冲突、便于维护、支持演进。多应用共存时，不同子应用（如 admin-dashboard、customer-portal、mobile-web）可能共享同一域名，若都直接用 "theme" 或 "user" 作键名，极易覆盖彼此数据。
按应用+模块+语义分层命名
每个键名应体现“谁在用、用在哪、存什么”，推荐格式：应用标识_模块_功能，例如：
admin-dashboard_ui_sidebar_collapsedcustomer-portal_form_draft_contactmobile-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 天未更新的键（需值中含时间戳）发起清理
- 记录清理日志，不静默删除，便于问题回溯
