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 ListPSL公共后缀列表的文件来识别“域名边界”。它列出所有可直接注册的公共后缀是浏览器 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 这类新 gTLDPRIVATE 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 隔离到反钓鱼 浏览器安全浏览器通过 libpsl 库加载列表判断域名边界防止跨域 Cookie 注入邮件与反钓鱼识别恶意域名时公共后缀帮助定位“真实域名”不被子域名伪装迷惑企业 IT 管理tools/private_domains_checker/ 下的工具可校验私有后缀申请的合规性域名解析优化各类域名解析库都以它作为统一边界依据提升解析的一致性与准确性一键拉取并校验列表两步即可在本地跑通完整验证git clone https://gitcode.com/gh_mirrors/li/list cd list make testmake test 先跑 linter 语法检查再用 libpsl 校验列表规则全部通过说明你手上的列表干净且完整。实际集成时直接引用仓库里的 public_suffix_list.dat并从这里定期拉取更新即可。【免费下载链接】listThe Public Suffix List项目地址: https://gitcode.com/gh_mirrors/li/list创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考