我想得越多，我想知道为什么有人要费心使用默认值/首选项/*.js文件来设置默认值，而不是在JavaScript中设置默认值？
我正在做一个由其他人创建的基于XUL/Overlay的旧插件的工作，除了在JavaScript中设置所有默认值外，它实际上还使用prefs.js文件（以防prefs.js由于某种莫名其妙的原因而失败？），这基本上是在安装后直接将所有首选项转换为用户首选项。 起初这让我感到困惑，因为在查看about:config中的首选项时，默认值显示为已修改（用户设置）。 然后我意识到它是无条件设置一些默认值（非常大的字符串）。
所以我意识到，我不仅在 3 个位置（首选项.js、界面和内容脚本）维护相同的首选项，而且 prefs.js 文件在很大程度上是多余的，这似乎无缘无故地增加了额外的维护。 这看起来很愚蠢，我正在寻找一种更好的方法，只存储首选项并在一个位置管理它们（这可能就是为什么首选项.js应该专门使用的原因）。
现在，我意识到，这个问题有可能被标记为"意见"，并且可能有也可能没有特定的"正确"答案。 但我认为这是一个有效的问题，我想更多地了解使用 prefs.js 文件的优缺点，而不是在共享 JS 代码中初始化期间设置所有首选项。 是否有任何性能问题，或我可以用来做出此决定的客观标准列表？ 首选项.js机制是否有可能失败？ 假设它永远不会失败是安全的吗？ 在FF 1.0-3.5天内是否更容易发生故障？
默认首选项：
- 可以在新版本的加载项中进行更改，而无需覆盖用户显式设置的值。
- 卸载加载项后，不要弄乱用户的配置文件
- 位于同一个地方，而不是分散在代码中。很容易看出有什么偏好。它们也出现在about：config中，它允许您为"隐藏"首选项提供UI - 为了高级用户。
遗憾的是，如果用户设置的值无效，他们没有让get*Pref API返回默认值，而且我知道不想在两个位置维护默认值。整个 API 很久以前就被"冻结"了，最终会随着 XPCOM 的其余部分一起消失，所以这并不重要......