Autoload：测量随请求一并加载的选项并调整

这里究竟测量的是什么

WordPress 在每一次调用时——首页、图片、REST 调用——都会用一条查询读取所有设置了 autoload 列的选项。所以这些数据行花的不是一次时间，而是每次都花。哪些列值算作“会被加载”，Kakapo 是向 WordPress 本身问的（wp_autoload_values_to_autoload，自 6.6 起，连同它的过滤器）；在较旧的安装上适用的是 yes、on、auto-on、auto 这份列表。随后在 PHP 中统计每个值的长度，也就是真正的字节数。SQL 里的 LENGTH() 会更快，但视驱动而定统计的是字符而不是字节——在 SQLite 下，遇到变元音和表情符号时界面里就会出现错误的数字。读取以 100 行为一步进行，每次运行最多 20,000 行；达到这个上限时，界面会说明，并明确把这些数字标为下限。测量只在打开该区域时或点击“重新测量”时进行——绝不会在访客的页面构建过程中进行——之后有效期为 300 秒。

正确读懂这四个指标

上方有四个数字。“每次调用都加载”给出总大小、选项数量和测量时长。“占警告阈值的比例”把它对照 800,000 字节来算——与 WordPress 核心的“网站状态”检查所用的阈值完全相同，包括它的过滤器；在同一次安装中出现两个不同的警告界限只会让人困惑。“其中可切换”是没有活动归属者的那部分，也就是你真正能动的东西。“已切换”汇总的是你在这里已经从加载过程中移出的部分。下方的“负担来自哪里”卡片按来源拆分显示同样的数量，第二张卡片显示最大的 25 个单项。

这种归属是名称比对，不是证据

options 表里没有“所有者”这一列。因此 Kakapo 会把选项名称与磁盘上实际存在的东西作比较：每个已安装插件的目录名、主脚本文件名和文本域，以及所有主题的 slug。最长的匹配前缀胜出，否则“kakapowp”就会赢过“kakapowp_performance”，从而报出错误的插件。一个插件的选项实际用了什么前缀，任何文件头里都没有写 — 从“Yoast SEO”推不出“wpseo”这样的缩写。这类情况会被归入“无法归属”这一类，它的意思是“我不知道”，而不是“不属于任何人”。如果你确切知道某个前缀，可以通过 kwpp_autoload_praefixe 过滤器补充进去；插件对自己的前缀也是这么做的。

哪些可以切换——以及为什么很多都保持锁定

只有同时满足两个条件时，“切换”按钮才会出现：该选项至少有 1 KB 大，并且不属于任何处于活动状态的组件。因此保持锁定的有：WordPress 核心的选项（来自 populate_options 的固定列表，加上 theme_mods_*、widget_* 和 *_user_roles 这几种模式——它们在每次调用时确实都需要）、临时缓存（Transients 属于深度清理，在那里它们会彻底消失，而不只是改成稍后加载）、来自某个已启用插件或当前主题的一切，以及所有小于 1 KB 的项，因为在那里额外的单条查询比省下的字节还贵。把鼠标移到变灰的按钮上：原因会作为提示写在旁边。真正划算的情况几乎总是那些已停用或早已卸载的扩展，它们的数据行就那么留了下来。没有有效许可证时，该区域处于休眠状态——仍然会测量和显示，但什么也不会切换。

切换、日志、撤回

写入是通过核心的 wp_set_option_autoload() 完成的，而不是用自己的 UPDATE：只有这样，事后才会清空正确的缓存，否则外部对象缓存会继续给出旧的状态。在没有这个函数的安装上，Kakapo 会设置“no”，并自行清空 alloptions、notoptions 和那条单独的记录。写入之前会把这一行重新查一遍：它是否还存在、是否还处于“会被加载”、以及此刻它有多大——日志里该写的是真正从加载过程中移出的内容。如果数据库没有执行这次更改，提示会明确说出来，并且什么也没有改动。日志最多保留 200 条记录，含旧的列值、大小、时间点和用户名。撤回可以单条进行，也可以一次性全部撤回；写回的是“会被加载”，因为 WordPress 的中间值“auto”无法通过核心函数恢复——原来的值仍然可以在日志中看到。如果某个选项在此期间已经完全消失，比如因为插件被卸载了，Kakapo 会报告这一点并移除这条已无对象的记录，而不是声称“已撤回”。