WordPress中WP_Query的post__in参数失效返回多余文章问题求助

1. 优先检查是否有查询钩子拦截修改结果 #

WordPress 核心的 pre_get_posts 或者 the_posts 钩子经常被主题、插件用来全局修改查询结果，哪怕是自定义实例化的 WP_Query 也会被这些钩子命中。尤其是 the_posts 钩子可以直接过滤返回的 posts 数组，这就能解释为什么生成的SQL单独执行是对的，但最终拿到的结果不对——SQL执行完之后结果被钩子篡改了。
排查方式：

• 临时切换到默认主题（比如Twenty Twenty系列），禁用所有插件后再测试代码，如果结果恢复正常，就说明是主题或插件的钩子导致的，逐一启用即可定位出问题的组件。
• 如果不方便直接禁用站点功能，可在你的查询代码前临时移除所有相关钩子的回调，同时给WP_Query添加跳过过滤器的参数，快速验证问题来源：

remove_all_filters('pre_get_posts');
remove_all_filters('the_posts');
// 新增 suppress_filters 参数跳过所有查询相关过滤器
$newStuff = new WP_Query([
    'post__in' => [21757, 9595], 
    'orderby' => 'post__in',
    'suppress_filters' => true
]);

2. 检查是否有粘滞文章干扰 #

WordPress的粘滞文章默认会在查询结果顶部额外插入，哪怕不在post__in的范围内也会被自动追加，是非常常见的post__in查询返回额外结果的原因。你可以在查询参数里显式关闭粘滞文章的特性：

$newStuff = new WP_Query([
    'post__in' => [21757, 9595], 
    'orderby' => 'post__in',
    'ignore_sticky_posts' => true
]);

3. 确认是否存在多语言/内容管理插件的ID映射逻辑 #

如果站点用了WPML、Polylang这类多语言插件，或者Duplicate Post这类内容复制插件，可能存在ID自动映射、多语言关联文章自动追加的逻辑，也会导致返回的结果超出你指定的ID范围，配合前面的 suppress_filters => true 参数测试就能验证是不是这类插件导致的。

4. 验证查询对象的实际匹配参数 #

你可以直接打印 $newStuff->found_posts 查看实际SQL匹配到的文章数量：

• 如果这个值是2，但$newStuff->posts长度是6，100%是the_posts钩子或者插件修改了结果数组
• 如果found_posts也是6，就需要检查你传入的post__in数组在实例化WP_Query前是不是被其他逻辑额外追加了其他ID。

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