完整总结 + 实施步骤如下（按你最终口径）：
一、最终统一口径 规则来源
统一来自 geDomainModel 返回的元数据：*FieldMeta（如 TextFieldMeta）+ Meta 基类。 默认值、默认长度、校验约束都由 Meta 提供（可扩展属性）。 既有运行时定义
后端运行时/领域对象以既有定义为准：TextField + 基类（你们现有体系）。 保存不是“前端传啥存啥”，而是后端转领域对象后再落库。 保存阶段边界
按 Meta 做默认值补齐（仅缺失补，不覆盖用户输入）。 做输入合法性校验（例如最大长度、格式、范围、必填、引用存在性）。 最终序列化 JSON 持久化到 md_entity_definition。 分层
entity：语义字段（不放建表约束） table：物理建表字段（放 Unique/Indexed/PrimaryKey） 即： entity 不要 Unique/Indexed/PrimaryKey table 要 Unique/Indexed/PrimaryKey 前端职责
仅输入与展示，不写死业务默认规则。 保存前只做结构规范化与必要兜底提示，不定义业务规则真相。 二、你当前问题的根结（已对齐） 历史 Items/entity 双结构不一致导致删改回滚、字段“复活” 前端曾写死默认逻辑与空串处理，和后端校验口径冲突 列表/过滤绑定字段空值导致后端报错 三、实施步骤（按优先级） P0（先落地，止血） 后端保存入口统一规范化 入参先 normalize（trim、空值处理、结构对齐）。 entity/table 分离处理 entity 剔除 Unique/Indexed/PrimaryKey table 保留 Unique/Indexed/PrimaryKey 返回 4xx 业务错误而不是 500 包含字段路径，便于前端定位。 P1（核心改造） 接入 Meta 驱动 用 geDomainModel 的 *FieldMeta + 基类Meta 作为默认/校验来源。 映射到既有定义对象 字段映射到你们既有 TextField + 基类对象体系。 保存链路 payload -> meta补默认 -> 合法性校验 -> 序列化 -> md_entity_definition P2（收敛与清理） 前端移除硬编码默认规则 不再写死长度/默认值。 只保留必要 payload 去掉运行态冗余字段（Type/Type/等非必要项）。 读写口径统一 页面回显以 md_entity_definition 反序列化结果为准。 四、我接下来“马上要做”的事（执行清单） 清理前端保存前硬编码默认逻辑（长度/默认值推断全部去掉）。 保留前端最小结构规范化（只做字段裁剪与引用必填兜底提示）。 对齐 entity/table payload 白名单： entity 不发 Unique/Indexed/PrimaryKey table 继续发这三项。 在保存失败提示中展示后端返回的字段路径（可定位到具体列）。 为你准备后端改造接口契约草案（geDomainModel 规则字段映射表 + 保存校验返回结构）。
