基于user.js的Firefox深度定制：性能与隐私兼顾的配置指南

1. 项目思路与定位拆解

1.1 fox_charon 到底想解决什么问题

第一次看到 fox_charon 这个名字，很多人会以为它是个游戏 ID 或者某个开源库的代号。实际上，这是我维护了大半年的一个本地项目，核心就一件事：基于 Firefox 深度定制一套属于自己的浏览器工作环境。项目名里的 "fox" 指 Firefox，"charon" 则是冥王星最大的那颗卫星，也是希腊神话里冥河的摆渡人。取这个名字的逻辑很直接——把官方版 Firefox 这艘船，渡到符合我个人使用习惯的彼岸去。

为什么需要这么做？因为我自己受够了每次重装系统后，要重新折腾浏览器配置的体验。Firefox 默认配置讲究的是"最大兼容性"，但对我这种日常要开几十个标签页、经常切设备、对隐私和性能都有要求的人来说，默认配置就是一碗温吞水：不够快、不够顺、隐私保护不到位、界面浪费空间。我需要的是一套可以一键复现的、可持续维护的、跑在 Firefox 之上的个人工作台。

这个项目适合谁参考？如果你属于下面任意一类人，这篇东西应该能帮你省不少事：

• 重度浏览器用户，标签页常年 20+，觉得默认浏览器越来越臃肿；
• 对隐私和跟踪有一定要求，但又不想完全切换到小众浏览器；
• 需要在多台电脑之间同步一致的浏览器体验，而不是仅仅同步书签和密码；
• 对 about:config 有兴趣但没时间系统研究，想要一份可以直接抄的配置清单。

1.2 方案选型：为什么是 Firefox 而不是 Chromium 系

在动手之前，我其实对比过三条路线：Chromium 系（Chrome/Edge）、Firefox、以及一些基于 Firefox 的深度定制发行版（如 LibreWolf、Waterfox）。最终选 Firefox 作为基底，理由有三层。

第一层是配置自由度。Chromium 虽然也有 chrome://flags，但可调项和 Firefox 的 about:config 完全不是一个量级。Firefox 的配置项有上千个，从内核并发、渲染行为、字体回退到各种实验特性，都能通过配置文件精确控制。Chromium 这边很多调整要靠命令行参数或者第三方策略模板，维护起来很别扭。

第二层是扩展生态的克制感。我需要的不是"什么都有"的应用商店，而是"核心功能可靠"的工具链。Firefox 的 WebExtension 生态虽然比 Chrome 少一些，但关键的隐私、标签管理、脚本类扩展都有高质量选择，而且 Manifest V3 过渡期里 Firefox 对拦截类扩展的限制明显更宽松。

第三层，也是最重要的：配置可文本化。Firefox 的所有核心设置都可以收敛到 user.js 这一个文件里，配合 profiles.ini 和自定义扩展列表，整个浏览器环境就是一组纯文本文件。这意味着我可以把它们丢进 Git 仓库，换机器时克隆下来就能恢复完整环境。相比之下，Chrome 的配置散落在注册表和多个 JSON 里，备份和迁移都折腾得多。

然后说为什么不用 LibreWolf 这类现成定制版。它们确实开箱即得，但问题是"别人替你做的决定"不一定符合你的场景。比如 LibreWolf 默认就把很多兼容性特性关掉了，某些网站会出问题，而我是既要隐私增强、又要日常能用的实用主义者。自己动手定制，每个开关都是我验证过的，出问题也清楚该去哪里排查。

2. 核心配置拆分与参数逻辑

2.1 先说清楚配置的层次结构

一套可维护的 Firefox 定制环境，不能只靠 about:config 里手动改，那样改完就忘，还容易改错。我的做法是把配置拆成三层。

第一层：user.js 文件，这是配置的主战场。Firefox 启动时会读取 profile 目录下的 user.js，把里面的内容写进 prefs.js（也就是运行时配置）。换句话说，user.js 是"启动时强制覆盖"的配置模板，天然适合做集中管理。注意一点：user.js 里的配置项即使和 prefs.js 里的旧值相同，启动时也会重新写入，所以编辑完重启才能生效。

第二层：扩展清单，用 extension 相关配置项强制指定允许的来源，配合手工安装的 XPI 文件，实现一套"白名单制"扩展环境。默认情况下 Firefox 只允许从 AMO（官方扩展商店）安装，这没问题，但我不想每次换机器都手动去商店里点安装，所以我会把常用扩展的 XPI 文件单独存一份，后续通过脚本批量安装。

第三层：外观与行为微调，例如 userChrome.css 和 userContent.css。这两个文件控制在 Firefox 界面本身（标签栏、地址栏、菜单）以及网页内容的默认样式。界面级的修改能让我把标签栏压缩到最紧凑，网页级的修改则可以用来统一字体和暗色背景。

这三层各司其职，user.js 管内核行为，扩展管功能，CSS 管观感。改配置时不会互相干扰，排查问题也容易定位。

2.2 性能类参数的取舍：从"快"到"又快又稳"

性能调优是最容易踩坑的部分，因为网上很多所谓"优化参数"都是拍脑袋写的，改完并不能感知到变化，甚至还会引发副作用。我自己梳理了一套经过验证的参数组合，列几个最核心的。

并发行与进程模型。核心参数是这两个：

• dom.ipc.processCount：控制内容进程数量。默认值是 8，对 16GB 内存的机器来说偏保守。我设成 12，多标签场景下切换卡顿明显减少。不过不是越大越好，每个进程都要占内存，8GB 内存的老机器建议保持默认。
• browser.sessionhistory.max_entries：会话历史最大条数。默认 50 对我来说太多，因为我不太用"前进"按钮，改成 20 能略微降低内存占用。
• network.http.max-connections：全局最大连接数。默认 900，这个值不需要动，但很多人喜欢调到 1200 或者更高，其实收益很小，还可能增加路由器压力。

渲染与滚动。Firefox 现在默认在 Windows 上启用 GPU 加速合成，但有些老显卡会出现花屏或滚动掉帧。如果你遇到滚动不流畅，检查这些：

• layers.acceleration.force-enabled：是否强制启用图层加速。默认 false，如果显卡驱动正常，设成 true 可以强制开启硬件合成。
• gfx.webrender.all：WebRender 渲染器的总开关。新版 Firefox 基本默认打开，如果显示为 false 或没值，手动设 true。老显卡可能要关掉 WebRender 退回旧渲染路径，这个需要实测判断。
• mousewheel.min_line_scroll_amount：滚轮最小滚动行数。默认 0 表示按系统设定。我改成 8，滚动响应更跟手。

内存与回收。浏览器吃内存的核心原因之一是缓存和堆内存不回收。我用这两个配置控制：

• browser.cache.disk.capacity：磁盘缓存上限，默认 358400KB（约 350MB），SSD 时代可以放宽到 512000，让频繁访问的页面加载更快。
• javascript.options.mem.max：JS 堆内存上限，单位是 MB。默认值很大（约为物理内存的一半），如果不希望 Firefox 吃掉太多内存，可以显式设一个限制，比如 4096。但要小心，设太低会导致大型网页（比如某些后台管理界面）频繁 GC 卡顿。

性能调优最忌讳的就是"参数收集癖"。每个配置项都应该有明确的目的，改完要用一段时间再评估，不要一次性堆一堆参数然后根本说不清是哪个起了作用。

2.3 隐私与安全类配置：不开箱即用的底线

这部分是 fox_charon 项目里我最坚持的模块。Firefox 默认的隐私保护属于"比 Chrome 好一点，但还不够"的水平。我会在默认基础上做三层增强。

第一层：关闭遥测与数据上报。以下参数全部设成 false：

• toolkit.telemetry.enabled
• toolkit.telemetry.unified
• datareporting.policy.dataSubmissionEnabled
• browser.ping-centre.telemetry
• browser.newtabpage.activity-stream.feeds.telemetry
• browser.newtabpage.activity-stream.telemetry

另外还有 app.shield.optoutstudies.enabled（屏蔽 Shield 研究）和 browser.discovery.enabled（禁用推荐内容服务）。

第二层：增强追踪保护。Firefox 默认开启了基础追踪保护，但要在 about:config 里把严格模式真正拉满，关键参数如下：

• privacy.trackingprotection.enabled = true：启用追踪保护。
• privacy.trackingprotection.socialtracking.enabled = true：专门拦截社交媒体跟踪器。
• privacy.donottrackheader.enabled = true：发送 DNT 信号，虽然现在很多网站不认，但聊胜于无。
• privacy.firstparty.isolate = true（或者新版中的 privacy.dynamic_firstparty.max_sites 相关配置）：启用第一方隔离，让不同站点的数据互相隔离，防止跨站跟踪。这个参数对某些依赖第三方 Cookie 的站点有破坏性，比如一些单点登录流程会受影响。

第三层：禁用连接与预取。这些"贴心"功能实际上都在向外暴露你的行为特征：

• network.prefetch-next = false：禁用链接预取。
• network.dns.disablePrefetch = true：禁用 DNS 预取（会和系统 DNS 缓存功能有一定重叠）。
• network.predictor.enabled = false：禁用网络预测器。
• browser.urlbar.suggest.searches = false：禁用地址栏搜索建议（这个也能保护搜索关键词隐私）。

隐私设置影响兼容性是非常正常的，比如 privacy.firstparty.isolate 开了之后，部分网站（尤其内嵌视频或者第三方登录的）会频繁要求重新登录。我的处理方式是：保留一个独立的"裸奔" profile 用于特殊情况，平时主力环境保持最严格模式。

2.4 界面与交互微调：userChrome.css 的实用改动

userChrome.css 是很多 Firefox 定制玩家又爱又恨的东西：功能强大，但一不小心就写崩界面。我用的改动都比较保守，目标是减少视觉噪音、增大信息密度。

核心思路是先开启样式加载开关。新版 Firefox 需要在 about:config 里设 toolkit.legacyUserProfileCustomizations.stylesheets = true，否则 userChrome.css 根本不生效。

我的 userChrome.css 主要做以下改动：

• 隐藏标签栏左侧的空白区域，把标签视图压缩到更紧凑；
• 将书签工具栏的高度收窄，并去掉默认的圆角留白；
• 自定义活动标签和非活动标签的背景色区分，减少视觉干扰；
• 把侧边栏（如果用了 Tree Style Tab）的宽度默认值调小。

写 userChrome.css 有几个坑要提醒。首先，Firefox 的界面元素结构会随版本变化，一段时间不更新就可能失效。我每次升级大版本都会先备份一份，升级后检查界面是否正常。其次，不要试图把 Firefox 改造成 Chrome 的样子，Chrome 的标签风格和 Firefox 的 UI 结构差异太大，强行模拟只会得到四不像，还会增加维护成本。最后，userChrome.css 写错了不会报错，只会默默不生效，排查时可以用浏览器工具箱（Ctrl+Shift+Alt+I）检查界面元素的实际 ID。

3. 从零搭建：fox_charon 的完整实现路径

3.1 初始化 profile 与目录结构

动手实操的第一步，是创建一个干净的、专用的 profile。Firefox 默认有个叫 default-release 的 profile，但我不建议直接拿它来改，因为里面已经开始积累缓存和状态。合理做法是新建一个专用 profile。

打开命令行（Windows 下 PowerShell，macOS/Linux 下终端），输入：

bash复制firefox -CreateProfile "fox_charon"

这时会在默认 profile 目录下生成一个名为 fox_charon 的文件夹。下一步是确认它的具体路径。运行：

bash复制firefox -P

会弹出 profile 管理器窗口，选择 fox_charon，勾选"使用所选配置文件启动"，然后启动。之后访问 about:profiles，能看到 root directory 字段，这就是 profile 的物理路径。

拿到路径后，我建议直接把这个路径加进 shell 的环境变量，方便后续脚本引用。然后，在这个目录下建立以下文件结构：

code复制fox_charon_profile/
├── user.js
├── userChrome.css
├── userContent.css
├── extensions/
└── chrome/

其中 chrome 目录放置 userChrome.css 和 userContent.css，extensions 目录存放离线 XPI 安装包。这个结构不是官方强制，而是为了管理方便，把配置源文件和运行数据分开。

3.2 user.js 配置模板：可直接抄作业的版本

下面给一份我现役环境里的精简配置模板，按模块组织，每个模块都有注释说明为什么这么设。可以直接复制到自己的 user.js 里，但要特别注意最后面的"按需调整"部分。

js复制// fox_charon user.js
// 版本：2025.01

// ===== 性能与进程 =====
user_pref("dom.ipc.processCount", 12); // 内容进程数，16G内存可设为12，8G保持默认8
user_pref("browser.sessionhistory.max_entries", 20);
user_pref("mousewheel.min_line_scroll_amount", 8);
user_pref("gfx.webrender.all", true); // 启用WebRender渲染
user_pref("browser.cache.disk.capacity", 512000); // 磁盘缓存提高到500MB
user_pref("javascript.options.mem.max", 4096); // JS堆上限4GB

// ===== 隐私与安全 =====
user_pref("toolkit.telemetry.enabled", false);
user_pref("toolkit.telemetry.unified", false);
user_pref("datareporting.policy.dataSubmissionEnabled", false);
user_pref("browser.ping-centre.telemetry", false);
user_pref("browser.newtabpage.activity-stream.feeds.telemetry", false);
user_pref("app.shield.optoutstudies.enabled", false);
user_pref("browser.discovery.enabled", false);
user_pref("privacy.trackingprotection.enabled", true);
user_pref("privacy.trackingprotection.socialtracking.enabled", true);
user_pref("privacy.donottrackheader.enabled", true);
user_pref("privacy.firstparty.isolate", true);
user_pref("network.prefetch-next", false);
user_pref("network.dns.disablePrefetch", true);
user_pref("network.predictor.enabled", false);
user_pref("browser.urlbar.suggest.searches", false);

// ===== 界面与行为 =====
user_pref("toolkit.legacyUserCustomizations.stylesheets", true); // 允许userChrome.css生效
user_pref("browser.tabs.firefox-view", false); // 关闭标签页概览入口
user_pref("browser.fullscreen.autohide", true); // 全屏时自动隐藏工具栏
user_pref("browser.urlbar.suggest.history", true); // 保留历史建议
user_pref("browser.urlbar.suggest.bookmark", false); // 地址栏不推荐书签
user_pref("browser.search.suggest.enabled", false); // 关闭搜索栏建议

这里有个很重要的原则：每个 user_pref 都只写一个值，不要写多个值。这跟 JavaScript 语法无关，user.js 就是要求一行一个配置项，写错了启动时也不会报错，但配置不会生效。检查方式是在 about:config 里搜索对应项看值是否被覆盖。

3.3 扩展安装：从商店下载转到本地批量部署

默认情况下，Firefox 安装扩展有两条路径：图形界面访问 AMO 点安装，或者把 XPI 文件拖进浏览器窗口。我的方案是更可控的第三种：手动下载 XPI，用脚本批量安装到 profile 的 extensions 目录。

先说明为什么要这么麻烦。商店安装方便，但有几个痛点：一是换新机器时记不住自己装过哪些；二是商店里有些扩展会悄悄更新，更新后行为可能变化；三是部分扩展在商店里下架了但本地还能用，你不想被远程删除。本地 XPI 可以锁定版本，配合 user.js 层面的 extensions.autoDisableScopes 配置，可以更好地控制安装源。

具体的批量安装做法是两步。

第一步，准备好 XPI 文件。大多数扩展在 AMO 页面上有"直接下载"链接，也可以通过查看页面源码找到 .xpi 下载地址。更简单的方式是用 curl 从 AMO 的 API 拉取：

bash复制curl -L -o ublock-origin.xpi \
  "https://addons.mozilla.org/firefox/downloads/latest/ublock-origin/latest.xpi"

第二步，把 XPI 放进 profile 的 extensions 目录。这里有个关键细节：扩展的 XPI 文件名必须和扩展的 ID 一致，否则 Firefox 不会识别。扩展 ID 可以在 about:debugging 页面里查到，一般是一串类似 uBlock0@raymondhill.net 的字符串。文件名要改成 {扩展ID}.xpi 的格式。

整理好后，写个简单的部署脚本（Windows 批处理或 bash 都行）把 XPI 复制到目标目录。重启 Firefox，扩展就自动加载了。这个方法特别适合多机维护，把 XPI 文件和脚本一起放进 Git 仓库，换机器时拉下来跑一遍就行。

3.4 外观定制的实际落地：userChrome 实战

userChrome.css 的核心作用，是把 Firefox 默认的"安全留白"风格改成更适合自己的紧凑风格。我提供一个最小可用版本，目标是减少垂直空间占用，让内容区更大。

css复制/* userChrome.css - fox_charon 精简版 */

/* 让标签栏更紧凑 */
#tabbrowser-tabs {
  --tab-min-height: 30px !important;
  --tab-min-width: 80px !important;
}

/* 隐藏书签工具栏的图标文字，只保留图标，减少高度 */
#PersonalToolbar {
  min-height: 24px !important;
  max-height: 24px !important;
}
#PersonalToolbar .toolbarbutton-text {
  display: none !important;
}

/* 地址栏和搜索栏更紧凑 */
#urlbar-container {
  --urlbar-min-height: 28px !important;
}

/* 隐藏侧边栏标题头，为树状标签页腾出空间 */
#sidebar-box[sidebarcommand="treestyletab_piro_sakura_ne_jp-sidebar-action"] .sidebar-header {
  display: none !important;
}

写 userChrome.css 要注意：!important 在 Firefox 的 XUL 样式里必须加，否则会被内置样式覆盖。但也不是越多越好，每个规则都要是确有必要的。

调试 userChrome.css 的流程是这样的：改完文件后，在浏览器里打开一个新标签页，地址栏输入 about:config 不进入，而是按下 Ctrl+Shift+Alt+I（Windows/Linux）或 Cmd+Alt+I（macOS）打开浏览器工具箱，然后刷新 chrome 样式。这样不用重启浏览器就能看到改动效果，大幅提升调试效率。

有一个大量用户踩过的坑：修改 userChrome.css 后看起来没生效，于是拼命加 !important，结果还是没用。这八成是因为启动参数里没有 toolkit.legacyUserCustomizations.stylesheets = true，或者 profile 目录搞错了。先检查这两项，再开始排查选择器问题。

3.5 多设备同步方案：用 Git 而非 Firefox 账号

Firefox Sync 可以同步书签、密码、历史记录，但同步不了 user.js 和 userChrome.css。所以我的方案是：所有配置文件进入 Git 仓库，运行状态数据依然走 Firefox Sync。这样两台电脑各自拉取仓库，就能得到一致的浏览器外壳，而书签和登录态依然由官方同步通道处理。

具体做法是在 profile 目录外建一个 config_repo 目录，结构如下：

code复制config_repo/
├── user.js
├── chrome/
│   ├── userChrome.css
│   └── userContent.css
├── extensions/          # XPI文件只存原始版，不逐台机器同步
├── install.sh
└── README.md

install.sh 的核心逻辑是用软链接把仓库里的文件链接到 profile 目录。这样做的好处是以后只需要 git pull 再跑一遍脚本，文件自动更新。软链接在 Windows 上需要开发者模式或者管理员权限，如果怕麻烦，也可以改为用复制命令。

我在实际使用中遇到一个教训：不要把 profile 目录整个塞进 Git。profile 目录里有大量缓存和临时文件，git 会变得极其臃肿，而且每次提交都会产生巨量 diff。一定要区分"配置源文件"和"运行数据"，只版本控制前者。

4. 常见问题与排查技巧实录

4.1 配置不生效：先查这四件事

这是我被问得最多的问题，也是我自己踩得最深的一个坑。user.js 改了几十个参数，重启后发现 about:config 里什么都没变。这种事通常只有四个原因。

第一，user.js 放错位置。它必须在当前正在使用的 profile 目录里，而不是 Firefox 的安装目录。检查方法是在 about:profiles 页面看当前 profile 的 Root Directory，然后用资源管理器打开对比。

第二，user_pref 语法错误。最常见的是漏了分号、字符串少引号、或者用单引号还是双引号不一致。虽然 user.js 是类 JavaScript 语法，但它更接近"配置声明"，引号缺失不会报错，但整行都不会解析。建议用文本编辑器的高亮功能，确认每行都以 user_pref( 开头、以 ); 结尾。

第三，配置项被 prefs.js 中的旧值覆盖。理论上 user.js 的优先级更高，但如果你在 about:config 里手动改过同一项，再编辑 user.js 就会出现混乱。标准做法是：改完 user.js 后，在 about:config 里搜索那一项，如有"重置"按钮则点重置，让 user.js 重新生效。

第四，没有彻底重启。这里强调"彻底"，是因为 Firefox 有时候挂在后台进程里，点击关闭窗口只是关了界面，进程还在。Windows 上按 Ctrl+Shift+Esc 打开任务管理器，确认所有 firefox.exe 进程都结束，再重新打开。

4.2 升级后扩展或样式失效的应对

Firefox 每个大版本更新，都可能导致三件事：userChrome.css 样式错乱、某个扩展被标记为不兼容、某个 about:config 参数被重命名或移除。我遇到过最典型的是 privacy.firstparty.isolate 这个参数，在新版本里被拆分成了动态第一方隔离（Dynamic First-Party Isolation），行为也变了。如果不看 release notes 根本发现不了。

应对策略就两条。第一条是固定版本：如果是工作主力机，不要太激进地把 Firefox 设为自动更新，可以改成手动检查更新，等社区反馈稳定后再升级。桌面版在"设置 -> 通用 -> Firefox 更新"里可以配置。第二条是升级前备份：升级之前复制一份完整 profile 目录（不用复制缓存子目录），万一新版本出了问题，可以快速回退。

另外，扩展失效不一定是 Firefox 更新的锅，也可能是扩展作者主动停更。我的建议是：核心扩展控制在 10 个以内，并定期检查每个扩展的更新状态。如果一个扩展半年没更新，就要考虑找替代品了。

4.3 内存占用居高不下的排查思路

Firefox 吃内存这件事，任何优化都只能缓解，不能根治。但如果内存占用异常偏高（比如 16GB 的机器，Firefox 单个进程吃 6GB+），就要排查几个方向。

第一步，在地址栏输入 about:processes，这里能看到每个进程的 CPU 和内存占用。重点看内容进程里哪个标签页占最多。通常罪魁祸首是几个大站点，比如复杂的后台面板、长列表的社交媒体页面。

第二步，检查扩展的贡献。在 about:processes 里可以看到扩展进程的内存占用。可以用 about:debugging 临时禁用扩展逐一对比。我的经验是 uBlock Origin 最省内存、Tree Style Tab 也很轻，但有些"美化类"扩展（比如强制暗色模式的山寨扩展）是真正的内存黑洞。

第三步，调整缓存策略。如果磁盘缓存太小，Firefox 就会把更多数据留在内存里。把 browser.cache.disk.capacity 调大一些（比如 512000），内存压力通常会减轻。同时确保 browser.cache.memory.capacity 的值是 -1（自动），不要手动设一个过大的值。

也要调整预期：多标签工作流下，内存占用 2-3GB 是正常水平，不要指望它能压到几百 MB。真正需要省内存的话，直接从标签管理习惯入手——减少同时打开的标签页数量比任何参数优化都管用。

4.4 网站兼容性问题的分级处理

定制过强之后，偶尔会遇到网站显示异常，不一定是你操作错了，也可能是网站自己的前端太陈旧。兼容性问题我分为三级来处理。

第一级：轻微，不影响功能。比如某网站样式错位但可以正常操作。这种情况我一般用 userContent.css 做个局部修正，针对特定域名覆盖默认样式。

第二级：中等，功能可用但体验差，比如某些内嵌地图加载不出来、第三方登录跳转异常。我先检查是不是隐私参数关得太狠，比如 privacy.firstparty.isolate、network.http.referer.defaultPolicy 这类配置。逐个临时改回默认，找到罪魁祸首。如果确认是某个隐私参数导致，我会在该配置文件里加一行注释，标明"该配置与某站兼容性问题相关"。

第三级：彻底打不开，功能性损坏。这种情况我就开第二个裸奔 profile，平时不用，只在处理这种站点时打开。裸奔 profile 同样走 firefox -P 创建，默认真实配置，不加载任何定制。用它登录一次，问题解决就关掉，不会影响主力环境。

4.5 维护节奏：定期做的最小检查清单

配置环境不是一劳永逸的。我给自己定了一个维护节奏：每两个月做一次全面检查，每次 Firefox 大版本升级后再做一次快速检查。要做的事情不算多，列成清单就是：

• 在 about:config 里搜索 user.js 中设置过的关键项，确认值没有被自动重置或改名；
• 打开 about:processes 扫一眼内存占用，看有没有异常增长；
• 检查扩展列表，有没有更新提示、有没有不再维护的；
• 用浏览器的"刷新"功能测试几个常用的、比较复杂的网站（后台面板、在线编辑器、视频站点），确保兼容性没有退化；
• 把配置仓库 git push 一次，提交信息写清楚本周改动。

这套维护清单我实际跑了大半年，最大的价值不是发现多少问题，而是让我对浏览器的运行状态保持敏感。比如有一次我注意到地址栏搜索建议突然开启了，查了一下是某次升级把 browser.urlbar.suggest.searches 默认值改了，因为清单里有这项检查，十分钟就定位到了问题。

5. 一些实操后的经验沉淀

做 fox_charon 这个项目最大的体会是：浏览器的定制不能追求"改得多"，而应该追求"每一处都有目的"。我在早期的版本里堆了几十个从网上搜来的参数，最后发现其中至少有三分之一没有可感知的影响，还有几个反而让网站在某些情况下变得不稳定。后来我删掉了所有"看起来很酷但说不清作用"的项，配置量减少了一半，体验反而更稳定。

另一个经验是关于备份和迁移的。真正经历过一次硬盘损坏之后，我才意识到 bookmarks 和密码并不重要——这些数据本来就可以通过 Firefox 账号恢复，真正没法从云端找回来的，是那套花了很多心思积攒下来的 user.js 和 userChrome.css。所以现在我把配置仓库同时推到两个 git 远程，一个私有仓库，一个本地 U 盘副本。虽然 git 不是为浏览器配置设计的，但它恰好是这套场景下最简单、最可靠的同步工具。

最后再分享一个小技巧。如果你在 anywhere 配置了一套环境，并且在另一台机器上克隆使用，记得在启动后第一件事是打开 about:config 搜索 browser.cache.disk.capacity，确认配置值真的被加载了。因为有些企业版或便携版的 Firefox 会锁定某些偏好设置，user.js 里写了也无效，这时你就需要查看 prefs.js 里有没有对应的 user_pref 条目作为佐证。这个排查逻辑对 user.js 里任何一个不生效的项都适用：先看 prefs.js，再看进程，最后看版本行为变化。方向对了，问题就解决了一半。