企业官网建设流程全解析

1个文件划清全球域名边界：Public Suffix List 完整解读

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

Public Suffix List（PSL，公共后缀列表）是一个一万六千余行的纯文本文件：它列出所有"任何人都能注册域名"的后缀，.com 和 .github.io 都在内。浏览器、邮件系统和企业治理都靠它判断域名的可注册部分从哪里开始。

场景痛点：一条 Cookie 怎么串到隔壁域名

想象你登录了mail.shop.com。随后一个恶意者抢注了attacker.shop.com，如果浏览器把两者当成同一个站，Cookie 就直接泄出去了。

问题出在"边界"上：浏览器不知道域名哪一段是平台固定部分、哪一段归站主。没有权威依据时只能猜——com是，co.uk算不算？github.io呢？

猜一定会错。a.github.io和b.github.io是两个毫不相干的开发者站点，一旦把github.io当成单个站，甲的博客就能读到乙的会话。这就是这份名单存在的理由：给每个域名钉死"可自由注册的最长后缀"，前面那段才算站主自己的。🍪

核心结构：如何读懂 public_suffix_list.dat 的两区

打开 public_suffix_list.dat——这个仓库唯一的"数据文件"，也就是 Public Suffix List 本体。全文只分两段：

• ICANN 区（上半部分）：官方域名空间，com、co.uk都在里面，新 gTLD（通用顶级域名，即 .app、.blog 这类）也归在这；
• PRIVATE 区（下半部分）：平台自己运营的域名空间，如github.io、blogspot.com——底下那层可以随意"注册"，但入口由平台控制。

两区差异一张表说清：

语法上很简单：一行一个后缀，!开头代表通配（该行及以下整层都算后缀），//是注释。文件整体按字母序排，插错位置会被 linter 直接拦下。

自动维护流水线：数据从哪来、怎么校验、如何追溯

① 数据从哪来：newgtlds.go 负责拉取 ICANN 的最新 gTLD 数据和 IANA 的根域清单，格式化成 PSL 语法后与现列表比对，官方区几乎不用人肉维护。

② 怎么校验：pslint.py 逐行扫描重复条目、排序错误和非法字符；本地跑 Makefile 里的test-syntax目标就能过一遍；tests/ 目录下还有 test_psl.js 等规则测试，验证每条规则在解析器里的实际行为。

③ 如何追溯：变更合并后，history.go 会记录对应 PR 的历史，任何一条后缀是谁加的、为什么加，都能查到。⚙️

三个落地场景

1. 浏览器 Cookie 隔离：浏览器计算"可注册域"时以这份名单为准，不同*.github.io站点之间互读不到 Cookie。
2. 邮件反钓鱼：网关给仿冒域名打分时拿列表当边界，免费二级域名不再被误判成"同站"而放行。
3. 企业内部域名治理：tools/private_domains_checker/ 目录提供专用检查脚本，提交私有后缀申请前可先用它验证候选条目。

常见误区

问：我在 example.com 下注册了 foo，能申请把 example.com 加进列表吗？答：不能。PRIVATE 区只对"子域层级开放注册"的平台开放，普通注册人的子域不满足准入条件。

问：列表里出现了新 TLD，是不是就能直接用了？答：不是。名单只定义边界，拿域名仍要走正常注册商流程。

问：改本地那份 .dat，能不能让自家白名单放行？答：只能影响自己运行的程序，改不了任何全局标准。

快速上手

把 Public Suffix List 拉到本地并跑通格式检查：

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

第二条命令会跑 linter 自检加全量文件扫描，输出干净即代表格式合格。想加私有后缀？去数据文件下半部分的 PRIVATE 区，按字母序插入条目，再按 README 的要求用官方 PR 模板提交申请。✅

一份名单，钉死全球域名边界。

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