可行但风险高，必须同步更新post_date、post_date_gmt等时间字段并触发wordpress钩子，否则文章仍不显示或出现404；推荐用wp_update_post()或wp-cli而非直接sql操作。
直接改 wp_posts 表的 post_status 字段可行吗
可行，但风险高——post_status 只是状态标识，wordpress 还依赖 post_date、post_date_gmt、post_modified 等字段协同判断发布时间和可见性。单纯把草稿（draft）改成 publish，文章可能仍不显示在首页或归档页，甚至被缓存/搜索引擎忽略。
常见错误现象：SELECT * FROM wp_posts WHERE post_status = 'publish' 能查到，但前台访问 404 或返回空内容；后台编辑时状态又自动变回 draft。
- 必须同步更新
post_date和post_date_gmt，否则 WP 认为“发布时间未来”而屏蔽 -
post_modified和post_modified_gmt也建议设为当前时间，避免 RSS 或 REST API 返回异常时间戳 - 如果文章有自定义字段（如
_yoast_wpseo_metadesc），状态变更不会触发 SEO 插件重生成逻辑，需手动刷新或调用钩子
安全批量更新的 SQL 写法（含时间校准）
执行前务必备份数据库；推荐在 phpMyAdmin 或命令行中分步验证，不要一次性全表更新。
示例：将 ID 在 100–200 之间、当前为 draft 的文章转为已发布，并修正时间戳：
UPDATE wp_posts SET post_status = 'publish', post_date = NOW(), post_date_gmt = UTC_TIMESTAMP(), post_modified = NOW(), post_modified_gmt = UTC_TIMESTAMP() WHERE ID BETWEEN 100 AND 200 AND post_status = 'draft';
注意点：
-
NOW()和UTC_TIMESTAMP()必须成对使用，否则时区错位会导致 WP 后台显示发布时间异常 - 不要用
WHERE post_status = 'draft'全表扫描，容易锁表；加ID范围或post_author条件缩小范围 - 执行后立即检查几条记录的
post_date_gmt是否为当前 UTC 时间（不是本地时间），这是最常踩的坑
为什么不能跳过 wp_update_post() 直接操作数据库
因为 WordPress 的发布流程不只是改一个字段：它会清理对象缓存、触发 save_post 钩子、通知搜索引擎、更新文章计数器（如 wp_statistics 插件）、刷新重写规则（尤其是启用了自定义结构时）。
如果你有少量文章要处理，更稳妥的做法是用 WP-CLI：
wp post update 123 --post_status=publish --post_date=$(date -u +"%Y-%m-%d %H:%M:%S")
或写个临时 PHP 脚本（放在 WP 根目录下运行）：
<?php require_once('wp-load.php');
$ids = [123, 456, 789];
foreach ($ids as $id) {
wp_update_post([
'ID' => $id,
'post_status' => 'publish',
'post_date' => current_time('mysql'),
'post_date_gmt' => current_time('mysql', 1)
]);
}
这样能确保所有钩子和缓存机制正常响应，尤其适合启用 Redis 或 OPcache 的站点。
插件或缓存导致状态“看起来没变”的排查路径
即使数据库字段已更新，前台仍看不到文章，大概率是缓存层或插件拦截了状态判断。
- 禁用所有插件，切换默认主题，测试是否生效——重点排查 SEO 类（Yoast、Rank Math）、缓存类（WP Super Cache、LiteSpeed）、会员权限类插件
- 检查
wp_options表中rewrite_rules是否过期，可进入后台「设置 → 固定链接」点一次“保存更改”来刷新 - 某些 CDN（如 Cloudflare）会缓存 404 响应，清空 CDN 缓存并确认源站返回的是 200
- 多站点环境下，确认操作的是正确站点的
wp_posts表（如wp_2_posts），而不是主站表
时间字段的 GMT 对齐、钩子未触发、缓存未刷新——这三点漏掉任何一个，都会让“改完就生效”变成“改了但像没改”。
