如何在Must Use插件中获取Post ID与Post Type？

我之前也碰到过MU插件里调用get_the_ID()、get_post_type()这类函数返回false的情况，核心原因就是MU插件加载得太早了——WordPress还没完成文章对象的初始化，那些依赖全局$post对象的函数自然拿不到有效数据。下面分享几个靠谱的解决思路：

1. 挂钩合适的动作钩子（最推荐） #

MU插件会在plugins_loaded钩子之前就完成加载，这时候WordPress的文章查询和全局对象都还没准备好。你需要把获取文章数据的逻辑延迟到WordPress初始化完成之后执行，常用的钩子有这些：

• wp：WordPress完成核心初始化后触发，适合大多数后台/前台场景
• template_redirect：前台模板加载前触发，适合仅需在前台执行的逻辑
• the_post：文章对象被设置后触发，适合单篇文章相关的操作

示例代码：

add_action('wp', function() {
    // 先判断当前是否为单篇文章页面，避免在列表页或其他页面报错
    if (is_singular()) {
        $post_id = get_the_ID();
        $post_type = get_post_type($post_id);
        
        // 在这里处理你的业务逻辑
        if ($post_type === 'product') {
            // 比如针对产品类型文章做一些操作
        }
    }
});

2. 直接访问全局$post对象（需谨慎） #

如果你的逻辑需要在稍早的时机执行，也可以直接检查并访问全局$post对象，但一定要确保它是有效的WP_Post实例：

add_action('plugins_loaded', function() {
    global $post;
    // 先验证对象有效性，避免出现错误
    if ($post instanceof WP_Post) {
        $post_id = $post->ID;
        $post_type = $post->post_type;
    }
});

⚠️ 注意：这种方式只在$post对象已经被初始化的场景下有效，比如直接访问单篇文章页面时，在列表页或后台可能无法拿到正确数据。

3. 关于直接查询数据库的效率问题 #

直接查询数据库确实能绕开WordPress的函数限制，但我非常不推荐作为首选方案：

• WordPress内置了对象缓存机制，使用官方函数会自动利用缓存，减少数据库查询次数；直接查DB会跳过缓存，增加数据库负载
• 直接写SQL语句容易出现安全问题（比如SQL注入），需要手动处理参数转义，而$wpdb的prepare方法虽然能缓解，但还是不如官方函数安全

如果真的遇到极端场景必须用DB查询，示例代码如下（尽量依赖WordPress的查询变量来定位文章）：

global $wpdb, $wp_query;
// 从查询变量中获取文章ID，比通过URL或guid查询更可靠
if (isset($wp_query->query_vars['p'])) {
    $post_id = (int)$wp_query->query_vars['p'];
    $post_type = $wpdb->get_var($wpdb->prepare("SELECT post_type FROM {$wpdb->posts} WHERE ID = %d", $post_id));
}

总结 #

优先选择「挂钩合适的动作钩子」的方案，这是最稳妥且高效的方式，既符合WordPress的开发规范，又能避免不必要的性能损耗。直接查询数据库只作为万不得已的备选方案。

内容的提问来源于stack exchange，提问作者Roel Magdaleno