备份好，然后删除这三个place文件。重启火狐让它重建这几个文件，再添加书签测试一遍。怀疑这些文件损坏了。

firefox 正常退出时 places.sqlite-shm 和 places.sqlite-wal 都会自动删除
未删除则 firefox 仍未退出

这两个文件是SQLite 3.7某个版本后的特性，不是FF的问题。
我“退出”(三道杠菜单上面的)FF后，这两个文件也没删除。
但其它的数据库的却删除了。
我猜想是FF故意为之吧？

我备份时都用speedyfox这软件“优化”后才打包，
这个能去掉这两个文件
（至于你说的不同时备份这两个文件，
新添加书签消失的问题，没实际测试过用这方法能不能解决），
同时能减小这些数据库文件的体积。

dsznyrvzn：我备份的places.sqlite是我从用火狐时就有的文件，每次用SQLite Manager压缩一下。我想是不是places.sqlite太老了。它压缩后只有几百k，而新建配置后的places.sqlite有10M。我发现我用的place...回到原帖

可能也有这方面的原因，中间跨版本太大了。
我的places.sqlite文件是从FF3.4时代沿用到现在的nightly40，
但一切正常，可能是一个个版本升级上来的原因吧。

https://www.sqlite.org/wal.html

By default, SQLite does a checkpoint automatically when the WAL file reaches a threshold size of 1000 pages. (The SQLITE_DEFAULT_WAL_AUTOCHECKPOINT compile-time option can be used to specify a different default.) Applications using WAL do not have to do anything in order to for these checkpoints to occur. But if they want to, applications can adjust the automatic checkpoint threshold. Or they can turn off the automatic checkpoints and run checkpoints during idle moments or in a separate thread or process.

Automatic Checkpoint
By default, SQLite will automatically checkpoint whenever a COMMIT occurs that causes the WAL file to be 1000 pages or more in size, or when the last database connection on a database file closes. The default configuration is intended to work well for most applications. But programs that want more control can force a checkpoint using the wal_checkpoint pragma or by calling the sqlite3_wal_checkpoint() C interface. The automatic checkpoint threshold can be changed or automatic checkpointing can be completely disabled using the wal_autocheckpoint pragma or by calling the sqlite3_wal_autocheckpoint() C interface. A program can also use sqlite3_wal_hook() to register a callback to be invoked whenever any transaction commits to the WAL. This callback can then invoke sqlite3_wal_checkpoint() or sqlite3_wal_checkpoint_v2() based on whatever criteria it thinks is appropriate. (The automatic checkpoint mechanism is implemented as a simple wrapper around sqlite3_wal_hook().)

In normal cases, new content is appended to the WAL file until the WAL file accumulates about 1000 pages (and is thus about 4MB in size) at which point a checkpoint is automatically run and the WAL file is recycled. The checkpoint does not normally truncate the WAL file (unless the journal_size_limit pragma is set). Instead, it merely causes SQLite to start overwriting the WAL file from the beginning. This is done because it is normally faster to overwrite an existing file than to append. When the last connection to a database closes, that connection does one last checkpoint and then deletes the WAL and its associated shared-memory file, to clean up the disk.

https://bugzilla.mozilla.org/show_bug.cgi?id=686237
看起来是从34.0转async开始重现的

lonely_8：这两个文件是SQLite 3.7某个版本后的特性，不是FF的问题。
我“退出”(三道杠菜单上面的)FF后，这两个文件也没删除。
但其它的数据库的却删除了。
我猜想是FF故意为之吧？

我备份时都用speedyfox这软件“优化”后...回到原帖

看上面贴的那堆文本
wal(.sqlite-wal)和shared-memory file(.sqlite-shm)会在Checkpoint操作后被合并进.sqlite文件

如果firefox没有做特别设置
在firefox退出时
正确关闭最后一个到sqlite的connection会自动引发一次checkpoint操作并删除wal和shm
从之前的版本来看
firefox不应该有做过特别设置

不清楚speedyfox是怎么处理的
但是要备份
可以连同wal和shm一起备份
或者手动对sqlite进行操作（比如你说的VACUUM）并正确退出
就会引发之前说讲的checkpoint