必须先剥离敏感字段结构，Navicat 不自动识别 password、id_card 等敏感字段，直接生成会写入空值或残留数据；正确做法是预览 SQL 确认字段已移除或替换，并用脚本替代 GUI 实现可复现脱敏逻辑。
生成前必须先剥离敏感字段结构
navicat 本身不会自动识别哪些字段是敏感的，比如 password、id_card、email 或 phone。如果你直接对原表启用数据生成，它会照常填充这些字段——哪怕你没勾选它们，只要字段存在且允许 null 或有默认值，就可能被写入空值、随机字符串甚至原始生产残留值。
正确做法是：在生成前，先用 Navicat 的「表设计」功能，把敏感字段设为 NOT NULL DEFAULT ''（或 NULL），并确认其类型不触发隐式填充（如 TEXT 字段若没设默认值，生成时可能填入空字符串而非跳过）。
- 对 MySQL，特别注意
ENUM和SET类型字段——Navicat 生成器不支持自定义枚举值，若字段含敏感语义（如status ENUM('active','deleted','blocked')），需手动改用VARCHAR避免误填 - 外键字段若指向含敏感字段的主表（如
user_id → users(id)），即使子表无敏感字段，也要确保主表已按同样规则清理过结构，否则生成时可能因主表数据缺失导致失败 - 避免依赖“取消勾选字段”来排除敏感项——Navicat 的勾选状态只影响生成器配置界面，不修改实际 INSERT 语句的字段列表；最终是否写入，取决于你预览 SQL 里有没有该字段名
预览 SQL 是唯一可信的校验环节
很多人点完“开始生成”才发现 password 字段被写了进去，问题就出在跳过了「预览」步骤。Navicat 的预览功能展示的是真实将被执行的 SQL，不是示意效果图。
必须逐条检查预览窗口中的每条 INSERT INTO 语句：
- 确认括号内字段列表不含任何敏感字段名（如
INSERT INTO users (id, name, email) ...中不能出现password） - 如果用了表达式替换（如把
email改成CONCAT('test+', FLOOR(RAND()*1000), '@example.com')），要核对VALUES中对应位置确实是表达式，而不是原始列引用 -
UPDATE语句容易被忽略——即使INSERT没带password，同步或后续脚本若含UPDATE users SET password = ?，仍会造成泄露
只要预览里出现敏感字段名，说明映射规则没生效，或该字段被其他规则（如“全部字段自动填充”）覆盖了。
用脚本替代 GUI 实现可复现的脱敏逻辑
Navicat 的图形化生成配置无法版本化、不可审计、不支持条件分支，团队协作时极易失准。例如，A 同事设的日期范围是 “2020–2025”，B 同事设的是 “最近90天”，两者生成的数据分布完全不可比。
真正可控的方式是把脱敏规则外移到脚本中：
- 用 Python +
sqlalchemy读取 YAML 配置，对每个表声明哪些字段要跳过、哪些要用固定脱敏值（如email: 'REDACTED@EXAMPLE.COM'）、哪些走正则生成（如phone: '1[3-9]\d{9}'） - 用 MySQL 原生函数写 SQL 脚本：比如
INSERT INTO users SELECT id, name, MD5(CONCAT(id,'salt')) AS password, ... FROM source_users，明确控制每列来源 - 把脚本和配置一起提交 Git，每次生成前
git checkout到指定 commit，保证环境一致
Navicat 可以作为初始验证工具：先跑 100 行预览导出 CSV，再让脚本输出同样行数，用 diff 对比字段格式与空值比例，确认脱敏逻辑对齐。
别指望 ER 模型自动帮你过滤敏感字段
有人试图在 Navicat 17 的 ER 模型里给字段加注释标记 “sensitive”，然后幻想数据生成时能自动跳过——这不会发生。ER 模型只是结构图纸，不参与任何数据操作，也不读取字段注释或备注内容。
模型里能做的只有两件事：
- 在字段【备注】栏手动写
[SENSITIVE]，作为视觉提醒，但生成器完全无视它 - 逆向工程后用【检查模型】→ “验证外键引用完整性” 找出孤立字段，间接发现可能冗余又敏感的副本（如多个表里的
real_name），但这属于设计阶段清理，不是生成阶段脱敏
真正的脱敏动作，永远发生在物理表连接上下文里，且必须通过显式配置或代码控制。模型画布上多漂亮的红锁图标，也挡不住一条没检查过的 INSERT 语句。
