SQLite的STRICT表模式从3.37.0版本开始正式提供，它改变了过去建表时列类型只是建议的宽松做法。普通SQLite表使用类型亲和性机制，即使给列声明了TEXT，写入整数时也可能被自动转换成文本保存；反过来，声明为INTEGER的列也可能因为写入文本而得到一个看起来像数字的字符串。这种灵活性在原型开发和小型工具中很方便，但一旦数据库被多个应用、脚本或迁移任务共享，就容易出现同一列里既有整数又有文本的情况。
普通表的类型亲和性到底会带来什么问题
SQLite普通表最容易被误解的一点是，列类型并不会真正限制数据存储。比如创建一张表时写成age INTEGER，插入'25'这条文本数据并不会报错，SQLite会根据列的类型亲和性尝试转换，最终可能保存成一个整数。反过来，如果列类型是TEXT，插入数字25，也可能被转成文本'25'。这种机制本身不是缺陷，它是SQLite为了兼容动态类型而做出的设计，但问题在于不同开发者对类型转换的理解不同，最终数据可能变得难以预测。
一个真实场景是：Python脚本写入用户年龄时使用了字符串'30'，Go服务读取时按照整数解析没问题，但如果某个写入方不小心把'abc'塞进了年龄列，普通表仍然会接受并保存为文本。等到读取端进行数值比较或统计时，就会突然出现类型错误。SQLite的STRICT表模式正是针对这种不确定性提出的解决方案，它要求写入值的存储类必须符合列声明，并且只允许极少数明确的转换。
STRICT表并不能完全替代普通表，也不能替代业务层的数据校验。它更多是给数据库增加一层类型防线，让不合法数据在写入前就被拒绝。与CHECK约束相比，CHECK可以限制取值范围、字符串长度或正则匹配，但它无法强制要求某个值必须是整数还是文本。STRICT表弥补的正是这一缺口。
如何创建STRICT表以及合法类型有哪些
创建STRICT表的语法非常简单，只需要在CREATE TABLE语句的末尾加上STRICT关键字。与普通表不同的是，STRICT表的每一列都必须显式声明类型，而且类型名只能从少数几种中选取，否则建表语句会直接报错。下面是一个合法的STRICT表定义：
CREATE TABLE product (
id INTEGER PRIMARY KEY,
title TEXT NOT NULL,
price REAL,
stock INTEGER,
extra BLOB,
metadata ANY
) STRICT;
在上面的定义中，id使用整数主键，title必须是文本，price使用实数存储价格，stock使用整数保存库存量，extra可以存放二进制数据，metadata则使用ANY类型表示允许任意存储类。SQLite官方允许的类型名包括INT、INTEGER、REAL、TEXT、BLOB和ANY，其中INT和INTEGER等价。
如果尝试使用传统数据库里常见的VARCHAR(255)、DATETIME、BOOLEAN等类型名，STRICT表会直接拒绝建表。例如下面这段SQL无法执行成功：
CREATE TABLE event (
id INTEGER PRIMARY KEY,
name VARCHAR(100),
created_at DATETIME
) STRICT;
这是因为STRICT表取消了类型亲和性带来的类型名宽容度，VARCHAR和DATETIME不属于合法存储类型。对于日期时间，STRICT表通常使用TEXT存储ISO 8601格式字符串，或者使用INTEGER存储Unix时间戳。对于布尔值，则使用INTEGER存储0和1，因为SQLite本身没有独立的布尔存储类。
ANY类型是STRICT表中的一个特殊存在，它相当于显式声明该列可以接受任意存储类。这样做的好处是，当表里大部分字段需要严格约束，而个别字段确实需要灵活存储时，不用为了这一两个字段放弃整张表的STRICT模式。
写入时STRICT表如何执行类型校验
STRICT表的核心行为发生在写入阶段。当一条INSERT或UPDATE语句尝试把值写入某列时，SQLite会检查该值的存储类是否匹配列声明。绝大多数类型不匹配都会直接报错，而不是像普通表那样尽量转换。例如下面这张用户表：
CREATE TABLE app_user (
id INTEGER PRIMARY KEY,
name TEXT NOT NULL,
score INTEGER
) STRICT;
INSERT INTO app_user(name, score) VALUES('Alice', 95);
INSERT INTO app_user(name, score) VALUES(123, 95);
第二条INSERT会失败，因为name列声明的是TEXT，而123是一个整数，整数不会自动转换成文本。这个错误会以SQLITE_CONSTRAINT_DATATYPE的形式返回，调用方可以立刻发现写入逻辑中出现了类型错误。如果同样的情况发生在普通表中，name列会保存成文本'123'，问题就被隐藏了。
STRICT表也允许少量无损且可逆的转换。例如整数可以写入REAL列，因为整数到实数的转换不会丢失信息；没有小数部分的实数也可以写入INTEGER列。格式良好的数字文本，如'95'，可以写入INTEGER或REAL列。但反过来，整数不能写入TEXT列，文本不能写入BLOB列。这种规则相对容易理解，也避免了普通表中各种隐式转换带来的歧义。
NULL值的处理需要单独说明。STRICT表并不会因为列声明了INTEGER或TEXT就自动拒绝NULL，NULL在SQLite中表示缺失值，与类型无关。如果需要强制某列必须有值，仍然要像普通表那样加上NOT NULL约束。例如name TEXT NOT NULL既限制类型为文本，又限制不能为空，两者是独立生效的。
哪些场景适合STRICT表，哪些场景需要谨慎
STRICT表最适合的数据场景是：表结构相对固定、写入来源多、后续要做统计分析或跨系统迁移。比如订单表、用户表、设备采集表，这些数据通常需要长期保存，并且可能由不同语言、不同服务写入。启用STRICT后，整型列不会被塞入文本，文本列也不会混入数字，读取端可以放心地按照声明类型进行反序列化。
如果你正在从其他关系型数据库迁移到SQLite，STRICT表也能让SQLite的行为更接近PostgreSQL、MySQL这类强类型数据库。虽然它仍然没有完整的类型系统，但至少能在存储类层面提供约束。对于已经存在且数据质量较差的表，直接改成STRICT表可能会触发大量写入错误，因此迁移前需要先清洗数据。
已有普通表无法通过一条ALTER语句直接转换为STRICT表，需要创建新表并复制数据。迁移思路是先建一张结构相同但带有STRICT后缀的新表，然后使用INSERT INTO ... SELECT ...把经过清洗的数据写入新表，最后重命名表。这个过程可以借助事务保证一致性。对于正在频繁写入的生产库，建议在低峰期操作，并提前验证旧数据中是否存在违反STRICT规则的异常值。
STRICT表与索引、约束和性能的关系
STRICT表对索引和主键的定义方式没有本质影响，仍然可以使用普通索引、唯一索引、复合索引以及WITHOUT ROWID结构。不过由于STRICT表要求列类型明确，主键列如果使用INTEGER PRIMARY KEY会更自然，也能继续享受SQLite的行号别名优化。如果使用TEXT PRIMARY KEY，则每一行的主键值必须是文本，不能再依赖隐式转换来保存数字主键。
性能方面，STRICT表在写入路径上会增加少量类型检查开销，尤其在高频插入场景下，CPU消耗会比普通表略高。但这个差异通常非常小，远不及磁盘I/O或事务处理带来的影响。对于大多数应用来说，获得的数据一致性收益远大于这部分成本。读取操作基本不受影响，因为STRICT模式主要作用于写入时的类型校验，查询执行计划不会因为表是STRICT而发生显著变化。
需要特别注意的是，STRICT表并不是一个万能的数据清洗工具。它只能保证存储类符合声明，无法判断业务意义上的合法性。例如age INTEGER可以保证age列存的是整数或者格式良好的数字文本转换后的整数，但不能保证年龄在合理范围内。如果还需要限制0到150之间的值，应继续组合使用CHECK约束。STRICT与CHECK、NOT NULL、外键等约束是互补关系，叠加使用能构建出更完整的数据完整性防线。
SQLite STRICT严格表数据完整性修改时间：2026-09-17 22:20:33