不能直接批量更新所有分类的 slug，因为 wp_terms.slug 修改会跳过 sanitize_title()校验、缓存刷新和重写规则重建，导致404、api失效及后台异常；必须使用 wp_update_term() 走原生流程，并配合 clean_term_cache() 和固定链接刷新。
不能直接批量更新所有分类的 slug —— 因为分类（term）的 slug 存在 wp_terms 表，但它的实际 url 映射和前端行为还强依赖 wp_term_taxonomy 和重写规则。盲目 update 会导致链接 404、分类页失效、rest api 返回空等连锁问题。
为什么不能直接 UPDATE wp_terms.slug？
WordPress 分类的 slug 不是孤立字段：它和 term_id、taxonomy 共同构成唯一标识；而 wp_term_taxonomy 表里存着该分类所属的分类法（如 category、post_tag 或自定义 product_cat），且 WordPress 后台编辑分类时会自动调用 sanitize_title() 生成 slug 并校验唯一性。直接 SQL 修改 wp_terms.slug 会跳过这些校验和缓存刷新逻辑。
- 修改后访问原分类链接返回 404（重写规则未重建）
-
get_term_by('slug', ...)可能查不到或返回错误 term - 后台分类列表里显示异常（比如两个分类 slug 冲突却没报错）
- 对象缓存（如 Redis）或页面缓存（如 WP Super Cache）不会自动失效
安全批量更新分类 Slug 的正确路径
必须走 WordPress 原生函数栈，确保 sanitize_title() 处理、唯一性检查、缓存清理、重写刷新全部触发。核心是用 wp_update_term()，而不是绕过它直改数据库。
- 先用
get_terms()查出目标分类，带上'fields' => 'ids'减少数据载入 - 对每个
$term_id，调用wp_update_term( $term_id, $taxonomy, [ 'slug' => $new_slug ] ) -
$taxonomy必须显式传入（如'category'），不能省略 - 每次调用后检查返回值是否为
WP_Error，避免静默失败 - 操作前务必
wp_cache_flush()或至少clean_term_cache()
示例片段（需放入主题 functions.php 或 mu-plugin 中临时执行）：
// 示例：把所有 category 分类的 slug 全部小写并去空格
$categories = get_terms([
'taxonomy' => 'category',
'fields' => 'ids',
'hide_empty' => false,
]);
foreach ($categories as $term_id) {
$term = get_term($term_id, 'category');
if (is_wp_error($term) || ! $term) continue;
$new_slug = strtolower(str_replace(' ', '-', $term->name));
$result = wp_update_term($term_id, 'category', ['slug' => $new_slug]);
if (is_wp_error($result)) {
error_log("Term {$term_id} update failed: " . $result->get_error_message());
}
}
clean_term_cache($categories, 'category');
如果坚持用 phpMyAdmin（不推荐，仅限紧急修复）
仅适用于极简单场景：所有目标分类都属于同一 taxonomy，且你已确认新 slug 全局唯一、无中文/特殊字符、不与页面/文章别名冲突。操作前必须完成三件事：
- 备份整个数据库（不只是
wp_terms） - 停用所有对象缓存插件
- 执行完 SQL 后立即访问「设置 → 固定链接」并点一次「保存更改」（强制刷新重写规则）
SQL 示例（以 category 分类法为例，注意替换表前缀）：
UPDATE wp_terms AS t JOIN wp_term_taxonomy AS tt ON t.term_id = tt.term_id SET t.slug = LOWER(REPLACE(t.name, ' ', '-')) WHERE tt.taxonomy = 'category';
⚠️ 这条语句不会处理 slug 冲突（比如两个分类名都是 “News & Events” → 都变成 news-events），也不会清理缓存，后续必须人工逐个进后台编辑页点「更新」才能恢复正常。
真正麻烦的不是改字段，而是让整个 WordPress 系统承认这个改动 —— 这一点，任何纯 SQL 操作都做不到。最易被忽略的点：即使你用 wp_update_term() 批量跑完，如果站点启用了 OPcache 且未重启 PHP，旧的 term 对象仍可能从内存中返回。遇到异常时，优先怀疑缓存残留而非代码逻辑。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
