TableClient.UpdateEntity为何单独设置ETag入参（ETag已在ITableEntity中）

这个设计本质是SDK 从API层面主动规避乐观并发控制的常见误用坑，同时适配更多灵活的使用场景，核心原因有三个：

• 强制开发者显式确认并发策略
  如果UpdateEntity默认直接读取实体上自带的ETag属性做校验，绝大多数开发者写代码时根本注意不到这个隐式逻辑：不少人图省事会直接new一个同分区键、行键的实体，只填了要更新的字段就调用更新方法，这时候实体上的ETag是默认空值，会直接跳过并发校验，悄无声息覆盖掉其他客户端的并行更新结果，这类并发冲突问题排查成本极高。
  把ETag拆成独立必填入参后，调用时必须明确传值：要么传查询实体时拿到的原始ETag走正常乐观并发校验，要么显式传ETag.Any声明要无条件覆盖，不管是写代码的人还是后续读代码的人，一眼就能看明白当前更新逻辑的并发策略，不存在藏着掖着的默认行为。
• 适配ETag与实体分离的业务场景
  不是所有更新场景下，用来传参的实体对象都带着正确的ETag：比如做Web接口时，ETag经常是放在请求头里和业务参数分开传输的，这时候不需要特意把ETag赋值回实体对象，直接把从请求头解析到的ETag传入方法就行，省了多余的对象赋值步骤。
  另外如果遇到需要对同一个实体实例执行不同并发策略的操作、或者实体经过多层对象映射/转换容易丢失ETag字段的场景，独立传参可以避免反复修改实体对象的状态，也不会因为映射过程丢字段导致并发校验意外失效。
• 规避实体状态污染导致的非预期bug
  很多开发者会复用实体对象做多次操作，如果直接依赖实体上的ETag属性，一旦某段逻辑不小心修改了实体上的ETag值，后续所有更新操作的并发校验逻辑都会出问题，这类因为对象状态被篡改导致的bug调试起来非常麻烦。独立传参相当于把并发控制的凭据和实体本身的业务状态解耦，你可以在查询到实体时就把ETag单独存为局部变量，不管后续实体对象怎么修改、怎么传递，最终更新时用最开始存的原始ETag即可，不会被中间的对象操作影响。

补充：如果你觉得每次单独传ETag麻烦，完全可以在查询拿到实体后，直接把实体上的ETag属性当参数传入UpdateEntity方法，效果和SDK隐式读取实体ETag完全一致，只是SDK把选择权完全交给了调用方，没有替你做默认决策。

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