sqlite无法用触发器维护自增主键连续性，因integer primary key本质是rowid别名，其值在语句解析阶段即由内部机制确定，触发器既无法干预分配过程，也不能修改已生成id；强行追求连续性会导致锁表、性能下降与数据混乱，应改用应用层serial_no或窗口函数生成序号。
SQLite 无法用触发器维护自增主键的连续性——这不是配置问题，而是设计限制。INTEGER PRIMARY KEY 本质是 ROWID 别名，其值由 SQLite 内部页管理机制决定，触发器无权读写 ROWID 或干预分配逻辑。
为什么触发器根本不能干预主键生成
触发器在 INSERT 语句执行「之后」（AFTER）或「之前」（BEFORE）运行，但主键值在语句解析阶段就已确定：
-
INSERT INTO t (id, name) VALUES (NULL, 'a')：NULL 被 SQLite 立即替换为下一个 ROWID，这个动作发生在触发器可见之前 -
INSERT INTO t (id, name) VALUES (5, 'b')：若 5 已存在，违反主键约束直接报错UNIQUE constraint failed: t.id，触发器根本不执行 - 触发器内部无法调用
last_insert_rowid()来“修正”已分配的 ID，也不能用 UPDATE 修改刚插入行的id字段（会触发新触发器，且可能破坏一致性）
所谓“连续性”需求本身在 SQLite 中就是危险信号
连续 ID 不是 SQLite 的设计目标，强行追求会导致严重副作用：
- 高并发下必须加表锁才能检查“下一个可用 ID”，性能断崖式下降
- DELETE + INSERT 组合操作中，
AUTOINCREMENT表的sqlite_sequence表会被更新，但普通INTEGER PRIMARY KEY表会复用已删 ID——两种行为并存时业务逻辑极易混乱 - 备份恢复、ATTACH 数据库、WAL 模式切换等场景下，ROWID 分配顺序不可预测，任何依赖连续性的代码都会失效
如果业务真需要有序编号，该怎么做
必须放弃“主键连续”幻想，改用应用层可控的方案：
- 新增一个
serial_no INTEGER列，不设主键，用应用逻辑或单独的计数器表（带SELECT ... FOR UPDATE）生成递增编号 - 查询时用
ORDER BY rowid或ORDER BY created_at保证结果顺序，而非依赖 ID 数值连续 - 导出报表类场景，用窗口函数
ROW_NUMBER() OVER (ORDER BY created_at)动态生成序号，避免存储冗余
最常被忽略的一点：SQLite 的 ROWID 是 64 位整数，从 1 开始分配，实际撞上限的概率远低于应用误用触发器强行重排导致的数据损坏概率。
