清空 sticky_posts 选项最安全：其值存于 wp_options 表，非 post_meta；用 WP-CLI wp option delete sticky_posts 或 SQL DELETE FROM wp_options WHERE option_name = 'sticky_posts' 即可，注意多站点加 --network、缓存需同步清理。
直接清空 sticky_posts 选项最安全
wordpress 的文章置顶状态不是存在每篇文章的 post meta 里，而是统一存放在 wp_options 表的 sticky_posts 选项中——一个序列化数组。批量取消置顶，本质就是清空这个选项值，而不是逐条更新文章。
常见错误是去查 wp_postmeta 表找 _sticky 或类似 key，根本不存在；也有误用 update_post_meta() 去“删 meta”，徒劳无功。
- 执行 SQL：
DELETE FROM wp_options WHERE option_name = 'sticky_posts'; - 或用 WP-CLI（推荐）：
wp option delete sticky_posts - 若用 PHP 直连数据库（如 phpMyAdmin），确认表前缀是
wp_，否则替换成你的真实前缀（如myblog_sticky_posts）
用 WP-CLI 批量操作时注意权限和环境
wp option delete 是最轻量、最可靠的方案，但容易卡在权限或路径上。
- 必须在 WordPress 根目录下运行命令，否则报错
WP-CLI could not find WordPress - 如果站点启用了多站点（Multisite），
wp option delete默认只操作当前站点；要全站清空，得加--network参数：wp option delete sticky_posts --network - 部分托管环境（如 SiteGround、WP Engine）禁用 WP-CLI 写操作，此时只能走 phpMyAdmin 或手动 SQL
别碰 post_status 或 menu_order 字段
有人看到“置顶”就联想排序，试图改 menu_order 或把文章设成 draft 再改回 publish，这完全无效——WordPress 判断置顶只读 sticky_posts 数组，其他字段不参与逻辑。
- 修改
post_status可能意外让文章下线，且不解除置顶 - 更新
menu_order对首页/归档页的“置顶区”毫无影响 - 哪怕把所有文章的
post_meta全删一遍，只要sticky_posts选项还存在，置顶状态就还在
清空后前端不生效？检查对象缓存和 CDN
执行完清除操作，首页可能仍显示旧的置顶列表——这不是数据库没清干净，而是缓存没刷新。
- 如果用了 Redis / Memcached，需清空对象缓存（如 WP-CLI：
wp cache flush） - CDN（Cloudflare、Bunny 等）可能缓存了首页 HTML，需 Purge 页面或设置缓存规则排除
/路径 - 主题或插件自建了置顶缓存（比如把
sticky_posts结果存进 transient），可手动删 transient：wp transient delete --all | grep sticky
真正难搞的永远是缓存层，不是数据库那行 DELETE。
