URL 里那个自增 ID 暴露了家底：目录站条目 ID 的三种生成方式
U
有次看一个同行的目录站，随手把条目 URL 末尾的数字改大一位，跳转到一个还没公开的待审条目页。他不知道自己泄露了两件事：库存规模，以及未发布内容。
图片来源：网络，版权归原作者所有，侵权请联系删除
自增 ID 的三个问题
| 问题 | 具体后果 | 严重程度 |
|---|---|---|
| 暴露规模 | 任何人都能推算出站点条目总数和更新速度 | 低，但同行都在看 |
| 可被遍历 | 写个循环就能拉全站，包括未公开页面 | 中，取决于权限校验 |
| 迁移困难 | 换数据库或合并两个站时，ID 冲突无法避免 | 高，改一次伤筋动骨 |
前两条可以通过权限校验和限流缓解，第三条基本没法缓解。两个目录站合并，两边都有 ID 为 10234 的条目，只能给其中一边做全量映射。
三种方案各自解决什么
| 方案 | 形态 | 优点 | 代价 |
|---|---|---|---|
| 自增 ID | /item/10234 | 实现最简，排序与分页天然有序 | 上面三条全占 |
| 哈希或随机 ID | /item/k3f9wq2x | 不可推算、不可遍历，迁移易合并 | 不可读，调试和日志排查不直观 |
| 语义 slug | /item/beijing-rental-tools | 可读，标题里有关键词 | 条目改名要 301，重名要加后缀 |
哈希 ID 通常用 hashids 这类库把数字映射成短字符串，可双向转换，数据库里仍然存自增主键，只是对外不暴露。这个方案对现有代码改动最小，只需要在生成链接和解析链接两头各加一层。
slug 方案要注意一点：条目名称变了不要随便改 slug。改名就换地址，等于主动制造一次全站 301。可以在 slug 里只放一个稳定的标识（比如域名主体），避免随描述文字变动。
和别名、语言选择是两件事
很多人把 ID 方案和「用中文还是拼音」搞混了。语言选择说的是 slug 里写什么文字，ID 方案说的是这个标识是连续的、随机的还是语义的。两者可以组合：用中文 slug，也可以用哈希 ID，互不冲突。
真正需要提前决定的是 ID 方案，因为它一旦上线就很难改。语言选择错了，改几个 slug 加 301 就行；ID 方案错了，全站地址都要变。
老站值不值得改
直接说结论：已经收录良好的老站，不要改。
改 ID 意味着全站地址变化，你需要一张完整的旧新映射表，每条旧地址 301 到新地址，重定向至少保留一年，sitemap 全量替换，还要接受短期内排名和收录的波动。这笔账算下来，换到的只是「别人猜不出你有多少条目」。
值得做的是补两块：给未公开页面加真正的权限校验（不能只靠 ID 不暴露），以及对异常高频的顺序访问做限流。这两件事几小时能做完，能解决自增 ID 里最实际的那条风险。
新站开局就选哈希 ID，成本几乎为零；老站别动，把精力花在权限和限流上。改地址的收益远小于它的代价。
新站如果选了 slug，记得提前定一条规矩：slug 只由稳定的标识生成，不随条目名称或描述变化。这条规矩写进代码，比写在文档里有用。