Mark Nottingham 最近写了一篇短文，专门劝人别滥用 .well-known。他的身份很关键：RFC 8615 作者之一，也是 IANA Well-Known URI 注册表当前的 Designated Expert。

这不是 IANA 发布新规，也不是 RFC 改口。更像一个长期守在门口的人，看多了协议设计者拿着方案来申请门牌，忍不住把话挑明：.well-known 不是协议的合法性徽章。

它只适合一类很窄的问题：客户端已经知道某个 site，更准确说是 origin，也就是 scheme、host、port 的组合；接下来要发现或交互的，是整个站点级信息。

窄，不是缺陷。窄，才是这个机制能成立的原因。

.well-known 解决的是站点级发现，不是协议背书

最容易讲清的参照是 robots.txt。

它早于 RFC 8615，也不在 .well-known 路径下。但它说明了这类固定位置为什么有用：爬虫已经知道一个站点，只是需要知道全站抓取策略。这个信息天然是站点级的，放在固定位置合理。

.well-known/change-password 也是同一类。客户端已经知道用户所在站点，要找到改密码入口。它发现的是账户体系的站点级交互，不是某个页面、某个业务实例的临时地址。

真正的分界线在这里：客户端是否已经知道 origin？要发现的东西是否作用于整个站点？

用法是否合适关键原因
站点抓取策略合适客户端已知站点，策略作用于全站
改密码入口合适交互对象是站点账户体系
给新协议挂注册名不合适注册项不等于采用率，也不等于合法性
把完整 URL 压成 hostname高风险容易把服务与站点锁成 1:1

这对协议和 API 设计者的影响很直接。

如果你的客户端本来可以拿到完整 URL，就不要为了文档好看，把它压成一个 hostname，再指望 .well-known 补全一切。今天少传一个字段，明天可能多出一整套迁移方案。

平台工程团队也要多问一句：这个 well-known 入口到底代表哪个 origin？谁维护？谁有权限发布？如果这些答案说不清，注册名再漂亮也没用。

误用通常发生在“看起来很标准”的地方

Nottingham 反对的不是 .well-known。他反对的是三种偷懒。

一种是把注册项当合法性。好像进了注册表，协议就更可靠、更官方。现实不是这样。注册表只能减少命名冲突，不能替协议解决部署、治理和采用问题。

一种是把它当 URL 缩短器。协议里不传完整 URL，只传 hostname，剩下靠固定路径拼出来。示例里很清爽，部署时很硬。

还有一种是把它当万能发现机制。服务在哪里、租户在哪里、登录入口在哪里、内容属于谁，全塞进一个固定位置。

麻烦马上出现。

用户从 login.example.com 开始，客户端应该查这个 origin，还是查 example.com？要不要跟随重定向？发布者为了互通，要在哪些 origin 上放文件？

内容元数据也一样。robots.txt 这种全站策略很自然。但很多站点不是单一发布者。老 Web 里有 /~username/，今天也有平台、多租户、托管服务和企业内部系统。

把内容元数据集中到一个 well-known 位置，就等于要求站点管理员替所有发布者处理授权、隔离、审核和同步。协议草图里一行路径，落到组织里就是一串责任。

还有旧路径迁移。像 /robots.txt 这种根路径模式已经存在很久，如果一个协议要迁到 .well-known，就需要过渡计划。不能让实现者靠猜。

如果协议不只跑在 HTTP/HTTPS 上，也要写清楚适用哪些 URI scheme。.well-known 看着像 Web 小工具，实际牵动的是 origin、scheme 和部署边界。

“天下熙熙，皆为利来。”放到标准设计里，就是大家都想用最短路径拿到标准化的好处，却不愿意为部署复杂性付账。

接下来该看什么：别看门牌，看迁移账本

我更在意的不是某个提案能不能注册成功，而是它有没有回答几个土问题。

入口放在哪个 origin？登录子域和主域冲突时听谁的？多租户站点里谁能发布元数据？旧根路径怎么迁？非 HTTP/HTTPS 怎么处理？客户端失败时怎么降级？

这些问题不漂亮，但决定协议能不能活。

铁路早期也有类似问题。大家都想铺轨，真正卡住扩张的，往往不是“有没有铁路”这个口号，而是轨距、调度、换乘和权责边界。不完全一样，但结构相似：基础设施的难处，总会从工程细节里冒出来。

.well-known 的价值也在这里。它不是地基，只是一个约定好的入口。入口能省事，但不能替你设计整栋楼。

对协议/API 设计者来说，动作很明确：

  • 如果问题是站点级发现，并且客户端已知 origin，可以考虑 .well-known。
  • 如果问题是服务发现、租户发现、资源发现，先考虑传完整 URL 或设计明确的发现流程。
  • 如果为了“显得标准”才申请注册名，停一下。注册表不是产品路线图。

对平台和基础设施团队来说，也别只看规范名字。采购、接入或评审一个新协议时，应该盯部署问题：能不能跨子域？能不能多租户？能不能迁移旧路径？能不能解释失败行为？

这些答案比一个固定路径更值钱。

技术标准里最危险的懒惰，往往不是不会设计，而是把固定路径、注册表和“看起来标准化”误当成架构能力。

.well-known 不是过时工具。它是好工具。好工具最怕被拿去证明错误的问题也值得解决。