Note: this is an incomplete answer which will be expanded upon incrementally

---

在多站点中刷新重写规则的唯一可靠方法是在给定的上下文中刷新重写规则，如：

global $wp_rewrite;
$wp_rewrite->init(); //important...
$wp_rewrite->flush_rules();

以上内容确保在构建重写规则和提交对数据库的更改之前，检索并设置给定上下文的正确permalink结构。

这不适用于上下文无关紧要的单个站点，因为只有一个上下文。

flush_rewrite_rules() 在我看来，它有缺陷的前提是它假定了正确的上下文，但没有考虑到我们使用switch_to_blog 这完全改变了环境，如果我们试图冲破规则，就可能让我们陷入危险的境地。

这就是flush_rewrite_rules() 看起来像：

function flush_rewrite_rules( $hard = true ) {
    global $wp_rewrite;
    $wp_rewrite->flush_rules( $hard );
}

我想不出为什么它不应该是这样：

function flush_rewrite_rules( $hard = true ) {
    global $wp_rewrite;
    $wp_rewrite->init(); //hello....
    $wp_rewrite->flush_rules( $hard );
}

。。。特别是当你考虑到WP_Rewrite 做什么？它可以做到这一点。。。

public function __construct() {
    $this->init();
}

谈到你的第一个关注点，以进一步推进这一思路，

那么插件如何可靠地刷新重写规则呢multisite:

创建新站点时，是否为该站点

首先wpmu_create_blog()install_blog() 依次调用populate_options()populate_options() 设置选项表中的默认永久链接结构install_blog() 已运行，wp_install_defaults() 然后被呼叫wp_install_defaults() 刷新新创建站点的重写规则，然后通过restore_current_blog().wp_install_defaults() 完全按照我上面的建议刷新规则：

$wp_rewrite->init();
$wp_rewrite->flush_rules();

。。。因为只有这样才能确保permalink_structure 规则是为当前上下文构建的。

此外，在Github issue, 用户出现以下行为的原因：

创建新站点时，它仅在顶级站点上打破后级别永久链接-在大多数永久链接配置中，但不是所有配置中：

这两种格式工作正常。

默认-按预期工作

天（&；N）；名称-按预期工作

。。。是因为如果主博客有一天；名称permalink结构/%year%/%monthnum%/%day%/%postname%/, 创建新站点时，它也有一天&；名称permalink结构/%year%/%monthnum%/%day%/%postname%/ 默认情况下，这就是为什么Yoast SEO插件在shutdown 钩