同源策略下Cookie可跨端口共享（通过Domain属性），LocalStorage则严格按“协议+域名+端口”隔离；二者表面相反，实则因用途与风险模型不同而设计取舍一致。
同源策略对 Cookie 和 LocalStorage 在端口不同时的限制，表面看“相反”，实则逻辑一致：都是为保障隔离性，但实现机制和控制粒度不同。
Cookie 可通过 Domain 属性绕过端口限制
Cookie 的同源判定在早期浏览器（如 IE）中本就不含端口；现代浏览器虽默认按“协议+域名+端口”判断，但服务器可通过 Set-Cookie 响应头显式指定 Domain 属性，使 Cookie 被更宽泛地共享。
- 例如，
https://api.example.com:8080返回Set-Cookie: sessionid=abc; Domain=example.com; Path=/，该 Cookie 就会被https://www.example.com:443或https://admin.example.com:3000一并携带发送 - 关键点：Domain 必须是当前域名的父域（不能是任意域名），且不能包含端口；协议仍需匹配（HTTPS 页面不会发送 HTTP-only Cookie 给 HTTP 上下文）
- 这意味着——端口不同 ≠ Cookie 隔离，只要域名可归并、Domain 设置得当，跨端口 Cookie 共享完全可行
LocalStorage 严格绑定完整源，端口不同即彻底隔离
LocalStorage 的存储空间完全由“协议+主机名+端口”三元组唯一确定，没有类似 Cookie 的 Domain 扩展机制。
-
http://localhost:3000和http://localhost:3001是两个完全独立的 LocalStorage 容器，互不可见、不可读写 - 即使页面代码完全相同、域名和协议一致，仅端口差 1，也视为不同源，无法共享任何键值对
- 这种设计杜绝了“端口试探”类攻击——比如本地开发时多个服务共用 localhost，避免某端口的恶意脚本污染另一端口的数据
为什么说“截然相反”其实是误解？
这不是规则矛盾，而是用途与风险模型不同导致的设计取舍：
- Cookie 是服务端参与的身份凭证载体，需要一定灵活性支持子域/端口协同（如前后端分离部署），所以留出 Domain 控制入口
- LocalStorage 是纯前端持久化空间，无服务端校验环节，一旦被跨源读取即等同于数据泄露，因此必须最严粒度隔离
- 二者都服从同源策略大前提，只是 Cookie 的“源”可被服务端指令临时放宽，而 LocalStorage 的“源”由浏览器硬性锁定，不可协商
实际开发中的应对建议
当遇到端口差异带来的存储访问问题，优先按场景选择方案：
- 若需跨端口共享用户身份态 → 使用带
Domain的 Cookie + 后端配合校验，避免依赖 LocalStorage - 若仅需前端调试或本地多端口协作 → 用
postMessage+ iframe 中转，由同源父页协调不同端口子页的数据同步 - 若必须复用 LocalStorage 数据 → 通过代理服务统一端口（如 Nginx 反向代理把
:8080/api和:3000/app映射到同一端口下的不同路径），回归真正同源
