navicat 16 的 sqlite 表设计器不支持直接修改字段类型，点“保存”会静默触发不可见、不可控的表重建流程，易丢数据或破坏约束；实际执行“建新表→导旧数据→删旧表→改名”四步，但不展示真实sql、不校验兼容性、默认丢弃外键/not null/check约束，且autoincrement可能失效。
navicat 16 的 sqlite 表设计器不支持直接修改字段类型——点“保存”不会生成 alter table ... modify column，因为 sqlite 根本不支持这个语法；它会静默触发表重建流程，但整个过程不可见、不可控，极易丢数据或破坏约束。
SQLite 字段类型修改在 Navicat 里实际走的是重建流程
SQLite 原生命令只允许 ALTER TABLE ... ADD COLUMN 和 ALTER TABLE ... RENAME TO，改类型必须靠“建新表 → 导旧数据 → 删旧表 → 改名”四步。Navicat 16 在你点“保存”后自动执行这套逻辑，但不展示中间 SQL，也不校验数据兼容性。
- 你改一个
TEXT字段为INTEGER，Navicat 会生成CAST(... AS INTEGER)，但遇到非数字字符串（如"N/A"）时直接转成0，无警告 - 外键、
NOT NULL、CHECK约束默认被丢弃，除非你在“设计表”界面手动重新勾选 - 如果原表有
PRIMARY KEY AUTOINCREMENT，重建后该属性可能失效，新插入的 ID 从 1 开始重复
点“保存”前必须手动检查三件事
Navicat 不会弹窗确认，也不会回滚失败操作。一旦执行，旧表已删，新表若因类型转换失败而中断，数据就丢了。
- 拉到设计器底部，看“SQL 预览”面板——这里显示的不是真实执行语句，而是 Navicat 自己拼的示意 SQL，不能代替实际验证
- 右键表 → “对象信息” → 切换到“DDL”页，复制当前建表语句，手动比对字段定义、约束、主键是否完整保留
- 确认目标类型能容纳现有数据：比如把
TEXT改REAL，先跑一遍SELECT COUNT(*) FROM table WHERE typeof(col) != 'real' AND col NOT LIKE '%[^0-9.]%'（粗略筛异常值）
更安全的做法：切到查询窗口手写重建逻辑
依赖图形界面改类型风险太高。真要改，建议用 SQL 显式控制每一步，尤其涉及非空、默认值、自增等关键属性时。
- 用
PRAGMA table_info(table_name)查原始结构 - 手写
CREATE TABLE table_name_new (...)，显式声明所有约束 - 用
INSERT INTO table_name_new SELECT CAST(col AS new_type), ... FROM table_name控制转换逻辑 - 加
PRAGMA foreign_keys = OFF（如有外键），再DROP TABLE table_name+ALTER TABLE table_name_new RENAME TO table_name
SQLite 的字段类型是“亲和性”（affinity）而非强类型，很多场景其实不需要改——比如用 TEXT 存日期，在查询时用 strftime() 处理即可。强行重建表，反而容易把简单问题搞复杂。
