微前端中cookie隔离需path+domain+命名空间协同：path限定路径范围，domain支持子域共享，命名空间防键名冲突，子应用须自主清理。
在微前端架构中，为不同子应用划分 Cookie 作用域，核心是**用 path + domain + 命名空间三者协同控制可见性与安全性**，而不是只靠一个属性。关键不在“能不能共享”，而在“谁该读、谁该写、谁不该碰”。
用 Path 精确限定子应用可访问范围
Path 是最常用、最直接的隔离手段，它决定浏览器在哪些 URL 路径下自动发送该 Cookie。
- 每个子应用应使用专属路径前缀：如主应用用
Path=/（慎用），订单中心用Path=/order，用户中心用Path=/user - 设置时必须以斜杠开头，
Path=order无效，Path=/order/和Path=/order效果一致（后者会自动补尾斜杠） - 注意前缀匹配特性：
Path=/user会匹配/user/profile，也会匹配/user-info（因为字符串前缀相同），这不是 bug，是规范行为 - 子应用初始化时，优先读取自己 path 下的 Cookie；写入时显式指定 path，避免依赖默认值
通过 Domain 配合实现跨子域统一管理
当微应用部署在不同子域（如 main.example.com、cart.example.com）时，仅靠 path 不够，需配合 domain 打通可信范围。
- 统一设
Domain=.example.com（注意开头的点），使所有子域都能读写该 Cookie - 但必须和 path 联合使用，例如：
Cookies.set('cart.items', '12', { path: '/cart', domain: '.example.com' })→ 仅/cart路径下的请求携带，且仅限.example.com及其子域 - 禁止设
Domain=com或Domain=example，浏览器会拒绝；顶级域名（如 .com）不可写 - 若子应用全在同域路径下（如都跑在
example.com的不同路由），domain 可省略，由浏览器自动设为当前 host
强制命名空间避免键名冲突
多个团队独立开发，极易出现 token、theme 这类通用键名重复。光靠 path/domain 无法解决语义冲突。
- 采用
[app-id].[domain].[key]结构，例如：main.auth.token、cart.ui.theme、report.data.lang - 推荐封装统一 Cookie 工具函数，在
set/get时自动注入前缀，子应用只传业务键名 - 不建议用
document.cookie原生操作——易漏编码、难统一前缀、无法自动处理 path/domain - js-cookie 库的
withAttributes()可预设公共配置，再链式调用，大幅提升一致性
清理与生命周期必须由子应用自主负责
微前端中子应用可能动态加载/卸载，Cookie 若不及时清理，会残留干扰后续逻辑。
- 子应用
unmount阶段，应主动清除自己写入的 Cookie，用相同 path + domain + name 覆盖并设maxAge: 0 - 避免全局
Path=/的长期 Cookie 存储敏感数据；会话级数据优先用max-age控制时效 - 调试时注意：修改 path 后，旧 path 下同名 Cookie 仍存在，需手动删或覆盖，否则会出现“两个同名但不同 path 的 Cookie 并存”现象
- 浏览器 Application > Cookies 面板里，务必核对每条 Cookie 的 Path 和 Domain 列是否符合预期
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
