应统一命名规范、用脚本清洗字段、建立映射表；优先查information_schema获取元数据；TS需结合is_nullable和column_default判空，禁用undefined；MyBatis-Plus需显式指定表名并配置类型转换。
结构面板里导出的字段名和数据库实际不一致怎么办
直接拿结构面板（比如 navicat、dbeaver 或 mysql workbench 的表结构视图）生成代码，最容易翻车的就是字段命名映射错位——面板显示 user_name，但后端实体类用了 username，前端又写成 username，结果接口一调就 400 或字段为空。
核心问题不是“能不能导”，而是“导出来谁来对齐”。结构面板本身不带语义转换能力，它只忠实地展示 column_name 和 data_type。
- 导出前先统一命名规范：在数据库建表时就用下划线（
snake_case），避免混用驼峰或全大写； - 导出后别直接粘贴，用脚本做一次清洗——比如用 Python 的
re.sub(r'_([a-z])', lambda m: m.group(1).upper(), field)批量转驼峰； - 前后端都约定一个“字段映射表”：比如
{ "user_name": { "java": "userName", "ts": "userName", "db": "user_name" } }，生成工具读这个表，而不是硬编码转换逻辑。
用 DBeaver 的“生成 DDL”功能反向提取表结构是否可靠
可以，但只适合单表、无外键/约束变更频繁的场景。DBeaver 的 Generate DDL 输出的是建表语句，不是结构元数据，它会把注释、索引、外键全塞进去，导致解析困难。
真正要喂给 CRUD 生成器的，是干净的字段列表：列名、类型、是否为空、默认值、注释。DDL 里这些信息藏在不同位置，正则一抽就漏。
- 优先用 JDBC 直连查
information_schema.columns表，SQL 简单稳定：SELECT column_name, data_type, is_nullable, column_default, column_comment FROM information_schema.columns WHERE table_name = 'user' AND table_schema = 'mydb'； - 如果必须用 DBeaver 导出，选“Export as CSV”而非“Generate DDL”，CSV 字段对齐清晰，Excel 也能直接筛；
- 注意
column_comment在 MySQL 8.0+ 才完整支持，低版本可能为空，别依赖它生成 API 文档。
前端用 TypeScript 自动生成 interface 时，null 和 undefined 怎么处理
TypeScript 的 strictNullChecks 开着时，数据库里允许为 NULL 的字段，对应到 TS 类型就得显式写成 string | null 或 number | undefined，否则编译报错——但结构面板根本不告诉你哪个字段真会为 NULL，只显示 is_nullable = 'YES'。
这会导致两种误判：一种是把非空字段标成可空，后续校验松动；另一种是把可空字段标成必填，运行时报 Cannot read property 'xxx' of null。
- 查
is_nullable是基础，但还要结合column_default：如果默认值是NULL或空字符串，且没设NOT NULL，大概率业务上允许为空； - 生成脚本里加个白名单配置，比如
["created_at", "updated_by"]这类时间/操作人字段，即使 DB 允许 NULL，TS 也强制标为Date | null； - 别自动生成
undefined——TypeScript 中undefined多用于未初始化变量，而数据库 NULL 对应的是null，二者语义不同，混用会让类型检查失效。
Java 后端用 MyBatis-Plus 的 AutoGenerator 为什么经常生成失败
因为 AutoGenerator 默认只认标准 JDBC URL 和驱动，一旦你用的是 ShardingSphere、TiDB 或带 SSL 的云数据库，它连不上，或者连上了却查不到表——它底层调的还是 DatabaseMetaData.getTables()，而某些代理层会屏蔽元数据查询。
更隐蔽的问题是：它默认把所有表当普通表处理，遇到视图、临时表、分区表就会抛 Table not found 或字段缺失。
- 先确认连接串能用
mysql -h xxx -u yyy -p手动连通，再测SELECT 1，排除网络和权限问题； - 禁用自动扫描，改用
setTableNames("user", "order")显式指定表名，绕过getTables()的兼容性坑； - 字段类型映射表（
globalConfig.setColumnTypeConvert()）必须配全，比如 MySQL 的TINYINT(1)默认被当成 Boolean，但如果你存的是状态码，就得重写转换器返回Integer。
真正难的不是生成动作本身，是让生成结果能直接进 Git、能跑通单元测试、能被其他开发者一眼看懂字段来源——这些靠结构面板点几下解决不了，得在生成流程里嵌入校验环节，比如生成后自动 diff 字段注释和数据库 comment 是否一致。
