Firefox Bootstrapped Addons 不会像 Overlay Addons 那样读取默认首选项。
我了解在安装 Bootstrapped Addon 时需要手动设置默认首选项。

在初始安装后，我猜设置默认首选项的唯一好处是启用重置首选项(除非 FF 在其他地方跟踪它)。

问题是，是否必须在每个 startup() 上读取和设置默认首选项？
如果是这样，它们将被保存在哪里(即 getDefaultBranch() 从哪里获取数据)？

参考：
如何将覆盖扩展转换为无重启
Mozilla 偏好的简要指南
Restartless 附加组件默认首选项
首选项

我已通过电子邮件收到答复，我将在此处逐字发布以供用户使用。

来自 Dave Garrett，Flagfox 的开发者和 How to convert an overlay extension to restartless一书的作者

Default prefs set during runtime are saved nowhere. There is no on
disk cache of default prefs.

On Firefox start, default prefs are read from their various locations
into the preferences system. (Firefox has its own in omni.ja & addons
have theirs in their install folders/files) A copy of this branch is
also maintained with the user prefs read from prefs.js overwritten
into it. Setting of (user) prefs changes the state in the prefs
system, which (eventually) is recorded in prefs.js (again, only
non-default pref values are saved). Setting of default prefs changes
the state in the prefs system, however this is not saved anywhere.
They need to be loaded on every start. For the old standard default
prefs system, Firefox loaded them on every start for you. For
restartless extensions you need to do this yourself. Every addon
startup needs to load the default prefs.

You can of course use prefs without having a default at all, but you'd
have to hardcode the default values in your code all over the place.
Simply implementing a default prefs system for restartless addons is a
far cleaner solution that avoids mistakes you would otherwise make.

As the prefs system only stores non-default prefs to disk, it also can
greatly improve the efficiency in saving prefs once they're put back
to default for any reason. For example, I've got a JSON blob in a
string pref. (as of v5.0 it's fairly compacted now) If a user alters
what needs to be saved there by changing something in the options
dialog, this JSON blob will be stored in prefs.js in full. If the user
then reverts that change, their JSON blob will be reverted to the
prior value. If this is equivalent to whatever the default value is,
then prefs.js simply stores no value and the default is used. This
reduces what needs to be loaded on start from prefs.js in the default
case. In fact, I can use the prefs API to detect if the value is
currently set to default and I entirely bypass loading from the packed
JSON user pref and go directly to a full JSON file, in which case I
don't even need to load from the prefs system. It's an optimization
that is only really applicable in cases like this, but it's another
example why properly using defaults can be useful.

关于删除 shutdown()

上的默认首选项

Generally no, you don't need to remove default preferences on
shutdown, though there's a legitimate argument that it might be
correct to do so (but maybe a bad idea). To be clear, there's a few
separate cases of shutdown to take into account:

1) Firefox shutdown + addon shutdown: In this case you should not be
doing any shutdown that isn't needed to preserve data. No need to
unload your stuff as app shutdown is in progress and it'll do that for
you.

2) addon shutdown due to addon update: In this case you need to
properly unload everything you've loaded so that the next version can
load cleanly. However, there's no need to worry about default
preferences here, generally. The new version's will be loaded and
overwrite the old. (unless a default has been removed, in which case
that will linger in memory doing nothing)

3) addon shutdown due to addon disable: Leaving default prefs loaded
here hurts nothing other than the tiny amount of memory they take up.
If you have a lot of prefs I guess unloading them might be warranted,
however this is not a use case that is going to come up very often. I
wouldn't worry about unloading prefs at all unless you either have way
too many prefs or prefs so large that you're getting warnings in the
browser error console about them being too big. (in which case you
should fix that)

Even if it might be a good idea to clean up default prefs on shutdown,
deleting a default pref that has a user pref might break things. I
suggest just leaving them alone.