如何在不丢失字段原有信息的前提下移除字段存储内容？

你现在用空格、连字符绕问题的思路本质是用特殊业务值硬编码操作语义，既不通用也容易留隐患，标准实现可以按下面的逻辑调整：

空格方案失效的根因 #

空格不生效基本是两个环节出了问题：

• 前后端提交链路默认做了字符串trim处理，你输入的空格被自动过滤成了空串，后续持久层框架又把空串自动转换为Null存储，根本没有把你输入的空格落到变更记录里
• 你的现有查询逻辑默认把空串、全空格内容判定为「无有效字段值」，直接跳过了这条记录，最终拉取到了更早的历史值

推荐的合规级实现方案 #

针对审计溯源的场景，绝对不要用空格、连字符这类可见字符作为操作标记——这类字符本身就可能是合法业务值（比如外籍客户姓名带空格、备注字段填连字符），迟早会出现业务判断错误。正确的设计是把「字段操作」和「字段值」拆开存储：
给每个字段的变更记录增加独立的操作类型枚举，只需要三类就能覆盖全场景：

• SET：正常赋值操作，对应存储用户输入的具体字段值，查询时直接取该值作为当前字段值即可
• CLEAR：明确清空字段操作，这个操作本身就是独立语义，不需要额外存特殊占位值，查询到最近一次对目标字段的操作是CLEAR时，直接返回空值即可
• IGNORE：本次更新未修改该字段，查询遍历变更记录时直接跳过带这个标记的字段，不要把它当作有效变更
  这种设计完全满足审计合规要求：你可以清晰区分「用户从来没改过这个字段」「用户把字段设成了某个值」「用户主动清空了字段」三类完全不同的操作，不会出现语义混淆。

无法调整表结构时的临时兼容方案 #

如果短期没法给变更表加操作类型字段，不要硬塞特殊字符当标记，可以在更新接口里给每个可清空字段加独立的布尔类型清空标识，比如提交更新时传clear_company: true这类参数，后端识别到标识后，在变更记录里单独标记该字段本次的动作为清空，查询时优先识别这个标记即可，不会和正常业务值冲突。

现有查询逻辑的必改点 #

你现在的「定位最近一次修改指定字段的更新记录」逻辑，必须把「清空操作」判定为有效修改，不要只筛选“存了非空值”的记录，否则不管你用什么标记方案，都会跳过清空操作的记录，永远拉到清空之前的旧值。

额外提醒：不要直接用Null代表清空操作，绝大多数场景下Null的语义是「本次更新没有涉及该字段」，和「主动清空字段」的审计语义完全不同，混存会直接导致溯源结果出错，不符合合规要求。

内容的提问来源于stack exchange，提问作者William Walker III