spring data jpa 的 save() 方法执行全量覆盖更新，若表单未提交全部字段，缺失字段在实体中为 null 或默认值，导致数据库对应字段被错误覆盖为空；正确做法是先 findbyid() 查询原实体，再合并修改字段后 save()。
Data truncation 错误不是前端问题，而是数据库字段长度或类型不匹配的明确信号。 它发生在数据从应用层写入数据库时被截断或拒绝，浏览器和表单本身通常无报错、无提示，但后端日志或 SQL 异常里会清晰暴露 Data truncation: Data too long for column 'xxx' at row xxx 或类似 Incorrect double value 信息。
为什么 form 提交后某些字段变空或报错？
根本不在 HTML 或 JavaScript 层面，而在数据落库前的校验与映射环节。常见触发点包括：
- 数据库字段定义为
VARCHAR(10)，但前端传入 15 个字符的字符串，MySQL 直接截断并抛出警告（严格模式下则报错） - 字段类型是
DOUBLE，但传入空字符串""、"N/A"或带空格的" 123 "，MySQL 无法转换，触发Incorrect double value - 实体类中某字段标注了
@Column(length = 20)，但数据库实际是VARCHAR(10)，JPA 插入时按注解生成 DDL 不生效，运行时仍以 DB 实际结构为准 - 表单中漏掉某个必填字段（如隐藏的
id），后端用 Spring Data JPA 的save()全量更新，缺失字段被设为null写入——这不是截断，但效果类似“数据丢失”
form 中没填的字段为什么会变成 NULL？
这是典型的全量更新逻辑缺陷，和数据库截断无关，但用户感知一致：改完提交，原来的数据没了。
- Spring Data JPA 的
save(entity)默认行为是“插入或全量替换”，不会做字段级 diff - 如果表单没包含
created_at、status等只读字段，它们在 entity 中就是null或默认值，直接覆盖原值 -
@Column(updatable = false)可阻止该字段被 UPDATE 语句包含，但前提是 JPA 生成的 SQL 确实跳过它（需确认方言和版本） - 更稳妥的做法是：用
findById()查出原记录，仅 set 修改项，再save()—— 或改用EntityManager.merge()配合脏检查
如何快速定位是哪一列触发了 Data truncation？
别猜，看异常堆栈里的具体字段名和行号，再交叉验证三处定义是否对齐：
- 数据库实际结构：
DESCRIBE table_name;看Field、Type、Null列 - Java 实体类字段：
@Column(name = "xxx", length = N)或 Lombok@Data生成的 setter 是否隐式接受超长输入 - 前端传参内容：用浏览器 Network 面板看 Form Data，确认
xxx字段值长度、是否含不可见字符（如 BOM、零宽空格） - 额外注意：MySQL 5.7+ 默认开启严格模式（
STRICT_TRANS_TABLES），非严格模式下只警告不报错，容易掩盖问题
真正麻烦的从来不是“怎么修”，而是“谁该负责校验”。前端 trim 和 maxlength 只是掩耳盗铃；后端 DTO 层的 @Size、@DecimalMin 是第一道防线；但最终，数据库字段定义 + 应用层类型映射必须物理对齐——少一个环节，就可能在线上静默丢数据。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
