PWA的离线能力本质上是一套资源缓存与数据存储方案的组合，但大多数项目在数据层仍然停留在IndexedDB的简单键值对操作上。当业务需要多表关联查询、聚合统计或者严格的事物回滚时，IndexedDB的异步游标接口会让代码迅速膨胀。SQLite作为嵌入式关系型数据库，在移动端和桌面端已经证明了其稳定性和易用性，那么在浏览器环境中它是否也能承担起离线数据引擎的角色？答案是肯定的，借助WebAssembly技术，SQLite可以完整地运行在浏览器沙箱中，为PWA提供接近原生的SQL操作体验。
SQLite在浏览器中的几种运行形态
要在PWA中使用SQLite，首先得理解浏览器端与本地环境的差异。原生SQLite是一个跨平台的C库，浏览器无法直接加载动态链接库，因此必须将C代码编译为WebAssembly字节码，再通过JavaScript胶水代码调用。目前社区主要有两种成熟方案：一是使用sql.js，它把SQLite编译成单个wasm文件并提供一套JavaScript API，特点是轻量、易上手，但默认数据只存在于内存中，需要手动序列化到IndexedDB或文件系统；二是使用SQLite Wasm官方包，从SQLite 3.40版本起官方提供了面向浏览器的编译产物，支持持久化到OPFS（Origin Private File System），这个方案更贴合PWA的离线持久化需求。
如果只把SQLite当作内存数据库来用，那它的意义会大打折扣。sql.js适合用来做教学演示或处理临时数据，而真正要落地到PWA项目，推荐使用官方SQLite Wasm包并配合OPFS。OPFS是Chrome 102+引入的浏览器私有文件系统，每个源都有独立的存储空间，比IndexedDB更适合存储二进制大对象和频繁读写的数据库文件。通过OPFS，SQLite数据库文件可以像原生磁盘文件一样被打开、锁定和关闭，极大提升了读写性能。
在PWA项目中集成SQLite的完整流程
集成过程分为依赖引入、Worker初始化、数据库操作封装三个步骤。首先在HTML中通过ES模块导入官方包：
import initSqlJs from 'https://cdn.jsdelivr.net/npm/@sqlite.org/sqlite-wasm@3.45.0/+esm';
因为OPFS的访问权限在Worker上下文中更加灵活，建议把SQLite相关逻辑放在Web Worker中执行，主线程通过postMessage发送SQL命令。下面是一个基于Worker的初始化示例，它会打开或创建一个名为app.db的数据库文件：
// worker.js
import initSqlJs from 'https://cdn.jsdelivr.net/npm/@sqlite.org/sqlite-wasm@3.45.0/+esm';
let db;
self.onmessage = async (event) => {
const { type, payload } = event.data;
if (type === 'init') {
const sqlite3 = await initSqlJs({
locateFile: file => `https://cdn.jsdelivr.net/npm/@sqlite.org/sqlite-wasm@3.45.0/${file}`
});
db = new sqlite3.oo1.DB('/opfs/app.db', 'ct');
db.exec('CREATE TABLE IF NOT EXISTS notes (id INTEGER PRIMARY KEY AUTOINCREMENT, title TEXT, content TEXT, updated_at INTEGER)');
self.postMessage({ type: 'ready' });
} else if (type === 'query') {
const rows = db.selectObjects(payload.sql, payload.params);
self.postMessage({ type: 'result', rows });
} else if (type === 'exec') {
db.exec(payload.sql, { bind: payload.params });
self.postMessage({ type: 'done' });
}
};
主线程侧需要负责创建Worker并封装异步API。下面的代码展示了如何初始化并执行一条插入语句：
// main.js
const worker = new Worker('worker.js', { type: 'module' });
worker.onmessage = (e) => {
if (e.data.type === 'ready') console.log('SQLite ready');
else if (e.data.type === 'result') console.table(e.data.rows);
};
worker.postMessage({ type: 'init' });
function insertNote(title, content) {
worker.postMessage({
type: 'exec',
sql: 'INSERT INTO notes (title, content, updated_at) VALUES (?, ?, ?)',
params: [title, content, Date.now()]
});
}
注意到Worker中使用了oo1.DB接口，这是SQLite Wasm官方提供的高级对象封装，相比底层API可以少写很多样板代码。数据库文件路径/opfs/app.db中的/opfs/前缀是虚拟文件系统映射，实际存储在浏览器分配的私有源空间中。如果浏览器不支持OPFS，可以回退到IndexedDB VFS，但性能会有所下降。
性能优化与存储配额管理
SQLite在浏览器中的性能优势主要体现在复杂查询和事务处理上。以1万条记录的聚合查询为例，使用IndexedDB需要手动遍历游标并在JavaScript中累加，而SQLite一条SELECT COUNT(*)语句即可在毫秒级完成。对于需要离线同步的场景，SQLite支持完整的ACID事务，配合BEGIN IMMEDIATE可以防止并发写入冲突。
但浏览器存储并非无限可用。Chrome对每个源的存储配额通常为磁盘剩余空间的60%，当数据量接近配额时，写入操作会抛出QuotaExceededError。在PWA中需要监听navigator.storage.estimate()返回的配额信息，并在写入前做预检查。此外，数据库文件如果过度膨胀，可以执行VACUUM命令回收空间。对于需要长期保留的数据，建议结合Background Sync API定时将增量变更推送到服务端，避免本地数据成为孤岛。
与IndexedDB的选型对比与混合策略
选择SQLite还是IndexedDB，取决于数据模型的复杂度和团队的技术栈。如果只是存储用户偏好设置或少量键值对，IndexedDB的简单接口足够应对；但如果需要存储订单、商品、日志等结构化数据，并涉及多表关联查询，SQLite能显著降低代码复杂度。一个折中的做法是：用SQLite作为主数据库存储业务数据，用IndexedDB保存非结构化的缓存文件（如用户头像、离线图片），两者通过主键关联。
需要注意的是，SQLite Wasm包体积通常在500KB左右，首次加载会消耗额外带宽。对于性能敏感的场景，可以将wasm文件通过Service Worker预缓存，实现秒开。另外，所有SQL操作都应放在Worker中执行，避免阻塞主线程导致页面卡顿。随着浏览器对WASM和OPFS的支持越来越完善，SQLite在PWA中的应用门槛会进一步降低。