URL 不只是浏览器地址。了解稳定、可预测的 URL 如何服务分享、文档、脚本和产品体验。

好的 URL 设计为什么重要？把链接当作产品的一部分

URL 是网络上的通用语法：它可以出现在浏览器、脚本、书籍脚注、二维码和设备按钮里。好的 URL 应该让人看得懂、让程序用得稳，并在页面标题小幅调整后依然有效。它不会单独决定搜索排名，却会影响链接被分享、引用、调试和长期维护的方式。

Kyle Aster 在 2010 年谈 URL 设计时提醒读者，不要把 URL 只理解成地址栏里的文字。这个观点的重点不是某种固定格式，而是把 URL 当作离开页面后仍然有意义的公开接口。

URL 会被复制、引用，也会被程序调用

一个链接可能被粘贴进邮件、知识库、实体书的注释、客服工单或海报上的二维码。开发者还会在 curl、wget、脚本和系统集成中直接使用它。用户未必总能看到页面标题和导航，因此 URL 本身需要提供足够的方向。

/guides/url-design 让人知道目标大致讨论什么；/page/1847 只对内部数据库有意义。可读并不意味着把整句标题塞进路径，而是用少量稳定词语表达资源主题。

Stack Overflow 的问题地址长期采用类似 /questions/:id/:slug 的结构。id 是服务器定位问题的稳定标识，slug 是给读者看的主题描述。省略 slug 时，系统仍可以根据 ID 找到问题；题目稍后修改，也不必因此更换地址。

/questions/16245767
/questions/16245767/creating-a-blob-from-a-base64-string-in-javascript

这是一种很实用的分工：机器依赖稳定 ID，人依赖可读描述。slug 不应成为唯一事实来源，也不应允许随意改词后把同一个 ID 解释成另一篇内容。对长期公开内容，ID + slug 往往比完全依赖标题更有韧性。

GitHub 的比较页面使用类似 /:owner/:repository/compare/:ref1...:ref2 的结构。熟悉 GitHub 的人可以从地址读出仓库和比较范围，不必先打开界面再寻找功能。

npm 的包页面也把包名和版本体现在路径中。开发者知道资源属于哪个包、哪个版本后，可以直接构造目标地址。这种可预测性是技术产品的便利：URL 不只是页面的结果，也成为浏览产品的一种方式。

设计路径时，应先把用户理解的对象表达出来。例如文章、作者和标签可以分别使用 /articles/:slug、/authors/:name、/tags/:tag。不要把框架控制器、数据库表名或临时页面状态直接暴露成公开结构。

Slack 曾用 /is/team-communication 一类路径延续“Slack is...”的营销叙事；个人网站也可能用一个有个性的词代替传统的 /about。少量稳定页面使用这种表达，可以让品牌语气延伸到地址本身。

但帮助文档、定价页、商品目录、后台和 API 更需要可预测。/docs、/pricing、/contact 这类入口已经足够明确。品牌化路径应该是清晰结构之上的表达，而不是让用户猜测页面含义的谜语。

假设文章标题是“当链接会被复制到文档、二维码和脚本里时，网站 URL 应该怎样设计才更好用？”。它适合做标题，却不适合逐字进入地址。

urlslug.im 可以帮助从长标题中提炼英文主题词和词序。- 与 _ 的替换、统一和显示由前端规则负责；是否准确、唯一、值得长期保留，仍然是编辑和产品团队的判断。

先问资源是否稳定，再问地址是否可读；先保证同类路径一致，再讨论品牌语气；先设计迁移方案，再决定是否替换旧 URL。这样可以避免为了几个更漂亮的词，破坏已经被引用的公开接口。

好的 URL 不一定最短，也不一定最有创意。它应该能让陌生读者获得方向，让熟悉用户快速定位，让程序在多年后仍能调用。把这三个目标放在一起，URL 才真正成为产品的一部分。