更新接口时前端少传了字段，后端该不该把它更新成空？

更新接口收到字段没传的请求时，后端不要默认把它更新成 NULL 或空字符串。按 2026 年的接口交付经验，先分清接口语义是整行覆盖还是部分修改：全量覆盖的接口，调用方要传回所有保留字段；部分更新接口，只处理传过来的字段。如果前端为了省流量只传改动项，后端却按整行覆盖，很容易把数据库已有旧值清掉。解决核心是把“空值是否写库”写进接口约定，并对可能并发修改的数据加版本号兜底。

先分清：这个接口是“整行覆盖”还是“部分修改”？

编辑保存的写接口，实际上有两种不同语义。一种是全量更新：调用方提交完整业务对象，后端用本次请求整体替换原有数据；另一种是部分更新：调用方只提交要改变的字段，后端只动这些字段，没传的保持原值。

很多联调事故，都出在“前端以为是部分更新，后端却做成了全量覆盖”。编辑页只改了备注，请求体却只带了备注，后端用 updateById 覆盖那行记录，其余字段就被重置。

• 全量更新（类似 PUT）：缺省字段通常会被写成空或默认值，适合字段少、一次提交整个表单的场景。
• 部分更新（类似 PATCH）：缺省字段保持不变，适合字段多、只改一两项、多人协作的场景。

联调第一句话要问清：这个接口能不能整行覆盖？

线上覆盖事故，多半是因为接口语义没定清楚

线上数据被覆盖，常见原因有三类：前端只提交页面绑定的字段导致隐藏字段丢失；后端把空字符串或 null 当成正常值直接写入；两个后台同时修改同一行，后提交的整行覆盖先提交的结果。

• 前端漏传非空字段，整行覆盖后被漏字段变成空值。
• 后端用空值判断是否更新，想清空的字段清不掉，不想清空的反而被覆盖。
• 并发编辑时，后保存的人一提交，前面保存的修改就被冲掉。

从 2026 年的交付经验看，这类空值与覆盖问题在接口联调返工原因中的占比，常见区间在一到三成，它不只是低级错误，很多时候是接口文档里没把更新语义写清楚。

三问判断法：决定没传的字段动不动

与其争论“漏传要不要更新”，不如用三个问题把场景定下来。

1. 第一问：这个写接口处理的是完整表单，还是局部操作？完整表单用全量更新；局部操作（改状态、改头像）用部分更新。
2. 第二问：字段缺失时，是表示不修改，还是表示要清空？缺失表示不修改时用 PATCH；缺失表示清空时，要要求调用方显式传空值。
3. 第三问：同一数据会被多人同时修改吗？只要可能并发，更新条件里就要带版本号或更新时间，否则很容易出现后写覆盖先写。

三问的顺序不能调换：第一问定接口语义，第二问定空值规则，第三问决定要不要加并发控制。通常第二问无解，是因为第一问没有先表态。

落地写法：让“没传”和“清空”不再混淆

代码上要做三件事：区分全量与局部接口、为允许清空的字段留显式入口、对并发更新做版本校验。

• 全量更新接口：后端要忽略创建人、创建时间这类主数据字段，不参与 update，避免一更新就把审计信息冲掉。
• 部分更新接口：如果用 MyBatis 这类框架，常见写法是“if test 字段非空判断”，它会挡住空字符串，导致允许清空的字段清不掉；清空要单独写 set 语句或增加清空标记。
• 凡是可能并发修改的写操作，都建议用 version 字段做乐观锁：update ... where id=? and version=?，影响行数为 0 就返回冲突。

在 2026 年交付过的一个后台项目里，资料编辑页有二十多个字段，最初用整表 updateById，上线后出现“改备注把审核状态重置”的情况。约束条件是没有数据库触发器、前端也不愿意为每个页面回传所有字段。我们改成把接口拆成基本信息和状态两个写接口，状态接口只收状态字段，并让前端带上 version。这个改造的代价是额外增加约 2 到 3 个工作日联调。

按这类“拆语义”改造的常见区间，额外周期通常在 2 到 5 个人日；虽然当时多花了两三天，但后续反复出现的覆盖返工基本消失了。

全量更新 vs 部分更新：怎么选

按实际业务形态选，而不是按技术习惯。可以从字段数量、并发频率、调用方类型三个维度快速判断。

• 字段少于 10 个、一次保存一个完整对象：优先全量更新，过程直接，联调通常也较快。
• 字段超过 20 个、或每次只改一两个字段：优先部分更新，既能避免每次传几十个字段，也降低漏传风险。
• 并发编辑频繁，比如多个运营同时维护一条配置：建议部分更新加版本号，全量更新很容易出现后写覆盖先写。
• 接口要给小程序、第三方等多端用：按 PATCH 语义设计，把“缺失与空值”的规则在接口文档里写清楚。

按多个项目的经验区间，字段数量在 10 到 20 个之间时，两种方案的联调成本接近；字段一旦超过 20 个，部分更新的长期维护成本更低，空值类返工大概能少三成。如果你的字段都在 10 个以下且不允许清空，全量更新仍然是稳妥选择，不必为了“规范”强行上更复杂的更新协议。

适用场景与边界

上述做法适合有编辑页的业务后台、带状态流转的管理系统，以及需要多端复用的接口。

边界也很明确：如果是一次性数据迁移脚本或定时任务，调用方每次都能拿到完整数据，直接整行覆盖风险不大，不需要拆成两个接口。

如果业务是一次更新要跨多张表并保持原子性，或者写的是大 JSON 内部的字段，更新策略要再叠加上事务边界和 JSON 粒度控制，不能用单纯的全量/部分更新一概而论。

常见问题

更新接口没传字段时，后端会把它置空吗？

取决于接口语义。全量更新会覆盖为缺失值，部分更新只会改动传来的字段；不确定时先查接口文档是如何约定的。

PUT 和 PATCH 有什么区别？

简单说，PUT 是提交完整状态，没传字段通常视为清空或重置；PATCH 是提交修改说明，没传字段保持原值。两者适用的数据安全级别不同。

前端传空字符串想清空地址，后端却不更新怎么办？

空字符串和 null 要分别处理。后端代码不能只在字段非 null 时更新，建议为允许清空的字段单独设清空入口或清空标记。

多人同时编辑一行数据，字段被覆盖怎么办？

用版本号或更新时间做乐观锁。更新时带上前端保存的 version，影响行数为 0 就提示对方重新加载，别让后提交的直接覆盖。

所有写接口都改成部分更新，是不是更安全？

不一定。部分更新对“缺失=不更新”的语义要求更细；如果前端习惯整单提交，强行改成部分更新反而增加漏更新风险，按场景选择更稳。

落地时可以先花一两个小时，把当前系统的写接口在文档里标一遍：是全量覆盖、部分更新还是不允许更新；每个写接口都注明缺省字段和空值是否写库。这个动作对避免返工很划算。

适用边界也很直接：字段少、数据一次性由内部脚本写全时，整行覆盖没问题；多端共用、多人维护的写接口，务必先标清更新语义，再加版本控制兜底。