嵌入grpc.ClientStream的Go结构体为何显式实现已继承的CloseSend方法

显式实现CloseSend方法的常见原因如下： #

• 提升代码可读性，降低维护成本
  当结构体嵌入多个字段/接口时，继承的方法不会直接体现在当前结构体的方法定义列表中，其他开发者阅读代码时需要逐层查看嵌入的成员才能梳理清所有对外暴露的方法。显式声明CloseSend可以让开发者一眼就明确该结构体支持该方法，不用额外溯源嵌入的grpc.ClientStream接口定义。
• 预留扩展能力，保证后续迭代的兼容性
  目前的实现虽然只是透传调用底层的ClientStream.CloseSend()，但后续如果需要在关闭发送流的逻辑中新增额外操作（比如添加超时控制、埋点监控、日志打印、资源回收、错误统一处理等），直接修改这个显式实现的方法即可，完全不需要改动上层调用方的代码，也不会破坏现有接口的兼容性。尤其是该结构体本身已经定义了收发超时字段，后续大概率会扩展相关逻辑，提前声明方法可以降低后续改造的成本。
• 规避嵌入字段为空的隐含风险
  如果后续代码逻辑中出现contextableStream实例的ClientStream嵌入字段未初始化（为nil）的情况，直接调用隐式继承的CloseSend会直接触发panic。显式实现方法后可以很方便地新增判空兜底逻辑，哪怕当前版本没有加，也相当于给开发者提了个醒，要注意嵌入字段的初始化校验。
• 优化API文档展示效果
  Go官方的文档生成工具会优先展示结构体显式声明的方法，嵌入接口继承的方法通常会归类到嵌入字段的文档分区中，不会直接展示在当前结构体的方法列表里。显式实现可以让API文档更清晰，使用者不需要跳转查看grpc.ClientStream的文档就能明确该结构体的能力边界。
• 提前感知接口变更风险
  如果后续grpc.ClientStream接口的CloseSend方法签名发生调整，或者该方法被从接口中移除，显式声明的实现会在编译阶段直接报错，提前感知依赖变更带来的兼容性问题，而隐式继承的方法只会在实际调用的时候才会暴露问题，排查成本更高。

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