.NET(C#)调试模式下禁用邮件发送：用#if DEBUG还是依赖注入？

一、预处理指令#if DEBUG的可行性分析 #

这种方式可行，但存在明显局限性：

• 优点：实现简单，编译阶段就会剔除调试模式下的邮件发送代码，没有运行时性能开销
• 缺点：
  • 硬编码逻辑，无法灵活适配多环境（比如想在测试环境禁用邮件就需要修改代码重新编译）
  • 业务逻辑与环境判断耦合，代码侵入性强
  • 多处邮件发送逻辑需要重复编写条件判断，维护成本高

二、依赖注入+接口抽象：行业标准做法 #

这是当前.NET生态中更推荐的通用方案，核心思路是通过抽象解耦业务逻辑与邮件发送实现，根据环境动态切换具体行为：

1. 定义邮件发送接口 #

public interface IEmailSender
{
    void SendEmail(EmailModel email);
}

2. 实现生产环境的真实发送类 #

public class RealEmailSender : IEmailSender
{
    private readonly MailHelper _mailHelper;

    public RealEmailSender(MailHelper mailHelper)
    {
        _mailHelper = mailHelper;
    }

    public void SendEmail(EmailModel email)
    {
        _mailHelper.sendEmail(email);
    }
}

3. 实现调试/测试环境的空实现（或模拟类） #

public class NullEmailSender : IEmailSender
{
    public void SendEmail(EmailModel email)
    {
        // 仅记录调试日志，不实际发送邮件
        System.Diagnostics.Debug.WriteLine($"模拟发送邮件：主题={email.Subject}，收件人={email.To}");
    }
}

4. 根据环境配置注入对应实现 #

在.NET 6+的Program.cs或传统.NET Core的Startup.cs中配置依赖注入：

var builder = WebApplication.CreateBuilder(args);

// 根据当前环境注入不同实现
if (builder.Environment.IsDevelopment())
{
    builder.Services.AddScoped<IEmailSender, NullEmailSender>();
}
else
{
    builder.Services.AddScoped<IEmailSender, RealEmailSender>();
}

5. 业务代码依赖接口而非具体实现 #

public class OrderService
{
    private readonly IEmailSender _emailSender;

    // 通过构造函数注入接口
    public OrderService(IEmailSender emailSender)
    {
        _emailSender = emailSender;
    }

    public void ProcessOrder(Order order)
    {
        // 业务逻辑处理...

        // 发送邮件，无需手动判断环境
        var email = new EmailModel
        {
            Subject = $"订单确认：{order.OrderId}",
            To = order.CustomerEmail,
            Content = $"您的订单已成功处理，订单号：{order.OrderId}"
        };
        _emailSender.SendEmail(email);
    }
}

三、方案对比与总结 #

• 预处理指令：适合快速临时解决简单场景，但扩展性和可维护性差
• 接口注入方案：遵循依赖倒置原则，解耦业务与实现，可灵活适配多环境，同时便于单元测试，是行业标准的最佳实践

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