保存接口对 id 标了 @NotNull，新增时传 null 正常，修改时传 null 也返回 200，最后更新了 id 为 null 的记录，影响行数是 0 却提示成功。乍看像缓存或者权限的锅，追下去往往不是。
curl -i -X PUT http://127.0.0.1:8080/api/users \ -H 'Content-Type: application/json' \ -d @user_no_id.json
追下去是这么回事：两个场景共用同一个 DTO，校验分组没有区分，修改接口没有启用对应的分组。@Validated 不带分组时只走 Default 分组，标了 groups 的约束会被跳过。接口返回成功是因为 update 影响 0 行也算执行完成。
「分组校验失效」这个问题文档写得含糊，实际行为以当前版本为准，别照旧版本的结论套。一次只改一处，改完立刻验证，几个改动叠在一起，出问题就说不清是谁导致的。
先做最小复现，能稳定跑出来的问题，排查成本会低一个数量级。别只看报错的最后一行，往上看几行，真正的起因通常在上面。
具体做法是，定义 Create 和 Update 两个分组接口 把 id 的约束放到 Update 组；修改接口参数改成 @Validated(Update.class)；service 里判断 update 影响行数为 0 时抛记录不存在；用不带 id 的修改请求回归一次。
验收就看一点，不带 id 的修改请求返回 400 提示 id 不能为空 不再出现假成功。