这篇文章由Well-Known URI规范的作者撰写，总结了使用该规范的最佳实践。核心观点是：Well-Known位置最适合客户端（如浏览器或爬虫）在已知网站时，高效发现关于整个站点的信息，例如robots.txt的访问策略。

作为《Well-Known URI规范》的作者之一及当前注册表指定专家，我经常收到关于如何正确使用这些URI的咨询。以下是我总结的最佳实践要点，但请注意这些并非注册的硬性要求。

适用场景 Well-Known位置最适合客户端（浏览器、爬虫等）已知目标站点，且需要高效获取全站信息时使用。典型例子是robots.txt——虽然它早于RFC标准，但正是这类需求催生了Well-Known URI的预留空间。爬虫通过单一中心位置获取站点访问策略，避免了逐条检查响应头部的低效操作。这类机制不限于策略文件，任何需要客户端已知站点后获取全局信息或交互的场景都适用，比如change-password端点。

不适用场景 部分协议设计者存在滥用倾向：将注册Well-Known位置视为提升合法性的手段，或误以为注册表席位能带来采用率。实际上，Well-Known位置只解决特定问题（客户端已知站点+需要全站信息）。若协议不存在该需求，注册反而会制造新问题。另一种常见误区是将其用作URL缩短器——协议中仅传递主机名，由Well-Known位置补全路径。这种模式会强制服务与站点形成1:1绑定关系，当需要多服务部署时，必须创建新站点并设计用户引导方案。如果协议能承载完整URL，就不应使用Well-Known位置。

常见陷阱与权衡 1. 发现机制错位：当用户交互范围与发现范围不匹配时，例如客户端从"login.example.com"发起请求，却需要查询"example.com"的Well-Known位置。非Web场景的协议更需谨慎，比如指定注册域名的Well-Known位置在根域，可能给运维带来困难。 2. 内容元数据困境：多发布者站点（如传统/~username/模式）将元数据集中化，要么限制用户使用，要么迫使管理员开发复杂基础设施。这需要在便利性与粒度之间权衡，往往需要并行设计HTTP响应头等替代元数据机制。

其他注意事项 - 已有固定根路径（如/robots.txt）的协议需制定过渡方案 - 明确枚举支持的URL协议（不限于http/https） - 务必通过官方注册流程完成注册，该指南直接影响注册成功率

（注：文中"站点"在技术层面指代由scheme、host、port构成的"源"）

根据评论内容，主要观点和论据如下：

支持标准化路径的观点（评分：None）： - 评论2（reddalo）支持遵循.well-known标准，反对在根域名下创建新标准，如"llms.txt"。关键引用："I wish people would follow this, instead of coming up with new standards in the root namespace." 和 "Let's stop polluting the root of a domain!"

质疑标准实用性的观点（评分：None）： - 评论1（jvuygbbkuurx）认为标准过于具体，建议自定义规范。关键引用："Why are they so specific?" 和 "Seems like a waste of time. I would just define my own spec outside of well known for my use case." - 评论4（sandblast）批评文章缺乏实质内容，没有实际建议。关键引用："It feels like it's about nothing, there is no substance" 和 "Without examples that lead to some real recommendations, this whole expertise claimed by the author is of no use."

其他关注点（评分：None）： - 评论3（einpoklum）质疑这些URI的知名度："How well-known are those URIs though?" - 评论6（jiggunjer）指出标题与内容不符："Title says uri but post only about urls, a type of uri" - 评论7（user3939382）希望有导航布局标准："I wish we had one for navigation layout of a site" - 评论8（momoraul）认为.well-known已变成"杂物抽屉"："became the junk drawer of the web root"

总结：评论者对.well-known标准存在分歧。支持者认为应遵循标准避免污染根域名；反对者认为标准过于具体、缺乏实用性，或已变得杂乱。部分评论关注技术细节（URI与URL区别）和实际应用需求（如导航布局）。