如何在服务中分离演示与生产代码？证书服务场景最佳实践咨询

针对你用DI管理证书服务、区分生产/演示环境的场景，分享几个落地性强的最佳实践：

1. 用框架原生环境API替代硬编码判断 #

别直接读取环境变量做判断，ASP.NET Core自带的IWebHostEnvironment提供了标准化的环境检测方法，代码更简洁且符合框架规范：

public void ConfigureServices(IServiceCollection services)
{
    services.AddSingleton<ICertService>(sp =>
    {
        var env = sp.GetRequiredService<IWebHostEnvironment>();
        return env.IsProduction() 
            ? new CertService(sp.GetRequiredService<IConfiguration>()) 
            : new CertServiceDemo(sp.GetRequiredService<IConfiguration>());
    });
}

如果需要单独的Demo环境，还可以自定义环境判断：

if (env.IsEnvironment("Demo"))
{
    return new CertServiceDemo(...);
}

2. 配置驱动注入（最推荐） #

把证书服务的实现类全名放到对应环境的配置文件里，彻底解耦代码和环境逻辑，不用改代码就能切换服务：

• 生产环境配置（appsettings.Production.json）：

{
  "CertService": "YourApp.Services.CertService, YourApp"
}

• 演示/开发环境配置（appsettings.Development.json）：

{
  "CertService": "YourApp.Services.CertServiceDemo, YourApp"
}

然后在Startup中通过反射加载注入：

public void ConfigureServices(IServiceCollection services)
{
    var serviceType = Type.GetType(Configuration["CertService"]);
    services.AddSingleton(typeof(ICertService), serviceType);
}

3. 隔离演示代码，避免污染生产包 #

• 把CertServiceDemo放到单独的类库项目（比如YourApp.DemoServices），生产环境打包时不引用这个项目，既减小包体积，也防止演示代码意外进入生产环境。
• 用条件编译控制演示代码的编译：给Demo项目添加DEMO编译符号，生产项目不添加，这样演示代码只会在指定环境被编译：

#if DEMO
public class CertServiceDemo : ICertService
{
    // 本地加载证书的逻辑
}
#endif

4. 单例注入的细节注意 #

• 确保两个服务类的初始化逻辑线程安全，比如CertService从Azure Key Vault拉取证书时，要避免并发请求重复拉取。
• 如果证书需要动态更新（比如Key Vault证书轮换），别让单例直接缓存证书，而是在服务类内部实现缓存刷新逻辑，或者用框架的缓存机制处理。

总结 #

简单场景用框架原生环境判断足够灵活；复杂多环境场景优先选配置驱动注入，符合开闭原则；同时一定要做好演示代码的隔离，避免生产环境冗余。

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