如何实现购物车删除验证，避免前端篡改data属性后删除错误商品

常见实现方案 #

• 服务端索引绑定校验
  用户登录后，购物车所有条目会在服务端生成与当前账号/会话绑定的固定有序列表。前端提交删除请求时，除了按钮data-属性携带的商品ID外，还会自动携带该条目在购物车列表中的位置索引。服务端收到请求后会优先校验「提交的商品ID」与「对应索引位置绑定的服务端存储商品ID」是否一致，不一致时直接以服务端存储的索引对应商品为准执行操作，或直接拒绝非法请求。
• 操作签名校验
  页面加载时，服务端会为每个购物车条目的删除操作下发唯一签名，该签名由「商品ID+条目索引+用户ID+服务端私有盐」加密生成，无法通过前端修改伪造。你仅修改data-属性的商品ID后，请求携带的签名与修改后的ID无法匹配，服务端会直接拉取该索引位置对应的真实商品ID执行操作，或返回请求非法。
• 前端缓存原始值不依赖DOM属性
  现在主流前端框架（React/Vue等）开发的页面，删除按钮的点击事件在列表渲染时就已经通过闭包/组件props缓存了对应条目的原始商品ID，点击触发请求时根本不会读取DOM上的data-属性值。哪怕你修改了DOM上的属性，也不会影响已经绑定好的事件回调里的缓存值，请求依然会携带原始的正确ID。
  部分用原生JS开发的页面会采用事件委托实现，点击按钮时会读取同一条目下隐藏<input>标签存储的商品ID，你仅修改删除按钮的data-属性，不会影响隐藏标签的内容，自然也不会生效。
• 购物车快照校验
  进入购物车页面时，服务端会为当前用户的购物车生成一个唯一快照版本号，所有操作请求都需要携带该版本号。服务端收到删除请求后，会对比对应版本快照里该索引位置的商品信息，与提交的ID不一致时直接以快照内容为准。

学习参考方向 #

你可以从以下几个方向深入学习相关内容：

• 后端服务的会话管理、状态一致性校验设计
• 前端闭包作用域、事件绑定、框架渲染逻辑相关知识
• 电商业务系统的幂等性、数据防篡改、数据一致性设计方案

内容的提问来源于stack exchange，提问作者Kasun Jalitha