WordPress文章别名(slug)不能为纯数字，这背后涉及到URL解析机制、数据库查询逻辑以及潜在的冲突问题。
核心原因
1.与文章ID的冲突机制
WordPress的核心URL重写规则中，纯数字的slug会被系统优先识别为文章ID而非别名：
WordPress会这样解析：
首先检查123是否是一个存在的文章ID
只有当ID不存在时，才会尝试匹配slug
这导致纯数字slug永远无法被正常访问(或被错误解析)
2.与分页参数的冲突
WordPress使用/page/2/、/feed/等后缀来处理分页和Feed，纯数字slug会与这些结构产生歧义：
wodepress.com/2024/page/2/ ← 正常：2024是年份归档
wodepress.com/123/page/2/ ←冲突：123可能是文章ID或slug
3.附件页面的ID冲突
WordPress媒体附件(图片、文件)也使用ID作为URL结构：
wodepress.com/?attachment_id=123
wodepress.com/123/ ← 如果文章slug也是123，产生歧义
4.数据库查询效率
WordPress的数据库查询优化基于以下假设：
纯数字 WHERE ID = 123 是主键查询，速度极快
字符串 WHERE post_name = '123' 需要全表扫描或索引查找
系统优先按ID查询是为了性能优化。
技术层面的具体限制
重写规则优先级
WordPress默认重写规则优先级
^(0-9{4})/(0-9{1,2})/(0-9{1,2})/(\^/+)/?$ ← 日期结构
^(0-9{4})/(0-9{1,2})/(\^/+)/?$ ← 年月结构
^(0-9{4})/(\^/+)/?$ ← 年结构
^0-9+/?.+$ ← 文章ID结构(最高优先级之一)
当URL为纯数字时，会匹配到文章ID规则，而非slug规则。
wp_unique_post_slug函数
WordPress核心的wp_unique_post_slug()函数会强制处理冲突：
// 位于 wp-includes/post.php
if ( preg_match( '#^[0-9]+$#', $slug ) ) {
$slug = $post_ID . '-' . $slug; // 强制添加ID前缀
}这确保了即使尝试保存纯数字slug，系统也会自动修改为123-456的格式。
为什么这样设计?
| 设计目标 | 说明 |
|---|---|
| 向后兼容 | 早期WordPress使用 ?p=123 结构，需要保持ID访问有效 |
| 性能优化 | 数字ID查询比字符串slug查询快10-100倍 |
| URL唯一性 | 避免wodepress.com/123/ 同时匹配文章ID=123和slug=123 |
| 防止歧义 | 区分 /2024/（年份归档）和 /hello-world/（文章） |
实际影响与解决方案
如果你确实需要"数字"效果
推荐做法：
wodepress.com/post-2024/ ← 添加前缀
wodepress.com/item-10086/ ← 添加业务前缀
wodepress.com/2024-story/ ← 混合数字+文字
不推荐但可行的做法：
// 使用自定义rewrite规则（需谨慎）
add_rewrite_rule('^([0-9]+)/?$', 'index.php?name=$matches[1]', 'top');常见错误场景
| 场景 | 问题 | 结果 |
|---|---|---|
导入数据时强制设置slug为 12345 |
与文章ID冲突 | 自动变为 12345-2 或无法访问 |
使用日期 20240115 作为slug |
被识别为年份归档 | 404错误或跳转到日期页面 |
| 产品SKU纯数字作为slug | 访问时解析为文章ID | 404或错误页面 |
WordPress禁止纯数字slug的根本原因是URL解析的歧义性。这是一个设计层面的限制，而非简单的"规则限制"。它确保了：
文章ID优先解析(性能与兼容)
避免与日期归档结构冲突
保持URL系统的可预测性
因此，在规划WordPress站点的URL结构时，始终建议采用"字母+数字"的混合模式，即使只是添加一个简单的英文前缀，也能完全规避这些问题。
原文