Cookie 为什么不能跨 .github.io 共享？5 分钟看懂 Public Suffix List

Cookie 为什么不能跨 .github.io 共享？5 分钟看懂 Public Suffix List

【免费下载链接】listThe Public Suffix List项目地址: https://gitcode.com/gh_mirrors/li/list

为什么 a.github.io 和 b.github.io 两个站点不能共享 Cookie？浏览器靠一份叫 Public Suffix List（PSL，公共后缀列表）的文件来识别“域名边界”。它列出所有可直接注册的公共后缀，是浏览器 Cookie 隔离与域名解析的依据。

到底什么是“公共后缀”

公共后缀，就是用户能（或历史上能）直接在其下面注册名字的域名：com、co.uk、pvt.k12.ma.us 都算。其中 ccTLD（国家/地区顶级域名，例如 .cn）是很常见的一类，不少 ccTLD 下面还有一级可注册的二级分区，比如 co.uk。

浏览器处理 Cookie 时，以公共后缀为界：界之上是“公共基础设施”，界之下才算“你的地盘”。所以 a.github.io 与 b.github.io 属于两个不同域名，Cookie 天然不互通。没有这份列表，任何服务都可以往整个 .io 下写 Cookie，网络环境会直接失控。

列表里装了什么：ICANN 官方与私有域名后缀双轨结构

打开仓库核心文件 public_suffix_list.dat，会发现整份列表分成泾渭分明的两块：

• ICANN DOMAINS：由 ICANN（全球域名体系治理机构）维护的官方后缀，包括 .com、.org 这类传统 gTLD，.cn、.uk 这类国家/地区顶级域名，以及 .app、.blog 这类新 gTLD
• PRIVATE DOMAINS：由企业或组织自行登记的私有后缀，例如 github.io、blogspot.com，也就是常说的“私有域名后缀”

两部分由===BEGIN ICANN DOMAINS===和===BEGIN PRIVATE DOMAINS===标记分隔，整个文件超过一万六千行。这种“官方 + 私有”的双轨设计兼顾权威与灵活：官方部分可回溯权威来源，私有部分让各平台自行管理子域名边界。

它如何保持准确：同步、校验与测试工具链 🔧

一份上万行的列表不可能靠人工核对。仓库内置了完整的自动化流水线：

• 数据同步：tools/newgtlds.go 定期从 ICANN 官方 gTLD 注册表（JSON 格式）和 IANA 的 TLD 清单（TXT 格式）拉取最新顶级域名数据，自动更新列表中的新 gTLD 区段
• 语法校验：linter/pslint.py 逐行检查格式、通配符语法（*）、例外条目（!）与排序规则，有问题会按行报出警告和错误
• 测试验证：tests/test_psl.js 等测试套件验证列表解析结果，Makefile 把语法检查与规则测试串成一条完整流程

每次变更都有提交记录可查，谁改了什么、为什么改、经过什么校验，全部可追溯。

谁在用它：从浏览器 Cookie 隔离到反钓鱼 🔒

1. 浏览器安全：浏览器通过 libpsl 库加载列表判断域名边界，防止跨域 Cookie 注入
2. 邮件与反钓鱼：识别恶意域名时，公共后缀帮助定位“真实域名”，不被子域名伪装迷惑
3. 企业 IT 管理：tools/private_domains_checker/ 下的工具可校验私有后缀申请的合规性
4. 域名解析优化：各类域名解析库都以它作为统一边界依据，提升解析的一致性与准确性

一键拉取并校验列表

两步即可在本地跑通完整验证：

git clone https://gitcode.com/gh_mirrors/li/list cd list && make test

make test 先跑 linter 语法检查，再用 libpsl 校验列表规则；全部通过，说明你手上的列表干净且完整。实际集成时，直接引用仓库里的 public_suffix_list.dat，并从这里定期拉取更新即可。

【免费下载链接】listThe Public Suffix List项目地址: https://gitcode.com/gh_mirrors/li/list