ASP.NET Core控制器参数添加自定义验证的惯用实现方式

两种实现方式都可行，优先选择声明式特性标注的方案，更符合ASP.NET Core的框架设计惯例，可维护性更好。

方案1：使用验证特性实现（推荐） #

你不需要自己在控制器里写冗余的判断逻辑，直接利用框架自带的验证管道即可：

简单场景直接用内置特性 #

如果规则固定不会频繁调整，直接用内置的RegularExpressionAttribute标注在参数上即可：

[HttpPost("{text}")]
public ActionResult PostSomething(
    [RegularExpression("^a|b|c$", ErrorMessage = "text参数仅允许取值为a、b、c")] 
    string text)
{
    // 执行到此处时参数已经通过校验，直接编写业务逻辑即可
    return Ok();
}

默认开启的[ApiController]特性会自动触发参数校验，校验失败时会自动返回标准400 Bad Request响应，不需要你手动处理错误返回。

复用场景自定义专属特性 #

如果这个校验规则需要在多个接口复用，或者想要更语义化的写法，可以自定义验证特性：

/// <summary>
/// 限制参数仅允许传入a、b、c
/// </summary>
public class ValidTextAttribute : ValidationAttribute
{
    private static readonly HashSet<string> AllowedValues = new() { "a", "b", "c" };
    public override bool IsValid(object? value)
    {
        return value is string input && AllowedValues.Contains(input);
    }
}

使用时直接标注在参数上即可：

[HttpPost("{text}")]
public ActionResult PostSomething([ValidText(ErrorMessage = "参数非法")] string text)
{
    // 业务逻辑
}

这种方式的优势：

• 校验逻辑和业务逻辑完全解耦，控制器代码更简洁
• 校验逻辑可跨接口复用，后续要修改允许值只需要改特性一处代码
• 自动适配框架的统一验证响应，不需要重复写错误返回逻辑

方案2：控制器内写if判断 #

这种方式仅适合校验规则和当前接口业务强绑定、无复用需求，且需要自定义校验失败的特殊响应格式的场景，示例代码：

[HttpPost("{text}")]
public ActionResult PostSomething(string text)
{
    if (!new HashSet<string>{"a","b","c"}.Contains(text))
    {
        // 可以自定义任意返回结构、错误码
        return BadRequest(new { Code = 40001, Message = "text仅支持传入a、b、c三个值" });
    }
    // 业务逻辑
    return Ok();
}

最佳实践选择 #

• 无特殊响应定制需求、规则可能复用时，优先选特性标注方案
• 仅单接口使用、且需要完全自定义错误返回时，再选择方法内写if判断的方式

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