第一次做网站时，人们通常先想页面长什么样、要放哪些内容，很少有人愿意先研究域名。域名看起来只是浏览器地址栏里的一串字符，注册页面也很像一次普通购物：搜索、付款、完成。
但网站真正运行起来以后，会发现域名可能是整套系统里最稳定、也最不应该频繁更换的部分。
页面可以重做，服务器可以迁移，框架可以替换，甚至整套程序都可以推倒重来。只要域名仍在，读者访问网站的入口、搜索引擎积累的记录、对外留下的链接和邮箱地址，就可以继续存在。
所以，注册域名不是给网站买一个门牌，而是在互联网上确定一个长期身份。
一、好域名首先要经得起长期使用
选择域名时，最容易掉进两个极端。
一个极端是只追求“看起来很酷”，加入生僻拼写、连字符、数字或当下流行的词；另一个极端是希望域名把网站的所有功能都解释清楚，最后变得又长又难记。
我更愿意用四个问题来筛选：
- 能不能自然地读出来？
- 听到以后，能不能大致拼对？
- 三年以后，网站方向变化了，它是否仍然适用？
- 写在名片、邮件地址和浏览器标签上，是否仍然简洁？
Mullwise 并不直接描述某一种具体业务。它来自 “mull it over” 和 “wise” 的联想：反复思量，再形成判断。这个含义足够明确，又没有把网站限制在某一项技术或某一种内容里。它可以容纳研究笔记、文章、工具和以后尚未出现的项目。
这类名字的价值，不在于第一次看到就能解释所有事情，而在于它能随着内容逐渐获得自己的含义。
二、后缀不是装饰，而是一种预期
同一个名字常常有许多后缀可选，例如 .com、.net、.org，以及各种新后缀。
新后缀有时更短，也更容易找到尚未注册的名称。但如果网站要长期公开使用，.com 仍然有一个朴素的优势：多数人会下意识地把一个品牌名称和 .com 联系起来。口头传播时，它也几乎不需要额外解释。
这不意味着所有项目都必须选择 .com。非营利组织、开源项目、地区服务或特定行业，完全可能有更合适的后缀。真正需要避免的是：只看第一年的低价，没有查看续费价格；只看名称是否可注册，没有确认这个后缀是否会给访问者带来误解。
域名的费用不是一次性的购买，而是持续续期。注册前至少要看清四件事：
- 首年价格和正常续费价格是否相差很大；
- 是否支持自动续费，以及扣款失败后如何提醒；
- 是否提供注册信息隐私保护；
- 域名转出是否方便，有没有额外限制。
价格会变化，促销也会结束。比起省下一次小额费用，稳定的续费机制和清楚的管理权限更重要。
三、注册商、DNS 和网站托管不是同一件事
这是域名配置中最值得先弄明白的关系。
注册商负责记录“这个域名属于谁”；DNS 负责回答“这个域名应该去哪里”；网站托管平台负责真正提供页面和程序。
它们可以来自同一家公司，也可以完全分开。
text
域名注册商
↓ 记录所有权与 Nameserver
DNS 服务
↓ 指向网站、邮箱和其他服务
网站托管平台
↓ 返回页面与数据
访问者浏览器Mullwise 的做法是：保留原来的域名注册商，把权威 DNS 交给 Cloudflare，再把网站部署在 Cloudflare Pages 上。这样，域名所有权、DNS 管理和网站部署的职责是清楚分开的。
将来如果更换托管平台，只需要修改 DNS 或自定义域名绑定；域名本身不必转移，公开地址也不必改变。
四、Nameserver 决定谁拥有最终解释权
把域名接入 Cloudflare 时，最关键的一步不是添加某条 A 记录或 CNAME，而是更换 Nameserver。
Nameserver 可以理解为这个域名的“权威通讯录”。浏览器要寻找 mullwise.com 时，会沿着 DNS 系统一路查询，最终向权威 Nameserver 询问答案。只有它保存的记录，才是这个域名当前的正式配置。
完整接入通常是这样的：
1. 在 Cloudflare 中添加根域名；
2. 检查 Cloudflare 扫描或导入的现有 DNS 记录；
3. 复制 Cloudflare 分配的两条 Nameserver；
4. 回到域名注册商，用它们替换原来的 Nameserver；
5. 等待 Cloudflare 确认域名已经激活。
Nameserver 必须逐字复制，并删除多余的旧服务器。Cloudflare 官方也建议在切换前检查现有 DNS 记录，因为网站、邮箱验证和其他子域名可能都依赖这些记录。
这里最常见的误区，是在 Cloudflare 中配置了一切，却忘了在注册商处更换 Nameserver。此时 Cloudflare 页面看起来已经准备好了，但全世界仍然在询问原来的 DNS 服务，自然不会得到新的答案。
五、切换 DNS 前，先给自己留一条退路
DNS 修改通常不是危险操作，真正危险的是不知道旧配置里有什么。
在更换 Nameserver 之前，我会先保存三类信息：
- 当前 Nameserver；
- 所有 DNS 记录的截图或导出文件；
- 邮箱、网站验证、第三方服务使用的 TXT、MX、CNAME 记录。
如果网站已经在运行，还应当记录原站点的访问地址。这样即使新配置出现问题，也能迅速恢复旧 Nameserver，或者补回遗漏的记录。
DNS 的变化还需要传播时间。不同网络、运营商和本地缓存更新速度并不完全一致。某一台电脑能访问、另一台暂时打不开，并不一定说明配置相互矛盾；它可能只是仍在使用旧缓存。
排查时应该依次确认：域名拼写是否正确、Nameserver 是否完全匹配、记录是否存在、代理状态是否合适、证书是否已经签发。先检查这些事实，比反复修改配置更有效。
六、根域名和 www，最好尽早决定主地址
mullwise.com 和 www.mullwise.com 是两个不同的主机名。它们可以同时指向同一个网站，但不应该长期各自独立工作。
更清楚的做法是选择一个主地址，另一个永久重定向过去。Mullwise 以根域名为主：
text
www.mullwise.com → https://mullwise.com这样，读者不会在两个地址之间犹豫，搜索引擎也不会把同一份内容当成两套页面。站内链接、分享链接和 canonical 地址都统一使用根域名。
七、HTTPS 是默认要求，不是上线后的附加项
域名能够解析，只代表浏览器找到了服务器；HTTPS 正常，才代表连接经过加密，并且浏览器能够验证网站身份。
接入 Cloudflare 和托管平台后，证书通常可以自动签发。但自动不等于永远不需要检查。上线时至少要验证：
http://是否自动跳转到https://；- 根域名和
www是否都拥有有效证书； - 页面是否加载了不安全的 HTTP 图片或脚本；
- Cloudflare 与源站之间是否也使用加密连接。
如果域名之前启用了 DNSSEC，更换 Nameserver 前还要留意原有 DS 记录。旧的 DS 信息与新的 DNS 服务不匹配时，解析可能直接失败。稳妥的做法是按服务商指引完成切换，再重新启用 DNSSEC。
八、真正需要保护的是域名管理权
页面代码丢了，可以从备份恢复；服务器坏了，可以重新部署。域名账户失去控制，影响会大得多。
因此，域名安全至少应包括：
- 注册商与 Cloudflare 都启用双重验证；
- 使用独立、不可复用的强密码；
- 打开自动续费，并保留有效的备用付款方式；
- 确保注册邮箱长期可用；
- 不把主账号、API 令牌或恢复代码放进网站代码；
- 非转移期间保持域名锁定。
API 令牌也应遵循最小权限原则：只允许访问需要操作的域名和功能，用完即可撤销。方便不应该以永久暴露管理权限为代价。
九、注册完成，只是建立了入口
域名注册完成后，网站仍然可能什么都没有。它只是拥有了一个可以长期使用的地址。
接下来要做的，是把这个地址接入 DNS，将 DNS 指向托管平台，为根域名和 www 建立明确关系，等待 HTTPS 证书生效，再从不同设备和网络验证访问结果。
回头看，域名配置里没有哪一步特别复杂。真正容易出错的，是同时在注册商、DNS 平台和托管平台之间切换，却没有先弄清每一层负责什么。
我现在更愿意把域名理解为一种长期承诺：名字一旦公开，就尽量不轻易更换；权限一旦交给某个平台，就要知道怎样收回；每一次配置修改，都应该留下能够回退的记录。
页面会不断变化，域名最好安静地留在那里。