直接修改 active_plugins 为 a:0:{} 常失效，因 WordPress 启动时扫描 wp-content/plugins 目录并重写该值；数据库仅缓存，非权威来源，且必须用正确 PHP 序列化格式。
直接在 phpmyadmin 里把 active_plugins 改成 a:0:{} 是最常见做法，但大概率会失效——wordpress 下次加载时会自动还原旧值。
为什么改了 active_plugins 却没用？
WordPress 不靠这个字段做实时判断。它真正依赖的是：wp-content/plugins/ 目录是否存在、每个插件文件头是否含 Plugin Name:、以及已知插件列表是否匹配。数据库里的 active_plugins 只是缓存结果，不是权威来源。
常见错误现象包括：手动清空后刷新后台，插件又全回来了；或者前台白屏、500 错误——因为写入了非法序列化值（比如填了 [] 或空字符串）。
- 必须用 PHP 序列化格式，
a:0:{}是唯一安全的“空数组”表示，不是 JSON、不是 NULL、不能少冒号或花括号 - 如果插件目录下仍有插件文件，WordPress 启动时会重新扫描并覆盖该字段
- 某些插件在激活时注册了定时任务或数据库表，跳过禁用逻辑会导致残留
phpMyAdmin 操作前必须做的三件事
不是点开就改，否则可能进不了后台。
- 先备份
wp_options表，至少导出active_plugins和recently_activated两行 - 确认数据库表前缀（不一定是
wp_），搜索时用实际前缀，例如wp234_options - 执行完修改后，必须清空服务器级缓存：OPcache 要重启 PHP 进程，Redis/Memcached 需手动 flush，否则旧值仍被读取
真能用 SQL 语句一键清空吗？
可以，但仅限你清楚后果且环境可控。以下 SQL 是唯一可接受的写法：
立即学习“PHP免费学习笔记（深入）”；
UPDATE `wp_options` SET `option_value` = 'a:0:{}' WHERE `option_name` = 'active_plugins';
注意：` 是 MySQL 字段/表名包裹符，不能省；单引号必须保留；表名要替换成你的真实前缀。
风险点很实在：
- 如果某个插件在
activate_plugin钩子里写了清理逻辑（比如删临时表、停定时任务），直写数据库会跳过这些步骤 - 多站点网络下，这条语句只影响主站，子站需额外处理
wp_sitemeta表中的active_sitewide_plugins - 部分托管平台（如 WP Engine）禁用直接数据库写入，SQL 执行会失败
比 phpMyAdmin 更稳的替代方案
如果你有 SSH 权限，wp plugin deactivate --all 是真正的“批量禁用”——它逐个调用 WordPress 原生禁用流程，触发所有钩子，清理副作用，最后才落库。
实在进不去后台又没 CLI，就别硬刚数据库。用 FTP 把 wp-content/plugins 重命名为 plugins.off，访问一次任意页面，WordPress 自动清空 active_plugins 并记入数据库，再改回原名——这才是它自己认的“全部禁用”。
复杂点在于：插件状态从来不是单点控制，而是文件系统 + 解析逻辑 + 缓存三者对齐。漏掉任一环，都可能让你以为禁用了，其实没禁掉。
