Well-Known URI 是一种预定义的路径前缀（/.well-known/），让客户端在已知域名的情况下，高效获取站点级信息。robots.txt 是最典型的例子——爬虫无需逐页检查响应头，只需访问一个固定地址即可获知整站抓取策略。然而，这种便利并非没有代价。
为什么有人误用它
设计者常犯两类错误：一是把 Well-Known 槽位当成"官方认证"，似乎注册了就能提升协议可信度和采纳率——实际上它只是一个技术机制，不能为协议本身背书。二是把它当成 URL 缩短工具，仅因协议只能传输主机名就硬套上去。这会锁死服务与站点的 1:1 关系，一旦部署需要扩展到多实例，就不得不新增站点或引入复杂重定向。如果你的协议能直接传完整 URL，别自找麻烦。
常见的设计陷阱
发现机制的域名匹配问题：客户端从 login.example.com 入手时，该去查这个子域还是根域 example.com？协议若未明确说明，不同实现会产生分歧。尤其是那些借 HTTP 之壳实现非 Web 协议的提案，域名架构往往更加灵活，需要提前界定清楚查询起点。
内容元数据的集中化困境：把元数据放在根路径下，多发布者站点（类似早期 /~username/ 模式）就难以使用——要么被排除在外，要么需要复杂的基础设施来管理子用户的权限。这本质上是便利性与精细控制的权衡，很多协议低估了其中的工程成本。
其他值得考虑的细节：如果你的协议已经有固定根路径（如 /.well-known/ 之外的 /robots.txt），需要制定迁移方案才能让已有部署平滑过渡；同时，别默认只有 HTTP/HTTPS，Well-Known URI 同样适用于其他 URL 方案，应在规范中明确列出。
一句话建议：只有"客户端已知站点，需要站点级信息"这个模式真正匹配时，才考虑使用 Well-Known URI；否则很可能是在用复杂方案解决本不存在的问题。
编注：信源为作者亲笔博客，其本人是 Well-Known URI 规范作者兼注册表指定专家，内容为设计实践建议，非规范原文。