WordPress插件激活状态由插件文件头、目录结构和active_plugins选项共同决定，直接清空该选项无效；正确方法是临时重命名plugins目录触发自动清空，或用WP-CLI执行wp plugin deactivate --all。
直接清空 active_plugins 选项会失效
wordpress 并不靠单独读取 active_plugins 这个选项来判断插件是否启用——它只是缓存结果。真正起作用的是插件目录下每个插件文件头部的 plugin name: 注释 + wp-content/plugins/ 目录结构 + wp_options 表中该选项的序列化值三者共同决定的。直接在数据库里把 active_plugins 设为空数组（a:0:{}）或 null，下次进后台或刷新页面，wordpress 很可能自动重写回原值。
安全清空插件激活状态的正确操作顺序
必须让 WordPress 主动“认为”所有插件都该停用，而不是强行覆盖缓存。最稳妥的方式是临时重命名插件目录，再触发一次插件状态重扫描：
- 通过 FTP 或 SSH 进入
wp-content/目录，将plugins/重命名为plugins.off/ - 访问任意前台或后台页面（触发 WordPress 发现插件目录不存在，自动清空
active_plugins） - 再把目录改回
plugins/（此时所有插件仍处于未激活状态） - 检查数据库确认：
SELECT option_value FROM wp_options WHERE option_name = 'active_plugins';应返回a:0:{}
手动更新 active_plugins 的风险与前提
只有在确定没有插件使用 activate_plugin、deactivate_plugins 等钩子做副作用操作时，才考虑直连数据库修改。否则可能跳过清理函数、残留定时任务或数据库表。
- 必须用 PHP 序列化格式写入，不能填空字符串或 JSON —— 错误值如
[]或null会导致后台白屏 - 正确值是
a:0:{}（PHP 序列化的空数组），不是[]、""或NULL - 执行前务必备份
wp_options表，尤其active_plugins和recently_activated两项 - 修改后清空对象缓存（如 Redis、Memcached）和 OPcache，否则旧值可能仍被读取
为什么不用 WP-CLI 更简单？
如果你有服务器命令行权限，wp plugin deactivate --all 是最干净的方式。它会逐个调用禁用逻辑，清理钩子、定时任务、选项，并最终写入正确的 a:0:{}。
- 执行前确保当前用户有插件管理权限（通常是 admin）
- 若插件含致命错误导致 CLI 崩溃，可加
--skip-plugins启动：wp --skip-plugins plugin deactivate --all - 注意某些多站点网络插件需额外加
--network参数
