后端开发 on Dev TLDRLSS

别被 SQLite 的随性骗了！动态类型陷阱是什么？为什么 ALTER TABLE 是半残的？如何在 Node.js 中做好防御性编程实现无痛数据表升级？

Tue, 19 May 2026 18:10:00 +0800

想象一个资源回收桶，你明明在上面贴了“宝特瓶专用”的标签，结果别人丢了一张纸片进去，它居然默默收下，连一声抗议都没有？

这就是开发者第一次遇见 SQLite 类型系统时的惊悚体验。

如果你习惯了 PostgreSQL 那种严格的海关作风（类型不对直接拒绝入境），SQLite 的随性程度可能会让你怀疑人生。

更恐怖的是，当你想 修改数据表结构 时，它会告诉你：

“数据表改不了，请盖一栋新房子，把家具搬过去，然后把旧房子炸掉。”

SQLite 底层只有 5 种存储类别

不管你在 CREATE TABLE 时宣告了什么华丽的类型名称（VARCHAR(255)、BIGINT、DECIMAL），SQLite 底层只认得这 5 种存储类别：

存储类别	说明
NULL	空值
INTEGER	整数（依数字大小自动占用 1 到 8 bytes）
REAL	浮点数（固定 8 bytes）
TEXT	字符串（默认 UTF-8 编码）
BLOB	二进制数据（原封不动存储）

你在字段上设置的类型，对 SQLite 来说 只是一个“建议”，而不是“强制规定”。

这叫做 “类型亲和性（Type Affinity）”，SQLite 会尝试把你的数据转成建议的类型，但如果转不了，它照样把原始数据塞进去，完全不报错。

你可以在 SQLite 宣告一个 age INTEGER 字段，然后塞入字符串 '永远的十八岁'，它会欣然接受。

三个最容易踩坑的类型陷阱

陷阱 1：没有原生 Boolean

SQLite 没有布尔类型。True 和 False 只能用整数 1 和 0 代替。

当你用 Node.js 从 SQLite 捞出数据时，拿到的会是数字 1 或 0，不是 true 或 false。

如果你直接拿去做 if (user.is_admin === true) 的判断，永远不会成立。

陷阱 2：没有 Date/Time 类型

SQLite 没有日期时间类型。你只能把时间存成：

存储方式	范例	优缺点
TEXT（ISO-8601 字符串）	`'2026-05-19T18:00:00Z'`	最推荐，可读性高，未来搬到 PostgreSQL 可无缝转换
INTEGER（Unix Timestamp）	`1747656000`	占用空间小，但人类不可读

千万不要存像 2026/5/19 下午六点 这种自创格式，否则未来做数据迁移时会是一场灾难。

陷阱 3：字符串塞进整数字段不会报错

在 PostgreSQL，你把字符串塞进 INTEGER 字段会直接报错。但 SQLite 只会默默尝试转换，转不了就原样收下。

这意味着你的数据库里 可能悄悄混进了脏数据，直到某天你的程序因为拿到非预期的类型而崩溃，才会发现问题。

防御性编程：用严格的态度对待随性的数据库

面对 SQLite 的随性，在 Node.js 开发中必须建立起 严格的防御机制：

防御层级	工具	作用
编译期挡错	TypeScript	在代码阶段就挡下错误的类型
API 入口验证	Zod	接收数据时严格验证（确认 age 一定是数字）
底层类型转换	Prisma / Drizzle ORM	自动处理 SQLite 和 PostgreSQL 之间的类型差异

把 “数据验证的守门员” 从数据库层移到 Node.js 应用层，这是同时驾驭 SQLite 开发速度与未来扩展性的关键策略。

使用 ORM 时，你只要在程序里宣告 type: 'boolean'，ORM 存入 SQLite 时自动转成 1/0，拿出来时自动转回 true/false，完美遮蔽底层的类型差异。

ALTER TABLE 是半残的：什么能改、什么不能改

SQLite 对数据表结构的修改支持非常有限：

操作	是否支持
新增字段（`ADD COLUMN`）	支持
重新命名字段（`RENAME COLUMN`）	支持
删除字段（`DROP COLUMN`）	支持（较新版本）
重新命名数据表（`RENAME TO`）	支持
更改字段类型	不支持
增加/移除 `UNIQUE`、`NOT NULL` 限制	不支持
修改 Primary Key	不支持
修改 Foreign Key	不支持

一旦你需要做“不支持”的那些修改，SQLite 会要求你执行 “重建并搬移” 的策略。

重建搬移四步曲：SQLite 的数据表升级之道

既然无法直接改，官方建议的标准做法就是 盖新房子、搬家具、炸旧房子、贴新门牌：

步骤	动作	说明
1	建立新表	`CREATE TABLE users_new (...)` 使用正确的结构
2	复制数据	`INSERT INTO users_new SELECT ... FROM users`
3	删除旧表	`DROP TABLE users`
4	改名	`ALTER TABLE users_new RENAME TO users`

这四个步骤必须 一气呵成，中途断电或程序出错就会造成数据丢失。

确保升级不丢失数据：两道安全防线

防线 1：物理防御，直接复制文件

SQLite 的本质就是一个文件。在执行任何结构变更前，先把 .db 文件复制一份当备份。

const fs = require('fs');
fs.copyFileSync('my_project.db', 'my_project_backup.db');

万一搞砸了，文件盖回去就瞬间复原。这是其他大型数据库做不到的优势。

防线 2：Transaction 包装，数据库的时光机

把搬家的步骤包在一个 Transaction 里面，只要其中一步失败，整个过程就会 自动还原（Rollback），当作没发生过。

const Database = require('better-sqlite3');
const db = new Database('my_project.db');

const migrateData = db.transaction(() => {
  db.prepare(`
    CREATE TABLE users_new (
      id INTEGER PRIMARY KEY AUTOINCREMENT,
      name TEXT NOT NULL,
      age INTEGER NOT NULL DEFAULT 18
    )
  `).run();

  db.prepare(`
    INSERT INTO users_new (id, name, age)
    SELECT id, name, COALESCE(age, 18) FROM users
  `).run();

  db.prepare('DROP TABLE users').run();
  db.prepare('ALTER TABLE users_new RENAME TO users').run();
});

try {
  migrateData();
  console.log('数据表升级成功');
} catch (error) {
  console.error('升级失败，数据已安全还原：', error.message);
}

“备份文件 + Transaction 绑定” 就是你的数据库迁移的安全气囊。

用严格的态度驾驭随性的 SQLite

用 严格的应用层架构 来驾驭随性的 SQLite，享受它极速开发的优势，同时避开未来的技术债。

SQLite 的类型系统很随性，ALTER TABLE 也有诸多限制。

但只要在 Node.js 端做好 TypeScript 类型检查 + Zod 验证 + ORM 抽象层，再搭配 物理备份 + Transaction 的安全策略，你就能安心享受 SQLite 带来的开发效率，同时为未来可能搬移至 PostgreSQL 铺好后路。

Reference

不要什么都用 PostgreSQL！SQLite 的嵌入式架构与零配置优势是什么？SQLite 的极限在哪？什么时候该选 SQLite、什么时候该选 PostgreSQL？

Tue, 19 May 2026 18:00:00 +0800

你有没有想过，你每天打开的浏览器、手机里的通讯软件、甚至桌面上的笔记工具，里面都藏着同一个轻巧的数据库？

它不需要你安装任何服务器软件，不需要设置账号密码，甚至不需要网络连接。它就是一个文件，静静地躺在你的硬盘里，随时准备好为你服务。

这个低调的存在，就是 SQLite。

什么是 SQLite？世界上部署最广泛的数据库

SQLite 是一个用 C 语言编写的 嵌入式关系型数据库引擎。

它没有独立的服务器程序，而是直接嵌入你的应用程序中运作。

这跟你熟悉的 PostgreSQL 或 MySQL 完全不同。传统数据库是一台 独立运作的服务器，你的程序必须透过 网络协议（TCP/IP） 去跟它「通讯」。

但 SQLite 不一样，它就是一段代码，直接跑在你的应用程序里面，读写硬盘上的那个 .db 文件。

比较维度	SQLite（嵌入式）	PostgreSQL（Client-Server）
运作方式	直接嵌入应用程序，无独立服务器	独立服务器程序，透过网络连接
配置需求	零配置，免安装、免帐密	需要安装、配置账号密码与防火墙
数据存储	单一跨平台文件	服务器目录下的多个文件
备份方式	直接复制那个文件	需要使用 pg_dump 等专用工具

正因为这种 「即插即用」 的特性，SQLite 成为了世界上部署最广泛的数据库引擎。

从 Android 和 iOS 操作系统、Chrome 和 Firefox 浏览器，到 Adobe Lightroom、WhatsApp，甚至是 Airbus A350 的飞行系统，处处都有它的身影。

在 Node.js 中使用 SQLite

如果你是 Node.js 开发者，使用 SQLite 非常简单。你不需要在电脑上安装任何数据库服务器软件，只需要安装一个 npm 套件就能开始。

目前行业最常用的选择：

套件名称	特点	建议情境
`sqlite3`	最老牌，支持异步 API	需要大量同时处理多个异步任务
`better-sqlite3`	性能极佳，API 设计直观，速度极快	首选推荐，追求开发效率与执行速度

用 better-sqlite3 建立数据库并查询，不用五分钟就能完成：

const Database = require('better-sqlite3');
const db = new Database('my_project.db');

db.prepare('CREATE TABLE IF NOT EXISTS users (name TEXT, age INTEGER)').run();

const insert = db.prepare('INSERT INTO users (name, age) VALUES (?, ?)');
insert.run('John', 25);

const user = db.prepare('SELECT * FROM users WHERE name = ?').get('John');
console.log(user); // { name: 'John', age: 25 }

如果文件不存在，better-sqlite3 会 自动帮你建立。

SQLite 支持的 SQL 语法比你想的强大

很多人以为 SQLite 很阳春，但它支持绝大多数的标准 SQL 语法，包含许多进阶功能：

语法类别	支持项目
基础操作	`SELECT`、`INSERT`、`UPDATE`、`DELETE`
数据定义	`CREATE TABLE`、`CREATE INDEX`、`CREATE VIEW`
进阶查询	`WITH` （CTE 递归查询）、窗口函数（Window Functions）
冲突处理	`UPSERT` （`INSERT ... ON CONFLICT DO UPDATE`）
JSON 处理	`json_extract`、`json_array`、`json_object` 等内建函数
事务控制	`BEGIN`、`COMMIT`、`ROLLBACK`、`SAVEPOINT`
连接查询	`INNER JOIN`、`LEFT JOIN`、`RIGHT JOIN` 和 `FULL OUTER JOIN`

SQLite 的核心哲学是「小而美」，它支持多数你日常需要的 SQL 能力，同时保持极致的轻量。

SQLite 的极限在哪？

轻巧是有代价的。如果把 SQLite 比喻为一间 只有一个结账柜台的文青杂货店，那 PostgreSQL 就是 配备 50 个收银台的好市多。

1. 写入大塞车

SQLite 在写入数据时，会把整个数据库文件 锁起来。

想像一间 只有一间厕所的餐厅：100 个人可以同时在外面看菜单（读取），但只要有 1 个人进去把门锁上（写入），其他人就只能排队等。

虽然开启 WAL 模式（Write-Ahead Logging） 能改善读写并行的性能，但本质上仍然无法做到多线程同时写入不同的数据行。

2. 无法跨多台服务器

SQLite 的本质就是一个实体文件。如果你的系统部署在多台服务器上（水平扩展），这些服务器 无法安全地共用同一个文件。

3. 缺乏精细的权限管理

SQLite 没有「使用者账号」的概念。谁能在操作系统层面读取那个 .db 文件，谁就能看光、修改所有数据。

对于 需要严格个资审查的商务系统，这是无法接受的。

SQLite vs. PostgreSQL：技术选型决策

工具没有好坏，只有适不适合。以下是一份帮助你做决策的终极检核表：

提問	答「是」→ 选 SQLite	答「否」→ 选 PostgreSQL
后端服务器是不是只有一台，或完全跑在本机端？	是	否（有水平扩展、多台机器）
系统行为是不是读远远大于写，且没有高频并行写入？	是	否（大家会同时抢着写入）
不需要精细的数据库账号权限或进阶索引？	是	否（极度依赖进阶功能）

更具体的情境对照：

情境	推荐选择	理由
桌面软件、手机 App、IoT 设备	SQLite	数据跟着设备走，免安装
个人部落格、展示型官网	SQLite	读多写少，省去维护服务器成本
快速原型开发、Demo	SQLite	建个文件就能开工
社区论坛、电商平台	PostgreSQL	高并发写入，需要行级锁
多台服务器分散部署	PostgreSQL	需要跨机器共享数据源
医疗、金融等敏感系统	PostgreSQL	需要严格的角色权限管控

你的数据库是随身笔记还是中央总机

如果数据是 「单机、静态、单一拥有者」，选 SQLite 享受极致的轻量与自由；

如果数据是 「云端、動態、高度互动」，让 PostgreSQL 接管。

SQLite 的核心哲学是 「应用程序的内部元件」，而 PostgreSQL 的定位是 「系统架构的独立中枢」。

下次在架构决策时，别急着拿出 PostgreSQL，先问问自己：

「我的数据库，是拿来当随身笔记，还是中央总机？」

答案清楚了，选择自然就明确了。