Slug 到底是什麼，不是什麼
Slug 是 URL 裡那段「人能讀懂」的識別字——例如 `/blog/getting-started-with-typescript` 裡的 `getting-started-with-typescript`。它和頁面標題不是一回事（標題可以很長、帶標點、有大小寫），也不是資料庫裡的內部 ID（ID 對人沒意義）。它處在兩者之間：足夠短，能放進 URL；足夠有意義，讓人不點開就能猜到這個連結指向什麼。理解 slug 在這條光譜上的位置，是寫好它的前提。
為什麼 slug 值得用工具產生，而不是手敲
“把标题小写一下、空格换成连字符”——slug 看起来手敲就够了。但只要标题里出现标点、重音字母、中日韩字符、emoji、CMS 自动转出来的弯引号或者非常规分隔，手敲就开始翻车。Slug 生成器做的是把这件事变成确定的：同样的标题进来，出去的永远是同一个 slug。这件“可重复”的小事，决定了 URL 在多人编辑、脚本生成、数据库导入的多次循环里能不能保持一致——一致才不会出现“同一篇文章两条链接”的事故。
產生器到底做了哪些事情
Slug 生成器本质上是一条很短的文本流水线，每一步都对应一个明确的目的。把它们一一拆开看，你就能预测输出，也能在结果不对时迅速定位问题出在哪一步。
- 整體轉小寫：讓 slug 大小寫不敏感，避免在不同系統裡被歸一化成不同的 URL。
- 把重音字母歸一化：透過 NFKD 分解，`café` 會變成 `cafe`，避免「同一個詞的兩種寫法」指向兩條 URL。
- 删掉 URL 里不安全或容易歧义的字符（引号、斜杠、冒号、括号、emoji），并把连续的分隔符压成一个连字符。
- 去掉首尾连字符，避免 slug 以 `-` 开头或结尾。
- 可选地限制长度：避免从一句长标题直接生成的 slug 超过 URL 规范允许的字符数。
一句話原則：同一句標題，今天和明天、不同裝置、不同編輯器、不同人貼進來，都應該得到同一個 slug。如果做不到，先修流水線，再聊輸出風格。
如何使用這個工具
- 先在 Slug 產生器 中准备一份有代表性的頁面標題、文章名、产品標籤和短语，不要一开始就處理最大或最敏感的真实内容。
- 执行處理流程并產生可複製到路由、CMS 欄位或檔案名中的连字元 slug后，優先檢查音标字元、标点、重复分隔符、保留词和现有 URL 冲突，再判断结果是否真的可用。
- 只有当结果已经適合用于博客 URL、文档路由、产品页、檔案名和 SEO 友好路径，并且不再触发這条风险提醒时，才複製或下载輸出：發布前應檢查最終 slug 是否與现有路由冲突，因為格式干净不代表路径唯一。
Slug 產生器 範例
這個 Slug 產生器 示例使用有代表性的頁面標題、文章名、产品標籤和短语，展示產生后的可複製到路由、CMS 欄位或檔案名中的连字元 slug，便于你先確認音标字元、标点、重复分隔符、保留词和现有 URL 冲突，再把同样設定用于真实輸入。
範例輸入
JSON Formatter & Minifier
預期輸出
json-formatter-minifier幾個常見標題對應的 slug 樣例
标题：Getting Started with TypeScript (2025 Edition)
Slug ：getting-started-with-typescript-2025-edition
标题：Café Recipes — Espresso, Latte & Café au Lait
Slug ：cafe-recipes-espresso-latte-cafe-au-lait
标题：10 Tips: Why Your Site Won't Rank!!
Slug ：10-tips-why-your-site-wont-rank
标题： multiple spaces / and slashes
Slug ：multiple-spaces-and-slashes注意 `&`、連續空白、斜杠、驚嘆號和重音號都被壓平了。Slug 留下的是「讀者一眼能認出來」的詞，剔除了一切會讓 URL 變脆弱的字元。
Slug 在哪些場景裡特別值錢
URL 一旦离开站点（被分享、被收藏、被搜索引擎收录），就很难再改。这也是“slug 起得好”的价值会随着时间发酵的原因——下面这些场景是最典型的“现在多花一分钟，未来少一次重定向”。
- 部落格和文件的 URL：希望它在標題被微調之後仍然能保持穩定，多年不變。
- 电商商品页：`/products/black-running-shoes` 比 `/products/12345` 在被分享时更可信、更可读。
- 知识库或帮助中心文章：经常出现在邮件和工单回复里，一个会“说话”的 slug 比纯数字 ID 友善得多。
- SEO：搜索引擎结果页和用户都会看到 slug，有意义的 slug 对点击率有正向影响。
- 对外可见的 API 资源路径：路径段同时充当公开标识符时（例如 `/teams/marketing/initiatives/2025-q1`），slug 的可读性直接影响接口使用体验。
會在以後「反噬」的 slug 寫法
大多数“slug 后悔事”都不是发布当天的问题，而是几个月后才浮出来：要改 slug、和另一篇撞名、被脚本批量处理时翻车。下面这些是最常踩到的几类坑。
- 把日期或年份塞進 slug（例如 `summer-2024-launch`）：內容如果第二年仍然在用，這條 URL 就立刻顯舊，但又不敢改，改了就要做 301。
- 堆关键词（例如 `buy-cheap-best-running-shoes-online-2024`）：搜索引擎当垃圾内容处理，读者也会瞬间失去信任。
- 改 slug 不配 301：旧链接已经散落在搜索结果、收藏夹、邮件、截图里，悄悄返回 404 的代价不是技术债，是真实流失。
- 用用户输入直接生成 slug 而不做唯一性检查：两条都叫“更新”的内容都想要 `/update`，没有冲突处理逻辑的话，后写的会覆盖先写的。
- 把中日韩内容按字符做拼音/转写：得到的字符串又长又难认，往往不如直接保留原字符（现代浏览器和搜索引擎都已支持），或者让作者手动起一个英文 slug。
- 忽略 slug 会出现在分享卡片里：Twitter/LinkedIn 卡片上的 URL 直接影响“点不点”的判断，内容再好也救不了一条凌乱的 slug。
Slug 與其它「識別頁面」的方式對比
| 識別方式 | 範例 | 強項 | 弱項 |
|---|---|---|---|
| Slug | /blog/getting-started | 可讀、對 SEO 友善。 | 可能撞名，需要唯一性規則。 |
| 數字 ID | /posts/12345 | 永不撞，天然唯一。 | 分享时缺乏上下文，读者只能猜。 |
| Slug + ID 混合 | /posts/12345-getting-started | ID 保证唯一，slug 提供可读性。 | URL 更长，外观偏乱。 |
| UUID | /r/3f1c1e9a-... | 全局唯一，无法预测。 | 完全不可读，不利于分享和复制。 |
使用注意
- 複用可複製到路由、CMS 欄位或檔案名中的连字元 slug前，先檢查音标字元、标点、重复分隔符、保留词和现有 URL 冲突。
- 發布前應檢查最終 slug 是否與现有路由冲突，因為格式干净不代表路径唯一。
- 当结果会影响生产工作或客户可见内容时，應保留原始頁面標題、文章名、产品標籤和短语以便回退和核对。
Slug 產生器 參考說明
Slug 產生器 的参考說明應始终围绕頁面標題、文章名、产品標籤和短语、產生的可複製到路由、CMS 欄位或檔案名中的连字元 slug，以及用于博客 URL、文档路由、产品页、檔案名和 SEO 友好路径前必须確認的檢查点。
- 輸入重点：頁面標題、文章名、产品標籤和短语。
- 輸出重点：可複製到路由、CMS 欄位或檔案名中的连字元 slug。
- 複核重点：音标字元、标点、重复分隔符、保留词和现有 URL 冲突。
參考資料
常見問題
以下問題圍繞 Slug 產生器 的實際用途整理，重點說明輸入要求、輸出結果與常見限制。將標題和短語轉換為適合 URL 的小寫 slug。
Slug 產生器 最適合處理什麼樣的页面标题、文章名、产品标签和短语？
Slug 產生器 的核心用途是把可读標題轉換成小写、適合 URL 的 slug。当頁面標題、文章名、产品標籤和短语需要快速变成可複製到路由、CMS 欄位或檔案名中的连字元 slug，并继续用于博客 URL、文档路由、产品页、檔案名和 SEO 友好路径时，它最有价值。
複用 Slug 產生器 產生的可复制到路由、CMS 字段或文件名中的连字符 slug前，最該檢查什麼？
應優先檢查音标字元、标点、重复分隔符、保留词和现有 URL 冲突。這些细节最能直接判断结果是否已经適合继续交给下游流程。
Slug 產生器 產生的可复制到路由、CMS 字段或文件名中的连字符 slug通常會被帶到哪裡繼續使用？
最常见的下一步就是用于博客 URL、文档路由、产品页、檔案名和 SEO 友好路径。這類輸出是按真实交接場景来组织的，不是泛化占位结果。
什麼時候不應該直接相信 Slug 產生器 的結果，而要人工複核？
發布前應檢查最終 slug 是否與现有路由冲突，因為格式干净不代表路径唯一。