浏览器扩展禁用后又被启用怎么办：少写一个字段

记录一个改浏览器配置改了个寂寞的坑，顺带一条通用的校验方法论。

当时的任务：批量停用 360 浏览器的内置扩展。做法是改用户目录 `Preferences` JSON，把扩展 `state` 写成 0。脚本写完读回校验，值全对，还打印了「7 项停用，校验通过」。

重启浏览器，五个内置扩展齐刷刷回到启用状态。

第一晚查错了方向：我怀疑 360 有个加密配置 `ext_360_cfg`，启动时重建白名单、把改动刷回去。那一晚三次「修好」全落空，三次都是脚本报成功、实际没生效。

第二天换个思路：拿一个真正停用成功的扩展，跟我的写法逐字段对照，问题当场现形：

```text
停用成功的：state: 0 + disable_reasons: 1
我写失败的：state: 0                    ← disable_reasons 没写
```

Chromium 判断扩展能否处于停用状态，看的是 `disable_reasons` 位掩码（1 = DISABLE_USER_ACTION，用户主动停用）。`state` 只是结果，位掩码才是依据。只写结果不写依据，就是状态不一致的脏数据，启动时被纠正回默认值。

补上字段，回弹当场消失。这条在 Chrome、Edge、360 系通用。

顺带两条教训：

1. 把 `Preferences` 设成只读没用——浏览器启动时自己解除只读再回写。
2. 脚本自己报成功不算数：写入后要读回断言值相等，再抽查文件字节数有没有真的变。

完整的字段对照、进程判断的坑、还有一例 zip 写入假成功，都整理在我的博客：

[https://www.budingwz.cn/browser-ext-disable-reasons.html](https://www.budingwz.cn/browser-ext-disable-reasons.html)