直接修改 post_status 字段风险大，必须同步更新 post_date、post_date_gmt、post_modified、post_modified_gmt 和 post_name 字段，并优先使用 wp-cli 执行发布以确保钩子触发、链接生成和缓存刷新。
WordPress数据库里怎么安全改草稿为已发布
直接改 post_status 字段是可行的，但不能只改这一个字段——否则文章可能出现在前台却没生成 url、不触发钩子、甚至被缓存/cdn 拦截成 404。
UPDATE wp_posts SET post_status = 'publish' 的风险在哪
这条 SQL 看似简单，实际会跳过 WordPress 的完整发布流程。常见后果包括：
-
post_date和post_date_gmt保持原草稿时间，导致文章排序错乱（尤其配合WP_Query的date_query） - 没有触发
save_post、publish_post等钩子，插件（如 SEO 工具、同步到微信、生成静态页）完全无感知 - 如果主题或插件依赖
get_permalink()或wp_get_archives()，可能因缓存未刷新而返回空链接或旧数据 - 多站点环境下，
wp_posts表前缀可能不是wp_，硬写前缀容易出错
真正生效的批量发布 SQL 必须同时更新哪些字段
绕过 PHP 层只能靠补全关键字段，让 WordPress “以为”这是正常发布的文章。核心字段如下：
-
post_status改为'publish' -
post_date和post_date_gmt需设为当前时间（用NOW()，别留空或用旧值） -
post_modified和post_modified_gmt同样设为NOW()，否则 REST API 或 feed 可能忽略变更 - 确保
post_name不为空（否则get_permalink()返回空），可用post_title自动生成：IF(post_name = '', REPLACE(LOWER(post_title), ' ', '-'), post_name)
示例（仅限单站点、默认前缀）：
UPDATE wp_posts SET post_status = 'publish', post_date = NOW(), post_date_gmt = UTC_TIMESTAMP(), post_modified = NOW(), post_modified_gmt = UTC_TIMESTAMP(), post_name = IF(post_name = '', REPLACE(REPLACE(LOWER(post_title), ' ', '-'), '.', ''), post_name) WHERE post_status = 'draft' AND post_type = 'post';
更稳妥的做法：用 WP-CLI 而不是纯 SQL
SQL 是最后手段。如果服务器支持命令行，wp-cli 能走完整 WordPress 流程，自动触发钩子、刷新缓存、生成固定链接：
- 查出草稿 ID：
wp post list --post_status=draft --post_type=post --format=ids - 批量发布：
wp post update $(wp post list --post_status=draft --post_type=post --format=ids) --post_status=publish - 注意：部分托管环境禁用
exec()，此时wp-cli仍比裸 SQL 安全——它会逐条调用wp_update_post()，而非绕过内核
真要用 SQL，务必先备份 wp_posts 表；且上线后立刻访问几篇刚发布的文章，确认 get_permalink() 有值、the_content() 能输出、分类归档页可见——这些才是“发布成功”的真实信号，不是数据库里 status 变了就算数。
