这似乎与redirect_guess_404_permalink() 在的第96行调用wp-includes/canonical.php. 为了测试，我添加了return false; 到的第一行redirect_guess_404_permalink() 这似乎阻止了这种奇怪的行为。我在四处闲逛，但到目前为止我没有看到good 在不编辑核心WordPress文件的情况下解决这个问题的方法（我个人反对在生产环境中这样做，因为这会使核心更新更困难，更容易发生事故）。我希望有一个好的过滤器/动作挂钩可用于redirect_guess_404_permalink 以简化此行为。如果我找到了一个好的解决方案，我会继续戳一点并更新这个答案。

EDIT

Edit (again) 添加了一些逻辑（复制在中完成的检查canonical.php 执行重定向）以检查某些查询参数。没有上次编辑测试的那么好，所以请告诉我它是如何工作的。如果不是100%有效，至少应该让你走上正确的方向（并检查canonical.php).

add_action(\'template_redirect\', \'remove_404_redirect\', 1);
function remove_404_redirect(){
  if (is_404()){
    $id = max(get_query_var(\'p\'), get_query_var(\'page_id\'), get_query_var(\'attachment_id\'));
    $redirect_url = false;
    if ($id && $redirect_post = get_post($id)) {
      $post_type_obj = get_post_type_object($redirect_post->post_type);
      if ($post_type_obj->public)
        $redirect_url = get_permalink($redirect_post);
    }
    if (!$redirect_url)
      remove_filter(\'template_redirect\', \'redirect_canonical\');
  }
}

这里有一个更简单的方法。仅当不存在query\\u vars时才关闭重定向。通过这种方式，我们可以保留功能，而无需复制redirect\\u canonical中已有的逻辑。

add_filter(\'redirect_canonical\', \'no_redirect_on_404\', 10, 2);
function no_redirect_on_404($redirect_url, $requested_url){
    $id = max(get_query_var(\'p\'), get_query_var(\'page_id\'), get_query_var(\'attachment_id\'), 
            get_query_var(\'day\'), get_query_var(\'monthnum\'), get_query_var(\'year\'));
    if (is_404() && !$id){
        return false;
    }
    return $redirect_url;
}