在有效邮箱非Null的系统中，将GetCustomerIdByEMail参数设为string?是否为不良实践？

已知Null并非有效电子邮箱，这种参数设计算不算不良实践，其实没有绝对的标准答案，核心取决于团队的编码规范、业务场景需求以及对代码契约清晰度的重视程度，下面从几个关键维度拆解分析：

1. 契约清晰度：矛盾的业务暗示 #

把参数设为string?，相当于对外传递了一个信号：这个方法接受Null作为合法输入。但业务规则明确Null不是有效邮箱，这就形成了契约和业务逻辑的矛盾。其他开发者看到这个方法签名时，可能会误以为Null是一个需要被处理的合法场景，甚至在不必要的地方传入Null，反而增加了认知负担和潜在的错误风险。

如果将参数设为string（非可空），则能在编译阶段就明确约束：调用者必须传入一个有效的、非Null的邮箱地址，完全贴合业务规则，从源头避免了无效的Null输入。

2. 调用者便捷性：便利与规范的权衡 #

你提到的“让调用者少写Null判断”确实是一个实际的便利点，但这种便利是以模糊契约为代价的。如果团队普遍倾向于“底层方法消化无效输入，减少调用者负担”的风格，这种写法有一定合理性；但如果团队更重视代码契约的明确性，那这种“替调用者处理无效输入”的逻辑就显得多余，甚至会让方法职责变得不纯粹。

如果想兼顾便捷性和契约清晰，可以考虑提供方法重载：

// 核心方法：明确要求传入有效非Null邮箱
public int? GetCustomerIdByEMail(string email)
{
    return DB.Query<Customer>().Where(c => c.EMail == email).Select(c => c.Id).SingleOrDefault();
}

// 兼容方法：处理Null输入，内部调用核心方法
public int? GetCustomerIdByEMail(string? email)
{
    return email == null ? null : GetCustomerIdByEMail(email);
}

这种方式既满足了调用者的便捷需求，又通过重载明确了“非Null是合法输入，Null是兼容场景”的契约。

3. 方法职责单一性：避免冗余逻辑 #

原方法内部的Null判断，本质上是在承担“校验输入有效性”的额外职责。一个设计良好的方法应该只专注于核心功能——根据有效邮箱查询客户ID，而输入的有效性校验，更适合由调用者来负责（或者通过专门的校验逻辑处理）。保持职责单一，能让代码更易维护、更易理解。

4. 团队空值处理策略：适配团队规范 #

不同团队有不同的空值处理哲学：

• 若团队采用防御式编程，习惯在所有方法中处理Null输入，那这种写法可以接受；
• 若团队采用契约式编程，依赖调用者保证输入有效性，并通过C#的可空引用类型（Nullable Reference Types）在编译阶段拦截Null，那将参数设为string?就不符合规范。

总结 #

是否属于不良实践，关键看团队的编码共识。但从契约清晰性、方法职责单一性的角度，更推荐将参数设为string，让调用者负责传入有效非Null的邮箱；或者通过重载的方式，同时兼顾便捷性和规范要求。

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