根域名还是子域名：一份面向技术选型的建站对比
一、引言
技术选型讨论里，"用 example.com 还是 www.example.com"经常被当成一个配置细节，随手在 DNS 面板填一条记录就过去了。但它其实是整个站点架构的第一块地基：canonical 主机名决定了搜索权重往哪里累积，决定了 Cookie 的作用域边界，决定了证书要签几张，也决定了三年后换托管商是一次 DNS 改动还是一场迁移项目。
厂商文档的默认建议互相矛盾——有的让你把根域名 301 到 www，有的反过来——因为这些建议背后是不同的基础设施约束，不是不同的审美。本文把它拆成九个可判断的维度，每个维度给出明确的优劣结论与适用边界，最后落到一张可以直接照着做的选型清单。
二、概念界定
根域名（apex / naked domain）：example.com。在 DNS 里它叫 zone apex，即该 DNS 区域的顶点。这个身份带来一个硬约束：顶点必须存在 SOA 与 NS 记录，而 CNAME 记录不允许与其他任何记录共存（RFC 1034 §3.6.2、RFC 2181 §10.1），所以根域名在标准 DNS 里不能设置 CNAME。这是后文所有技术差异的源头。
子域名（subdomain）：www.example.com、blog.example.com。它们是 zone 内的普通节点，可以自由设置 CNAME、A、AAAA、TXT 等记录，没有任何共存限制。
三个容易混淆的相邻概念，先划清界限：
- canonical 主机名：你希望搜索引擎和用户最终停留的那个 host。它与"用哪个域名建站"不是同一件事。
- registrable domain（可注册域）：
example.com，Public Suffix List 中com之下你实际拥有的那一层。它决定 Cookie 的共享边界和 SameSite 的"同站"判定。 - origin（源）：由 scheme + host + port 三元组决定。
example.com与www.example.com是两个不同 origin，尽管是同一个 site。
理解这三层的区别，才能理解为什么只差三个字符的两个名字，在安全、缓存、SEO 上表现迥异。
三、九个维度的对比
汇总表
| 维度 | 根域名（example.com） | 子域名（www / blog.example.com） | 更优方 |
|---|---|---|---|
| SEO 与权重传递 | 天然作为主域，权重集中 | 被视为独立 host，权重需从零积累 | 视内容归属，同主题选根域/子目录 |
| 品牌与用户认知 | 短、正式、易口播 | 可做业务分层，但会稀释主品牌 | 主品牌入口选根域 |
| Cookie 与登录态 | 可设 Domain=example.com 覆盖全部子域 | 无法向父域写 Cookie，默认 host-only | 需 SSO 选根域，需隔离选子域 |
| DNS / CNAME | 不能设 CNAME，需 ALIAS/flattening 或 NS 委派 | 可自由 CNAME，支持灰度与故障转移 | 子域名 |
| HTTPS 证书 | apex 与 www 需 SAN 或两张证书 | 可通配符覆盖，但通配符不含 apex | 小规模选根域，规模化选子域 |
| 部署与技术栈隔离 | 单一入口，多栈需自建路由层 | 天然部署边界，可按业务分供应商 | 子域名 |
| 安全隔离与故障域 | apex 是单点，故障影响全局 | origin 隔离彻底，故障局部化 | 子域名（需配合 Cookie 策略） |
| 运维复杂度与成本 | 记录少、证书少，但受解析商能力约束 | 记录/证书/监控按 host 线性增长 | 1–2 个入口选根域，多业务线选子域 |
| 迁移与扩展 | 新增业务需改路由与重新部署 | 加一条记录即可上线，但权重分裂 | 试错期选子域，长期资产选子目录 |
1. SEO 与搜索权重传递
搜索引擎按 host 划分站点边界。blog.example.com 在抓取、索引、外链统计上被当作独立站点处理，与 example.com 之间不会自动继承权威。Google 官方（John Mueller 自 2017 年起多次表述）的立场是：子域与子目录在排名算法中没有本质区别。但"没有算法惩罚"不等于"信号等价"——外链、历史点击数据、抓取预算都按 host 累积，新建子域等于从零建站。
因此判断标准不是"哪个排名更高"，而是内容与主站是否属于同一主题、同一受众。博客作为内容营销的一部分，放在 example.com/blog 能让每篇文章的外链反哺主域；放在 blog.example.com 则是在养第二个站。若博客是独立媒体、面向不同人群、由独立团队运营，子域反而更干净。
工程上有两个必做项：apex 与 www 若同时返回 200，构成重复内容，必须 301 归一，并让 canonical、sitemap、hreflang 三处一致；Search Console 优先用 Domain property（DNS TXT 验证），它覆盖全部子域，而 URL-prefix property 按 host 独立，子域一多就会漏配。
结论：权重集中场景下根域名/子目录更优；内容独立场景下子域可接受。前者是默认，后者是例外。
2. 品牌与用户认知
根域名更短，在口播、印刷、名片、发票、二维码上都有实际优势。现代浏览器的地址栏对 .com 有补全行为，输入 example 常能直达 example.com，www 曾依赖的"自动补全优势"已基本消失。
子域名的价值在于分层。mail.、docs.、status. 已成为用户预期的一部分，用子域承载功能模块能让"这是另一个系统"不言自明。但子域过多会稀释主品牌识别，用户记不住第五个子域。
有个实操细节常被忽略：品牌传播的主机名必须与 canonical 一致。如果对外一直宣传 example.com，落地却 301 到 www.example.com，用户每次都会看到地址栏变化，产生"我是不是进错站了"的迟疑。选哪个都可以，但不能分裂。
结论：主品牌入口用根域名更优；功能型、工具型入口用子域名更清晰。
3. Cookie 与登录态共享
Cookie 的可见范围由 Domain 属性决定。不带 Domain 的是 host-only cookie，只有当前 host 能读写；带 Domain=example.com 的，example.com 及其所有子域都能读写。
这里存在一个方向性不对称，很多人踩过：在 www.example.com 上无法写入对 example.com 可见的 Cookie。Cookie 只能向自身或更深的域写入，不能向父域写入。所以如果主站放在 www，想让 blog.example.com 共享登录态，必须在响应头里显式声明 Domain=example.com，此时这个 Cookie 对 apex 同样可见——共享是双向的，你没法只要一半。
SameSite 的判定基于 registrable domain，a.example.com 与 b.example.com 属于 same-site，因此 SameSite=Lax 的 Cookie 在跨子域请求中仍会携带；但它们依然是 cross-origin，CORS 预检照旧生效。"同站不同源"是子域架构最容易被误判的一点。
安全侧的代价必须算进去：共享父域 Cookie 会放大攻击面。任一子域出现 XSS 或被接管，攻击者就能读写主站会话。对高敏会话（后台、支付），应使用 __Host- 前缀 Cookie——它强制要求 Secure、Path=/、且不允许 Domain 属性，因而只能绑定单一 host，天然阻断跨子域读取。
结论：需要单点登录、跨端购物车、统一登录态时，根域名 + 父域 Cookie 更优；需要强隔离（管理后台、第三方页面）时，独立子域 + host-only Cookie 更优。
4. DNS 解析及 CNAME/ALIAS 限制
根域名不能设 CNAME（原因见第二节）。后果是：apex 无法直接指向 CDN 或托管商提供的 CNAME 目标。现实中的三条出路：
- 写 A/AAAA 记录。把厂商给的 IP 写死。代价是丧失 CDN 的任播调度与自动故障切换能力，厂商换 IP 时你要改 DNS，且 TTL 内的传播窗口无法避免。
- 用 ALIAS / ANAME 记录。这是 DNS 服务商的私有扩展（DNSimple、DNS Made Easy 等支持），行为上像 CNAME 但在响应时展平为 A/AAAA。AWS Route 53 的 Alias 记录是同类能力，但只能指向 AWS 自有资源（CloudFront、ELB、S3 等）。Cloudflare 的做法是在权威解析侧做 CNAME flattening，apex 上填 CNAME 也能正常返回 A 记录。这条路完全依赖解析商能力。
- NS 委派。把整个 zone 的 NS 交给托管商（Cloudflare、Vercel、Netlify 等），由它代管 apex。灵活，但等于把 DNS 控制权交出去。
子域名没有这个约束。www、blog、shop 都可以自由 CNAME 到任意目标，因此可以做蓝绿切换（改 CNAME 指向新环境）、灰度发布（按权重分流）、故障转移（配合低 TTL 与健康检查）。这些能力在 apex 上要么做不到，要么要用更笨的方式模拟。
结论：DNS 灵活性上子域名明确更优。根域名建站的前提是解析商支持 ALIAS/flattening，或你接受 NS 委派——这一点必须在选型第一天确认，而不是上线后才发现。
5. HTTPS 证书配置
example.com 与 www.example.com 是两个不同的 FQDN，一张单域名证书只能覆盖其中一个。要同时服务两者，需用 SAN 证书把两个名字都列进去，或者签两张。
通配符证书 .example.com 只覆盖一级子域，既不含 apex，也不含 a.b.example.com。这是证书配置里最高频的错误：以为买了通配符就万事大吉，结果裸域访问报证书错误。正确做法是 .example.com + example.com 组成一张 SAN 证书。
自动化方面，Let's Encrypt 的 HTTP-01 挑战要求每个 FQDN 单独验证且 80 端口可达；只有 DNS-01 挑战才能签发通配符，代价是需要 DNS 服务商的 API 凭据。子域数量增长时验证目标随之增长，续期失败概率累加——除非收敛到通配符。
还有一个不可逆的运维承诺：HSTS preload。提交 preload 列表必须带 includeSubDomains，一旦 apex 进入列表，该域下所有子域都必须长期提供有效 HTTPS，任何一个子域证书过期都会让它在浏览器里彻底打不开，且从列表移除需要数月。子域多的组织在提交前必须盘点全部子域。
结论：入口少（apex + www）时根域名方案证书更简单；子域规模化时，通配符 + DNS-01 更优，但需接受 DNS API 权限带来的密钥管理负担。
6. 部署与技术栈隔离
子域名是天然的部署边界。blog 跑在 Vercel 的静态生成器，shop 跑在 Shopify，app 跑在 K8s，docs 跑在 GitBook——各自独立的发布节奏、独立回滚、独立运行时，互不牵连。这是子域架构最大的工程价值。
根域名 + 子目录则要求统一入口：需要一层反向代理或边缘路由按 path 分流到不同后端。这层路由规则本身就成了需要版本管理、需要测试、需要 oncall 的代码，任何一条 path 改动都可能影响全局。跨技术栈时还要处理 header 透传、Cookie Path、缓存键设计、多层 rewrite 的调试链路——出问题时你面对的是"Nginx → 边缘函数 → 上游应用"三段日志。
结论：多技术栈、多供应商、多团队时，子域名明显更优；单一应用、以内容为主时，子目录更优，且顺带拿到 SEO 收益。
7. 安全隔离与故障影响范围
同源策略以 scheme + host + port 划分。admin.example.com 与 example.com 是两个 origin，localStorage、IndexedDB、Service Worker 作用域、CSP 的 'self' 全部独立。后台即使被 XSS，也读不到主站 localStorage 里的 token。
但这层隔离会被父域 Cookie 穿透。如果为了 SSO 设了 Domain=example.com，隔离就只剩下存储层，会话层已经打通。所以"子域更安全"这个结论成立的前提是 Cookie 策略配合到位，而不是域名本身带来的。
故障域是另一面。apex 是单点：DNS 异常、证书过期、CDN 配置错误，全站一起挂；子域故障只影响单业务。子域架构把可用性风险切碎了。
但子域也引入了一种特有风险：子域接管（subdomain takeover）。遗留的 CNAME 指向已释放的第三方资源——删掉的 S3 bucket、停用的 SaaS——攻击者可注册该目标并接管整个子域，进而利用父域 Cookie 或 CORS 白名单攻击主站。子域越多、历史越长，dangling CNAME 越多，必须定期扫描。邮件身份同属此维度：DMARC 的 sp= 决定子域是否继承主域策略，未显式配置时子域可能被用于伪造发信。
结论：安全隔离上子域名更优（前提：不共享父域 Cookie、定期审计 CNAME）；单点可用性上子域分担更优，apex 需额外做多 IP / 多 CDN 冗余。
8. 运维复杂度与成本
根域名方案：DNS 记录少，但受 CNAME 限制需要 ALIAS/flattening（部分解析商对此收费），证书要覆盖 apex + www，重定向链路必须正确——http → https → canonical host 最多一跳，多跳会被爬虫和 Lighthouse 同时扣分。
子域名方案：记录数、证书数、监控项、CORS 白名单、CSP 白名单、Search Console 验证全部按 host 线性增长。五个子域意味着五套 TLS 到期监控、五条告警、一张 N×N 的跨域配置矩阵。证书和 flattening 本身已由 Let's Encrypt 与 Cloudflare 免费化，真正的成本是人力与配置漂移——体现在"某天某个子域证书过期，没人知道"。
结论：入口只有 1–2 个时，根域名更省心；业务线超过三条、团队或供应商分离时，子域的边际成本反而更低——因为它把协调成本换成了隔离收益。
9. 后期迁移与扩展难度
迁移成本是不对称的，而且比多数人预估的高。子域迁到根域（或反向）需要：301 映射表、外链更新、Search Console 的地址变更工具、OAuth redirect_uri 白名单、邮件模板链接、第三方回调白名单、Cookie 重设（用户会被强制重新登录一次）。SEO 信号恢复以周或月计，不是以天计。
扩展是另一个方向。新增业务线时，子域加一条记录就能上线，不碰主站；根域 + 子目录要改路由、重新部署、跑一遍回归。但子域的扩展是"分裂式"的：每开一条新子域都从零积累权重，长期看主域权威被摊薄。
结论：业务边界尚不确定、需要快速试错时，子域更易扩展；已确定长期内容资产时，子目录更利于复利。
四、总结与选型建议
把九个维度收拢，可以得到一句判断：
能不能在 apex 上获得与 CNAME 等价的解析能力，决定了默认解的方向。
如果 DNS 解析商支持 ALIAS / CNAME flattening，或你愿意把 zone 委派给 Cloudflare、Vercel 这类平台，默认解是：apex 作为 canonical 主入口，www 301 到 apex。品牌、权重、Cookie 作用域三者天然统一，证书用一张 SAN 覆盖两个名字。
如果解析商不支持、又不愿委派 NS，默认解反过来：www 作为 canonical，apex 301 到 www。这不是妥协，而是把 CNAME 的灵活性换到手——代价是品牌口径要统一到 www，且 apex 必须保留一条重定向用的 A 记录。
两种都是正确解。错误的是第三种：apex 与 www 都返回 200，靠 canonical 标签"告诉"搜索引擎哪个是主站。canonical 是建议，301 才是命令。
选型决策清单
| 场景 | 优先选择 | 依据 | 例外 |
|---|---|---|---|
| 博客 | example.com/blog | 内容营销需反哺主域权重；同主题、同受众 | 独立媒体、独立团队、独立技术栈 → blog.example.com |
| 商城 | shop.example.com | 商城多为独立系统（Shopify/Saleor），发布节奏与主站不同，且支付合规要求隔离 | 商城即主营收入、SKU 页需强 SEO → example.com/shop，但需接受统一入口的运维成本 |
| 管理后台 | admin.example.com | 独立 origin 隔离存储；可单独加 IP 白名单 / mTLS / WAF；robots 禁止收录；Cookie 用 __Host- 前缀不共享父域 | 无例外。后台不应与面向公众的站点同源 |
| 多语言站点 | example.com/zh/、example.com/en/ | 权重集中；hreflang 配置简单；语言切换不需跨域 | 需地区合规、独立结算、独立运营团队 → zh.example.com 或 ccTLD |
| 第三方托管页面（docs / status / help） | 必须用子域名，如 docs.example.com | apex 不能 CNAME，而第三方通常要求 CNAME 做域名归属验证；且需独立证书与独立故障域 | 无例外 |
落地前的六项检查
- 确认解析能力：查解析商文档是否支持 apex ALIAS / CNAME flattening，用
dig example.com实测返回的是 A 还是 CNAME。 - 锁定唯一 canonical：配置单向 301，用
curl -I验证只跳一次，且 http→https→canonical 不出现多跳。 - 证书覆盖核验：
openssl s_client -connect example.com:443 -servername example.com检查 SAN 是否同时包含 apex 与 www；确认通配符没被误当作覆盖 apex。 - Cookie 策略清单：列出所有需要跨子域共享的 Cookie，其余一律 host-only 或加
__Host-前缀；高敏会话禁止Domain=example.com。 - Search Console 用 Domain property：DNS TXT 验证一次覆盖全部子域，避免子域新增后漏配。
- 子域台账与 CNAME 审计：维护子域清单，定期扫描指向已释放资源的 dangling CNAME；DMARC 显式配置
sp=策略。
这六项做完，域名选型就不再是一个"随手填一下"的决定，而是一条可以被验证、被交接、被回溯的架构约束。