核心方案是通过结构化命名与封装机制管控 localStorage：统一使用“组织名+产品名+版本号”前缀（如acme-crm_v2_user_settings），封装StorageManager类自动拼接前缀、提供clearOwn()和序列化，并在微前端中按模块隔离前缀，辅以ESLint禁用直接调用、文档约束及CI扫描保障落地。
核心思路是：不依赖“别人不乱写”，而是用结构化命名 + 封装机制，把 localStorage 操作收归到你可控的数据层中，让第三方脚本即使想碰也碰不到你的键。
统一前缀 + 项目标识作为命名硬约束
所有业务数据的 localStorage 键必须带唯一、稳定、可识别的前缀，例如：
✅ acme-crm_v2_user_settings
✅ acme-crm_v2_checkout_cache
❌ userSettings、cache、theme（泛化名极易冲突）
前缀应包含组织名 + 产品名 + 版本号，确保跨团队、跨项目、跨时间维度都具备区分力。版本号还能支持后续数据迁移或格式升级。
封装 StorageManager 类，拦截所有读写入口
禁止直接调用 localStorage.setItem 或 localStorage.getItem，全部走封装类：
- 类内固化前缀，所有键自动拼接，调用方只传逻辑名（如
"theme"） - 提供
clearOwn()方法，仅清除本项目前缀下的键，不影响第三方或其它模块 - 可加入简单类型序列化（自动
JSON.stringify/JSON.parse），避免字符串误存 - 开发环境开启键名校验，对未按约定命名的 key 发出 warning
微前端或多模块场景下进一步隔离
若页面中同时运行多个独立模块（如主应用 + 嵌入式报表组件 + 客服插件），需叠加模块级作用域：
- 在前缀后追加模块标识，如
acme-crm_v2_reporter_filters、acme-crm_v2_chat_session - 各模块使用各自实例化的
StorageManager，prefix 不同，互不感知 - 避免全局共享一个 manager 实例，防止模块间无意覆盖
配合构建时检查与文档约束
技术手段之外，需配套落地保障：
- 在 ESLint 规则中禁用
localStorage.直接调用，强制走封装 API - 在团队 Wiki 明确列出“禁止使用的键名黑名单”（如
token、user、config） - CI 流程中扫描源码，检测未加前缀的
setItem(.*")字符串模式并阻断合并
