对的，这是可能的。在我的一个插件中，我需要最小的 WordPress 核心（没有插件和主题的数据库），这就是我所做的：
<?php
define('SHORTINIT', true); // load minimal WordPress
require_once PATH_TO_WORDPRESS . '/wp-load.php'; // WordPress loader
// use $wpdb here, no plugins or themes were loaded
The PATH_TO_WORDPRESS我编造的常数；您只需将其指向正确的路径即可。例如，在插件中，它可能看起来像：
require_once dirname(__FILE__) . '/../../../wp-load.php'; // backwards 'plugin-dir/plugins/wp-content'
Setting SHORTINIT to true当然确实对性能有所帮助。
With WP_DEBUG禁用后，启动 WordPress 所需的时间如下：
- 没有 SHORTINIT：~0.045 秒
- 使用 SHORTINIT：~0.0015 秒
如果这是您自己需要性能的站点，您可以通过启用 OpCache（例如最近版本中的 APC 或 PHP OpCache）来稍微提高这一点。
但我相信上面的两行代码定义SHORTINIT并要求wp-load.php就是您正在寻找的。
澄清一下，这个文件是插件的一部分，但它的调用独立于 WordPress 本身（通过 Ajax 和直接）。它永远不会被插件或 WP 本身的任何其他部分包含或使用。
EDIT:由于 OP 实际上关注的是 WP-API，而不是一般的 WordPress，因此我添加此内容是为了解决实际问题。我会保留原来的答案内容，以防对其他人有帮助。
我使用 WP API 进行了进一步测试，就像 @David 在他的回答中所说，问题可能是其他问题。
除了其余 api 之外，我还加载了 12 个插件，一些相当“大”的插件，并且我的本地安装安装了大约 25 个主题（当然有一个是活动的）。我编辑了 WordPress'index.php文件并使用microtime(true)记录一切何时开始，然后编辑其中一个 REST 控制器来计算从开始到到达 API 端点所需的时间。
我的系统上的结果始终围绕0.0462 - 0.0513秒（没有 PHP OpCache，也没有其他系统负载）。因此，引导所有 WordPress 似乎对性能影响很小。
如果请求需要半秒，则瓶颈在其他地方，并且删除插件和主题的影响将很小。至少这是我发现的。
