自定义域名和 HTTPS，几乎不用碰 DNS

自定义域名把人吓跑完全是没道理的事。真正重要的记录就那么几条，有一个合理的添加顺序，再加上 一个所有人第一次都会栽进去的 apex 坑。学一次，以后你就再也不用为它操心了。

它大概长什么样

每个现代托管平台——Cloudflare Pages、Vercel、Netlify——工作方式都一样：在控制台里添加域名 （它会显示”待处理”），把一条 DNS 记录指向托管平台的目标地址，然后托管平台就会**自动为你 签发 TLS 证书。**不用 nginx，不用 certbot，也不用到处复制证书文件。

托管平台的目标地址只是一个你要指向的主机名：

行得通的顺序

1. 先添加域名——在托管平台控制台里先加，这样它才知道要等这个域名。
2. www 很简单——加一条从 www 指向上面那个托管目标的 CNAME。
3. **apex 才是那个坑。**你不能在裸域名（example.com）上直接放一条原始 CNAME——这违反 DNS 规范。改用你的 DNS 服务商的 CNAME flattening（Cloudflare 会自动做这件事），或者一条 ALIAS / ANAME 记录。
4. 挑一个规范地址（canonical）——把 www → apex 或 apex → www 做重定向，不要两个都同时上线。 一个家，一个 URL。
5. 等待校验，然后在你开香槟之前先确认它能通过 HTTPS 解析。证书通常几分钟内就会到位。

人们会忘掉的两件事

• apex 和 www——两个都设好，然后把其中一个重定向到另一个。跳过这一步，就是为什么 example.com 能用、但 www.example.com 报证书错误（或者反过来）的原因。
• 邮箱和域名共用——你在 example.com 上的应用和同一域名上的邮箱可以好好共存；只要别在 捣鼓的时候顺手删掉 MX 记录就行。

结论

这是个 10 分钟的活儿，不是一个 DevOps 项目：添加域名、给 www 加一条 CNAME、给 apex 用 flattening/ALIAS、挑一个规范地址、确认 HTTPS。证书现在是托管平台的事了——这本来就该如此。 应用搞好了但还没弄域名？那就看看完整的部署路径。