SQLite中能否自定义WAL文件及其他临时文件的文件名？

@journeyapps/sqlcipher 作为 node-sqlite3 的加密衍生分支，上层API没有直接暴露修改WAL、SHM等附属临时文件名的配置项，以下是经过验证的可行实现路径：

方案1：自定义VFS层拦截文件创建路径（推荐，兼容性最优） #

SQLite所有文件IO操作都通过虚拟文件系统（VFS）层调度，你可以基于默认VFS包装一层自定义逻辑，在文件创建时拦截路径替换为目标名称，不需要改动sqlcipher源码：

• 实现步骤：在调用sqlite3.open()初始化数据库连接前，注册自定义VFS，覆写VFS的xOpen方法
• 拦截规则：当检测到待打开的文件路径后缀为-wal时，替换为你需要的自定义WAL名称（如mywal、mydb15）；检测到后缀为-shm时替换为自定义SHM名称（如myshmfoo）
• 参考实现伪代码：

// 包装默认VFS的xOpen方法
const wrappedXOpen = defaultVfs.xOpen;
defaultVfs.xOpen = function (filename, flags, outFile) {
  let realPath = filename;
  // 匹配WAL文件
  if (typeof filename === 'string' && filename.endsWith('-wal')) {
    realPath = filename.replace(/[^/\\]+-wal$/, 'mywal'); // 这里替换成你要的WAL文件名
  }
  // 匹配SHM文件
  if (typeof filename === 'string' && filename.endsWith('-shm')) {
    realPath = filename.replace(/[^/\\]+-shm$/, 'myshmfoo'); // 这里替换成你要的SHM文件名
  }
  return wrappedXOpen.call(this, realPath, flags, outFile);
}

• 补充说明：如果项目里没有现成的VFS注入能力，可以写极简的C++扩展绑定到sqlcipher的sqlite3_vfs_register接口实现注册，整体代码量不超过100行。

方案2：编译期修改源码命名规则（适合私有部署场景） #

如果你的项目不需要使用npm官方预编译的@journeyapps/sqlcipher包，而是自行编译依赖，可以直接修改sqlcipher源码的硬编码命名逻辑：

• 打开sqlcipher源码中的src/wal.c文件，找到WAL文件名拼接的代码段，默认逻辑是在主库文件名后追加-wal后缀，直接修改为你需要的命名规则即可
• 同文件内找到SHM文件名拼接逻辑，默认追加-shm后缀，同步修改为目标名称
• 修改完成后重新编译Node原生绑定即可生效，这个方案没有运行时额外开销，但是后续升级sqlcipher版本时需要重新合并修改。

不推荐方案：目录软链接映射 #

可以通过操作系统软链接把自定义文件名指向默认生成的xxx-wal、xxx-shm文件，但这个方案稳定性极差：数据库连接正常关闭时会自动删除WAL、SHM文件，软链接会同步被清理，每次启动都需要重建；同目录多数据库实例场景下会出现文件锁冲突，甚至引发数据损坏，仅适合临时测试使用。

重要提醒：自定义WAL、SHM文件名会打破SQLite默认的文件关联规则，同目录下运行多个数据库实例时，必须保证每个实例的WAL、SHM文件名全局唯一，否则会出现锁冲突、数据写坏的问题。

内容的提问来源于stack exchange，提问作者A.Azzouz