ie8–ie11支持document.cookie基础读写，但samesite属性被完全忽略，secure需https环境，且后续js逻辑（如fetch、promise）须降级兼容。
IE旧版浏览器（尤其是IE8–IE11）对Cookie的处理本身没有语法级限制，真正影响兼容性的不是document.cookie读写本身，而是后续依赖Cookie的逻辑所用的JS特性或HTTP协议行为。比如SameSite属性、Secure标记、第三方上下文下的跨域写入，以及JS代码中调用的API（如Promise、fetch）——这些才是实际出问题的地方。
一、document.cookie基础操作本身是兼容的
IE6+均支持原生document.cookie的读写，无需额外垫片：
- 设置：直接赋值
document.cookie = "key=value; path=/; expires=...;" - 读取：
document.cookie返回分号分隔字符串，可用正则或循环解析 - 删除：设过期时间为过去时间，如
expires=Thu, 01 Jan 1970 00:00:00 GMT
注意：IE8及以下不支持encodeURIComponent自动编码，若value含特殊字符（空格、分号、逗号等），需手动escape()或自定义编码函数；但escape()在现代标准中已废弃，建议仅对IE8兜底使用。
二、SameSite属性必须降级或跳过
IE所有版本（包括IE11、Edge Legacy）完全不识别SameSite属性。若服务端下发SameSite=None; Secure，IE会静默忽略整个Set-Cookie头，导致Cookie丢失。
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 服务端应根据User-Agent判断：匹配
MSIE|Trident|Edge\/[0-1][0-9]时，不设置SameSite字段（留空），让IE按默认策略（等效于SameSite=None）处理 - 若前端通过
document.cookie写入，不要尝试加SameSite=——该字段在JS中无法设置，只由HTTP响应头控制
三、Secure标记需配合实际HTTPS环境
IE8–IE11支持Secure属性，但仅当页面本身通过HTTPS加载时才生效。若页面走HTTP却设置了Secure，IE会拒绝存储该Cookie（不报错，静默失败）。
- 开发阶段避免硬编码
Secure，可通过环境变量或构建时注入 - 测试时确认协议一致：
location.protocol === 'https:'再拼接; Secure
四、配套JS逻辑必须做降级处理
Cookie只是载体，真正崩溃常发生在读取后使用的环节：
- 避免用
fetch传Cookie：IE全系不支持，改用XMLHttpRequest并手动设withCredentials = true - 避免用
Promise封装Cookie操作：IE11无原生Promise，需引入es6-promise垫片 - 避免用
Array.from、Object.entries解析cookie字符串：IE11不支持，改用for循环或split().map()（注意map在IE9+才支持）
推荐用特性检测代替浏览器检测，例如：
if ('fetch' in window) { /* 用fetch */ } else { /* 用XHR */ }不复杂但容易忽略。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
