SQL.js 是纯前端 SQLite 实现，所有数据库操作均在内存中进行，无法直接修改服务器上的 .db 文件；HTTP 协议禁止客户端任意写入远程资源，因此必须结合服务端（如 Node.js）或浏览器持久化存储（如 IndexedDB）实现数据持久化。
sql.js 是纯前端 sqlite 实现，所有数据库操作均在内存中进行，无法直接修改服务器上的 `.db` 文件；http 协议禁止客户端任意写入远程资源，因此必须结合服务端（如 node.js）或浏览器持久化存储（如 indexeddb）实现数据持久化。
SQL.js 是一个基于 WebAssembly 的 SQLite 移植库，其核心设计目标是在浏览器中无服务端依赖地执行 SQL 查询与事务。但需明确一个关键事实：它不提供、也不支持对原始 .db 文件的写回（write-back）能力。你当前的代码逻辑存在一个常见误解——以为 new SQL.Database(new Uint8Array(buf)) 创建的数据库实例能将后续 INSERT 或 UPDATE 操作“保存回” src/db/sql2.db 文件。实际上：
- fetch("src/db/sql2.db") 仅是一次性读取二进制数据（即数据库快照）；
- SQL.Database 构造函数将该数据加载到内存中的独立副本；
- 所有 db.run()、db.exec() 操作均作用于该内存副本，生命周期仅限于当前 JavaScript 上下文；
- 页面刷新、关闭标签页后，所有变更即丢失；
- 浏览器出于安全沙箱机制，绝对禁止前端脚本通过 HTTP PUT/POST 等方式覆盖服务器文件系统中的任意资源（否则任意网站都可篡改 index.html 或数据库文件，造成严重安全风险）。
✅ 正确理解 SQL.js 的定位：
它是一个 “只读加载 + 内存运行” 的客户端数据库引擎，适用于离线查询、数据预处理、本地缓存计算等场景，不是服务端数据库的替代品，也不具备文件系统 I/O 能力。
? 可行的持久化方案对比：
| 方案 | 原理 | 适用场景 | 是否需服务端 | 数据持久性 |
|---|---|---|---|---|
| IndexedDB + SQL.js 导出 | 将内存数据库序列化为 Uint8Array，用 IDBObjectStore.put() 存入 IndexedDB；加载时反向读取并重建 SQL.Database | 完全离线、用户专属数据（如笔记、表单草稿） | ❌ 否 | ✅ 关闭页面后保留（同源内） |
| 服务端 API（如 Node.js + SQLite） | 前端通过 fetch() 提交 SQL 操作 → 后端解析并执行真实 SQLite 文件读写 → 返回结果 | 多用户共享、需权限控制、强一致性要求 | ✅ 是 | ✅ 文件级持久，支持备份与并发 |
| localStorage（仅小量结构化数据） | 将简单表数据转为 JSON 字符串存入 localStorage，自行实现增删改查逻辑 | 极轻量配置、计数器等 | ❌ 否 | ✅ 但容量小（~5MB）、无事务、非 SQL 接口 |
? 示例：使用 IndexedDB 持久化 SQL.js 数据库
// 保存数据库到 IndexedDB
async function saveDatabase(db, dbName = 'myAppDB') {
const dbPromise = idb.openDB('sqljs-store', 1, {
upgrade(db) { db.createObjectStore('databases'); }
});
const tx = (await dbPromise).transaction('databases', 'readwrite');
const buf = db.export(); // 获取当前内存数据库的完整字节流
await tx.store.put(buf, dbName);
await tx.done;
}
// 加载数据库（含初始化逻辑）
async function loadOrCreateDatabase(dbName = 'myAppDB') {
const dbPromise = idb.openDB('sqljs-store', 1);
let buf;
try {
buf = await (await dbPromise).get('databases', dbName);
} catch {
// 首次运行：创建空库并保存默认结构
const SQL = await initSqlJs({ locateFile: () => 'sql-wasm.wasm' });
const freshDb = new SQL.Database();
freshDb.run(`CREATE TABLE items (id INTEGER PRIMARY KEY, quantity INTEGER)`);
await saveDatabase(freshDb, dbName);
buf = freshDb.export();
}
const SQL = await initSqlJs({ locateFile: () => 'sql-wasm.wasm' });
return new SQL.Database(new Uint8Array(buf));
}
// 使用示例
(async () => {
const db = await loadOrCreateDatabase();
db.run("INSERT INTO items VALUES (?, ?)", [100, 42]);
await saveDatabase(db); // 显式调用保存
})();⚠️ 注意事项：
- db.export() 会导出整个数据库状态（含所有表、索引、触发器），体积随数据增长而增大，请合理评估 IndexedDB 容量；
- 不要尝试在 fetch().then(...) 中直接 new SQL.Database(buf) 后立即 db.run() 并期望文件更新——这是根本性误解；
- 若需多标签页实时同步，IndexedDB 需配合 onversionchange 和 onclose 事件做协调，或改用服务端方案；
- 开发阶段可借助 Chrome DevTools → Application → IndexedDB 查看存储内容，验证数据是否正确写入。
总结：SQL.js 本身没有缺陷，而是被赋予了超出其设计边界的期望。真正的“本地持久化数据库网站”，应分层设计——前端用 SQL.js 处理逻辑与查询，持久化层选用 IndexedDB（单用户离线）或服务端 SQLite/PostgreSQL（多用户在线）。明确技术边界，才能构建健壮、安全、可维护的应用。
