Navicat 无法直接删除 SQLite 表字段，因其不支持原生 DROP COLUMN，实际执行静默表重建，易丢数据、破坏约束；需手动通过备份、建新表、重命名、补约束三步安全操作。
navicat 无法直接删除 sqlite 表字段——它根本不会执行 drop column，因为 sqlite 原生不支持该语法；点“保存”后实际触发的是静默表重建流程，极易丢数据或破坏约束。
为什么 Navicat 点“删字段”后没反应或数据丢了
SQLite 自 3.35.0 起才实验性支持 ALTER TABLE ... DROP COLUMN，且需启用 PRAGMA legacy_alter_table = OFF，而 Navicat（截至 v17.0）仍基于旧版驱动，完全忽略该特性。你删掉字段再点保存，Navicat 会走和改类型一样的重建路径：CREATE TABLE new_... → INSERT INTO new_... SELECT ... → DROP TABLE old → ALTER TABLE new_... RENAME TO old。整个过程不校验、不提示、不回滚。
- 原表若有
NOT NULL字段被删，新表对应列默认变成NULL，但 Navicat 不提醒 - 如果原表有
AUTOINCREMENT主键，重建后该属性丢失，新插入 ID 可能从 1 开始重复 - 外键、
CHECK、UNIQUE约束全部清空，除非你在设计器里手动重新勾选 - 若
SELECT导数据时某行含NULL值，而目标列在新表中被设为NOT NULL，整条INSERT失败，但 Navicat 不报错，只静默跳过该行
手动执行安全删字段的三步法（推荐）
绕过 Navicat 的不可控重建，用原生命令+备份控制风险。核心是：先备份 → 改结构 → 验证 → 清理。
- 关闭所有连接该数据库的程序（包括 Python 脚本、VS Code 插件、另一个 Navicat 标签页），避免 WAL 文件残留干扰
- 用命令行备份：
sqlite3 /full/path/to/db.db ".dump" > backup.sql（确保可完整还原） - 新建临时表，只包含要保留的字段：
CREATE TABLE t_new AS SELECT id, name, email FROM users; - 删旧表：
DROP TABLE users;，再重命名：ALTER TABLE t_new RENAME TO users; - 手动补约束：
PRAGMA foreign_keys = ON;后，用CREATE INDEX和PRAGMA integrity_check验证
Navicat 里删字段前必须检查的三件事
如果你坚持用 Navicat 界面操作，这些检查不做，大概率丢数据。
- 确认当前表没有被其他进程占用：终端运行
lsof | grep your.db（macOS/Linux）或handle.exe your.db（Windows），确保输出为空 - 检查 WAL 模式是否关闭：在 Navicat 查询窗口执行
PRAGMA journal_mode;，如果不是delete，先运行PRAGMA journal_mode = delete;并重启连接 - 手动导出当前表数据为 CSV 或 SQL：右键表 → “导出向导”，选“SQL 插入语句”，存为
users_backup.sql，以防重建失败后手动恢复
真正麻烦的不是删字段本身，而是 Navicat 把“不可见的重建”包装成“点击保存就搞定”的假象。它不展示 SQL、不校验数据兼容性、不保留约束细节——这些都得你提前肉眼核对、手动兜底。
