跨多个独立NuGet包共享自定义异常的实现方案咨询

你提到的抽取MyPackage.Common公共共享包的方案并不是唯一实现方式，这是目前行业内最常用、维护成本最低的主流方案，适合绝大多数场景，除此之外还有以下几种可行方案：

• 源码NuGet包共享
  将自定义异常的代码打包为源码形式的NuGet包，5个业务包安装该源码包后，代码会直接注入到对应项目的编译流程中，最终每个业务包的程序集内都会包含完全相同的异常类代码，无需额外引入第三方程序集依赖。注意需要配套使用[assembly: TypeForwardedTo]特性做向前兼容，避免后续切换到公共程序集方案时出现类型不匹配的问题。
• 接口抽象+各包独立实现
  如果不想让5个业务包引入额外的公共依赖，可以先定义一套公开的HTTP异常统一接口（例如包含StatusCode、RequestId、ErrorMessage等统一属性的IHttpException接口），每个业务包内部独立实现该接口的自定义异常类。上层处理逻辑捕获异常时，仅需要判断异常是否实现了该统一接口即可完成统一处理，不需要感知具体的异常类型。该方案的缺点是无法直接按异常类型做catch筛选，需要先捕获通用Exception再做接口实现判断。
• .NET 8+ 静态接口默认实现优化
  如果所有业务包都面向.NET 8及以上版本，可以给统一异常接口添加静态抽象成员和默认实现，大幅减少各包独立实现时的重复代码量，降低该方案的维护成本。
• 强名称程序集+GAC部署
  如果是内部可控环境使用的项目，可以将公共异常类编译为强名称程序集，部署到目标运行环境的GAC（全局程序集缓存）中，5个业务包统一引用该强名称程序集即可，不需要将公共包打包进各自的NuGet分发包中。该方案适用场景非常窄，仅适合完全可控的内部部署环境，不适合公开发布的NuGet包。

选型参考：公开发布的NuGet包优先选择公共共享包方案，类型一致性最好、后期维护成本最低；如果不想让用户安装额外的依赖包，可以选择源码包方案；仅内部使用且上层统一做接口维度的异常处理时，可选接口抽象的方案。

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