www与主域的Cookie为何不一定共用

1. 记录设置响应的完整主机，确认Domain是省略还是显式指定。
2. 按主机范围先作匹配表，再逐项核对其他发送条件。
3. 区分存储、发送、脚本读取与服务端接受四个阶段。
4. 仅用自有测试环境核对，记录属性和现象，隐藏真实秘密值。

适用范围与例子性质

本文供站点维护者理解HTTP字段，所有地址均为example.com教学域名；矩阵只比较Domain主机条件，假设Cookie已被接受且未过期，不进行真实网络或账号测试。依据RFC 6265及2026年10月27日核对的MDN说明。

host-only比写一个相同域名更严格

若https://example.com返回“theme=light; Path=/”，而没有Domain属性，按标准存储为仅主机Cookie。主机范围只对应example.com，不自动扩展到www.example.com。

• 若同一响应加上Domain=example.com，范围便包含该域及其子域。省略Domain与显式写上当前域名不是同一个动作：前者限制到当前主机，后者允许子域参与域匹配。

用三个主机读一张矩阵

本例三列是example.com、www.example.com和shop.example.com。第一行不写Domain，只有主域列满足主机条件；第二行写Domain=example.com，三列都满足主机条件。

• 图中的“匹配”不代表本页发送过请求，也不代表所有浏览器情境都会带上Cookie。它只回答一项字段规则，实际发送还受路径、安全连接、SameSite、有效期以及浏览器策略等条件影响。

www不能任意给旁边的主机设范围

Domain并不是任意收件人列表。MDN说明，它须是设置方自己的域或合适的父域，不能设置为另一不相关域，也不能使用公共后缀。因而不能通过填写多个主机名来让一份Cookie随意跨站共享。

• 在自己管理的子域上考虑放宽到父域之前，先确认是否真的需要那么大范围。若只是保存www入口的本地偏好，扩大到其他子域未必有必要；具体认证架构仍需单独设计。

发送到服务器与脚本读取要分开

HttpOnly影响脚本访问，并不意味着浏览器不能在符合条件的HTTP请求中发送该Cookie。反过来，在开发工具里看见一条Cookie，也不能据此断定某个页面脚本能读到它。

• 因此排障记录应写“未存储”“已存储但请求未带”“请求已带但服务未认可”等具体阶段。不要把它们统称为“www读不到”，也不要为排查而将真实会话值复制进公开日志。

Cookie域范围不等于同源规则

本站旧指南说明：两个HTTPS地址的主机不同，origin也不同。Cookie的Domain机制则有自己的匹配规则；能对父域及子域发送Cookie，不会把这些地址变成同一个origin。

• 即便两入口都收到同一名称和值，服务端是否接受该会话、是否关联同一账号仍取决于服务实现。不能用一个域属性替代跨源接口、认证状态或访问权限的完整检查。

怎样安全地核对自有测试环境

使用无敏感含义的测试偏好字段，先记录设置响应来自哪个完整主机及Domain是否省略，再核对目标请求的主机与路径。保留属性而不记录秘密值，比较时每次只改变一项条件。

• 若需检查实际登录，请使用获授权的测试账号与受控环境。本文没有修改本站登录系统，也没有提供读取他人Cookie的办法；表格是规则解释，不是对任一真实站点的检测报告。

相关指南

关联主题

• www 连接与同源：两种主机的证书覆盖与浏览器源需要分别判断，不能由同一IP或相似页面推断。

相关知识条目

结合下面的概念理解操作原因。