最可靠的方法是用SQL三表联删，即DELETE a,b,c从wp_terms、wp_term_taxonomy、wp_term_relationships中清除count=0的post_tag记录，执行前须备份并用SELECT预览，避免误删。
直接删数据库最可靠，但必须先备份；用插件或代码批量处理容易漏关联数据或触发缓存异常。
为什么不能只在后台点“删除”标签
WordPress后台的“文章→标签”页面里，点击单个标签的“删除”按钮，只会移除该标签与文章的关联关系，wp_terms 表里的原始记录不会被清除。如果这个标签没被任何文章引用（count = 0），它就变成“幽灵标签”——后台看不见、前台不显示、但依然占着数据库空间和索引资源。
常见错误现象包括：
- 后台标签列表页数异常多（比如 449 页），手动翻页删根本不可行
- 导出数据库时发现
wp_terms表里有几百条taxonomy = 'post_tag'且count = 0的记录 - 使用某些 SEO 插件扫描时提示“存在未使用的标签”，但无法定位来源
用 SQL 直接清理 wp_terms + wp_term_taxonomy + wp_term_relationships
这是最彻底的方式，但必须三表联删，否则会留下孤立记录，下次同步或插件刷新可能报错。
立即学习“前端免费学习笔记（深入）”；
在 phpMyAdmin 或命令行执行以下语句（注意替换你的表前缀，如不是默认 wp_）：
DELETE a, b, c FROM wp_terms AS a LEFT JOIN wp_term_taxonomy AS b ON a.term_id = b.term_id LEFT JOIN wp_term_relationships AS c ON b.term_taxonomy_id = c.term_taxonomy_id WHERE b.taxonomy = 'post_tag' AND b.count = 0;
关键点说明：
- 必须用
DELETE a, b, c同时删三张表，不能只删wp_terms -
b.count = 0是判断依据，它由 WordPress 自动维护，比查wp_term_relationships是否为空更准 - 执行前务必用
SELECT先预览：SELECT a.term_id, a.name, b.count FROM wp_terms a JOIN wp_term_taxonomy b ON a.term_id = b.term_id WHERE b.taxonomy = 'post_tag' AND b.count = 0; - 部分托管环境（如 SiteGround）可能禁用多表 DELETE，此时需分步：先删
wp_term_relationships，再删wp_term_taxonomy，最后删wp_terms
用插件清理比写代码更稳，但要注意兼容性
插件适合不想碰数据库、或需要定期执行的场景。推荐两个经验证的：
-
Better Search Replace：支持按
taxonomy和count条件筛选标签，但本身不提供“删未使用标签”功能，需配合自定义 SQL 或导出后离线处理 -
WP Clean Up：内置 “Delete Unused Tags” 功能，底层仍走 SQL，但做了事务封装和 UI 确认。注意它默认不删
wp_term_relationships中残留的空关系，建议删完再跑一次OPTIMIZE TABLE wp_term_relationships;
不推荐用 functions.php 加钩子自动删标签——wp_delete_term() 函数在循环中调用极易超时，且无法保证事务一致性，中途失败会导致部分删、部分留。
删完别忘了检查和补救
SQL 执行成功后，不代表万事大吉：
- 清空对象缓存（如 Redis / Memcached），否则有些主题或插件仍会从缓存读到旧标签列表
- 检查
wp_term_taxonomy表里是否还有taxonomy = 'post_tag'但term_id不在wp_terms中的“悬挂记录”，如有，用DELETE FROM wp_term_taxonomy WHERE term_id NOT IN (SELECT term_id FROM wp_terms);清理 - 某些 SEO 插件（如 Yoast）会缓存标签权重，删完后需进其设置页点“重新生成 XML Sitemap”或“刷新元数据”
- 如果网站启用了静态缓存（如 WP Super Cache），要手动删掉缓存文件夹下的
tags/目录，否则 404 页面可能被缓存住
