团队里生产、测试、预发常常共用一个顶级域：www.example.comwww.test.example.comwww.uat.example.com。某天测试同学反馈一个诡异现象——明明把界面语言切成了中文。页面却时不时按英文渲染，偶尔还会在两种语言之间来回重定向；而这台机器之前刚访问过生产环境。打开 DevTools 一看，名为 lang 的 cookie 居然有两条：一条 domain 是 .example.com值是 en一条 domain 是 .test.example.com值是 zh。

两条同名 cookie、值还不一样，到底谁说了算？按理说，这篇文章借这个真实问题，把 Cookie 的作用域讲透：父域 cookie 为什么会向下泄漏到所有子域、同名 cookie 为什么是「不可区分」的、浏览器和服务端各自会读到哪一个。还有一套可复用的「写入隔离 + 读取自愈 + 正确删除」治理方案。

至于先厘清，Cookie 的作用域由什么决定

A single cookie is sent with a request only if two attributes match: Domain and Path.

• If you set Domain=example.com: cookie will be sent to example.com and *all* its subdomains – www.example.com。www.test.example.com,a.b.example.com,etc.
• If you omit Domain : it will only be sent to that exact host;subdomains won’t receive it.
• Cookies written in a subdomain never leak upwards or sideways.

The parent domain’s cookie travels downwards in a one‑way fashion.

P --> A
P --> B
P --> C
S --> B

The parent domain’s cookie is visible to all subdomains。while a child domain’s cookie is only visible to itself . This unidirectional leakage is root of all subsequent issues.

说到真正的坑，同名 Cookie 是「不可区分」的

The crux of this article: when your browser contains two cookies named lang=zh;lang=en,server sees just:

Cookie: lang=zh;lang=en

No metadata about which domain each value came from survives in HTTP header. RFC 6265 explicitly states that servers must not rely on order of cookies in header when multiple cookies share same name.

Cookies with longer paths are listed before cookies with shorter paths. Among cookies that have equal-length path fields,cookies with earlier creation-times are listed before cookies with later creation-times. Servers SHOULD NOT rely upon order in which se cookies appear in header.

This means that reading “which” value you get is inherently nondeterministic across browsers and even over time on same browser—depending on which environment was visited first.

客户端也无法辨别来源：document.cookie 只返回 name=value

• You’ll often find yourself debugging “*** am I getting zh sometimes and en or times?” because both values are lumped toger.
• The JavaScript API can’t tell you wher a particular value came from example.com or test.example.com—every read returns just one of m based on whatever happens to come first in string.
• This nondeterminism is what turns seemingly simple language switches into flaky bugs that vanish after clearing your cache or restarting your browser.

为什么多环境共用顶级域最容易中招

A quick walkthrough explains *** this happens:

1. User visits production ​) first,selects English → app writes lang=en;怎么说呢，Domain=example.com; Path=/，. This becomes visible to all *.example.com sites.
2. User n visits testing ​) → test environment writes its own Chinese preference: lang=zh;Domain=test.example.com;Path=/，.
3. A request from test now carries both values: one from example.com's parent scope and one from its own child scope.

U --> H
H --> L1
H --> L2
L1 --> R
L2 --> R
R --> X
X --> Y

The leakage is always one‑way—from parent to child—but never reverse. That’s *** you see “production changes break testing” but production itself remains unaffected—making it hard to reproduce locally unless you purposely visit both environments back‑to‑back.

后果不止于语言切换

• Middlware routing / redirects based on language: an intermittent redirect loop may occur if different requests see different language values for consecutive requests.
• User agent headers derived from language cookies: an incorrect language header may cause APIs to return mismatched localized content even though UI shows anor language.
• Spa/SDK initialisation based on locale or feature flags stored in a cookie: renders may flicker 娱乐ween languages or features during reloads or navigation until manual clearing occurs. These bugs share common traits:
  • Nonsensical intermittent behavior tied closely to recent environment access history. Solution: start by suspecting “cookie contamination” whenever you see se symptoms. If you're wondering how much trouble this could cause beyond language toggling—imagine security tokens or A/B experiment flags being polluted across environments!
  "

一份可复用的 checklist

•  写         \u3000 \u4e00\u6b21\u8bbe\u7f6e​了相\u540c;的 消息\u9009视\u9009度\u53d8\u51fa

  \u90fd \u4e00 “. “ \u4e00 \ u3000\u202f& \u56feÐ\xa7;§c\xcf\x80 å\xbf—§e §e å\xa5 a"\uff01& \u6b64 \u670d>\t

  "

  • - 写 Cookie 必须显式指定 Domain + Path 并保持一致性。
  \
  • - 对“每个环境本该独立”的状态→ 写精确子域，不写顶级父域。
  \ - 多环境共用顶级域时默认假设父域 Cookie 会泄漏至所有子域；对关键 Cookie 加“同名去重自愈”。\

  - 读取同名敏感 Cookie 前先确认是否重复；怎么说呢，服务端永远不要依赖 Cookie 头顺序。}，\
  
  - 删 Cookie 时必须使用空值 + 過期时间 + 完全匹配 Domain/Path/Secure/SameSite；如来源不明则多组合覆盖删。话说回来，\
  - 客户端自愈仅对后续请求有效；首个请求需在服务端通过 Set-Cookie 或中间件立即清除。\