为何context.go同时定义并实现Context接口，突破Go接口定义惯例？

Go官方代码评审指南里提到的「接口归属于使用方包」是通用实践，核心目的是避免实现侧随意定义、修改接口导致所有使用方被迫重构，同时也避免实现包定义无实际使用者的冗余接口。当同时满足以下几个判定标准时，可以参考context包的设计，将接口与实现放在同一个包中：

• 接口是当前包对外暴露的核心契约，整个包的设计逻辑完全围绕该接口展开。context包的所有能力、导出函数（如WithCancel、WithValue）都是为Context接口服务的，接口本身就是包的核心价值，而非实现侧给使用方预留的扩展点。
• 包需要完全控制接口的实现权，不期望外部用户自定义实现该接口。context包的所有实现类（emptyCtx、cancelCtx等）都是包内私有类型，对外仅返回Context接口实例，用户无法也不需要自行实现Context，后续即便需要给接口新增方法，只需在包内修改所有私有实现即可，不会影响外部用户，完全符合指南中「避免大规模重构」的核心要求。
• 接口的语义高度稳定，几乎不会发生变更。作为包的核心对外契约，这类接口的方法签名、语义在设计阶段就已经过充分验证，上线后不会随意调整，不存在频繁修改接口拖累使用方的问题。
• 用户使用包时仅需要依赖接口的公开方法，不需要感知任何实现细节。这类设计反而符合最小暴露原则，用户无需关心底层实现差异，只要依赖接口定义的能力即可。

这种设计完全不违背代码评审指南的初衷，只是通用规则在「包核心抽象」场景下的合理适配。

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