Angular与Spring JPA应用PUT请求新增标签时名称为null问题排查

这些问题的根源完全是前端传值结构错配+后端关联逻辑不规范导致的，和Heroku部署、实体注解配置没有关系，Postman能复现的现象也完全匹配这个判断。 #

前端代码的核心错误 #

• 取值逻辑从根上就错了：在addTag()里写的this.expert.tags.push(this.formGroup.value)完全不对。你创建的this.formGroup是整个顶层表单的实例，因为表单里只配置了tags这一个表单项，它的value结构是{ tags: [所有表单内的tag输入值] }，你把这个嵌套结构的整体对象当成单个tag元素塞到expert的tags数组里。这种嵌套对象传到后端时，根本没有顶层的name属性，后端序列化映射Tag实体时自然读不到值，最后存成null。
• 提交时机完全不对：现在每往表单数组里加一个tag输入框，就立刻触发一次PUT请求。这也是返回结果里原有标签重复N次的原因——每次请求都会把当前expert.tags里的所有元素（包括那些结构错位的嵌套对象）全量传给后端叠加。

前端修复参考：

• 不要在添加表单控件的时候直接操作expert对象，更不要加一个输入框就发一次请求。等用户填完所有标签、点最终提交按钮时，再从tagsArray里逐个取出每个输入项的有效值（结构是扁平的{name: "输入的标签文本"}），合并到expert的tags列表里，再调用更新接口。
• 彻底改掉直接push整个formGroup.value的写法，取表单数组里单个控件的输入值，保证传给后端的每个tag元素都是带顶层name字段的扁平结构。

后端代码的核心错误 #

• 关联处理没有任何校验：现在直接把前端传来的所有tag全量addAll到专家的关联列表里，既不检查tag有没有合法的name字段，也不判断专家是不是已经关联过这个标签，更不区分传过来的tag是数据库已存在的托管实体、还是需要处理的临时对象。
• JPA持久化逻辑写得太粗糙：前端通过请求传过来的Tag对象是脱离持久化上下文的临时对象，直接add到处于托管状态的Expert实体关联列表里时，JPA会把这些没有正确赋值的临时对象当成全新实体持久化，自动生成自增主键ID，但因为字段映射错位，name字段始终是null。
• 多对多关联没有去重逻辑：每次更新都全量叠加传过来的所有tag，不校验已有的关联关系，这也是返回结果里同一个php标签重复4次、c++标签重复4次的原因。

这也解释了为什么用Postman直接测试也会复现null标签的问题——只要请求体里的tag结构不符合后端的映射要求，无校验的addAll逻辑就会把这些结构错位的对象持久化，生成新的自增ID，但因为没有匹配到正确的name字段，最终存储的值就是null。

后端修复参考：

• 遍历前端传来的tag列表时，先做合法性校验：如果tag的name为空，直接跳过不处理。
• 区分已有标签和新标签：如果tag带有效的数据库ID，就从持久化上下文查出对应的托管Tag实体，判断当前专家是否已经和这个Tag建立过关联，没有关联再添加关系，避免重复叠加。
• 对没有ID的新tag，先根据name查询数据库是否已有同名的Tag实体，有就直接用已有实体建立关联，没有再新建带正确name值的Tag实体建立关联，绝对不要直接把前端传的临时Tag对象丢到关联列表里。

内容的提问来源于stack exchange，提问作者Miss Sunshine