ASP.NET Core Web API中JSON结合[Bind]特性的使用问题

首先直接给结论：[Bind]特性确实不支持JSON请求体，这是官方的有意设计，而非未开发的功能。下面我来详细解释原因，并给出几种限制属性提交的正确方式。

为什么[Bind]不支持JSON？ #

ASP.NET Core里的模型绑定和JSON序列化是两个完全独立的机制：

• [Bind]特性是针对**表单数据（x-www-form-urlencoded、multipart/form-data）**的模型绑定流程设计的，它的作用是在键值对形式的表单数据中过滤出允许绑定的属性。
• 而JSON请求体是通过InputFormatter（比如SystemTextJsonInputFormatter）来处理的，本质是序列化/反序列化过程，依赖的是JSON序列化库（System.Text.Json或Newtonsoft.Json）自身的规则，[Bind]的逻辑不会介入这个过程。

官方之所以这样设计，是因为JSON的序列化控制已经有成熟的方案，而且用DTO（数据传输对象）来做请求/响应的契约，是Web API设计的最佳实践，比[Bind]更清晰、更安全。

限制JSON请求属性提交的正确方式 #

1. 使用DTO（最推荐） #

创建一个专门的数据传输对象，只包含允许客户端提交的属性，API Action直接接收这个DTO作为参数，再映射到你的业务模型。这种方式从根源上避免了不必要的属性被提交，同时也让API的契约更明确。

示例代码：

// 你的业务模型（包含所有属性）
public class User
{
    public int Id { get; set; }
    public string Username { get; set; }
    public string Password { get; set; }
    public DateTime CreatedAt { get; set; }
}

// 用于创建用户的DTO（只允许提交Username）
public class CreateUserRequest
{
    public string Username { get; set; }
}

// API Action
[HttpPost("users")]
public IActionResult CreateUser([FromBody] CreateUserRequest request)
{
    if (!ModelState.IsValid)
        return BadRequest(ModelState);

    // 把DTO映射到业务模型（可以手动映射或用AutoMapper）
    var user = new User
    {
        Username = request.Username,
        CreatedAt = DateTime.UtcNow
        // Password可以后续通过其他逻辑设置，比如生成默认密码
    };

    // 保存到数据库等逻辑...
    return Ok(user);
}

2. 使用JSON序列化特性控制 #

如果不想额外创建DTO，可以直接在业务模型的属性上使用JSON序列化库的特性，来控制哪些属性可以被反序列化：

• 对于System.Text.Json，使用[JsonIgnore]标记不允许提交的属性（反序列化时会忽略该属性，客户端传了也不会被赋值）。
• 如果你用的是Newtonsoft.Json，用[JsonIgnore]或[JsonProperty(DefaultValueHandling = DefaultValueHandling.Ignore)]。

示例：

public class User
{
    // 禁止客户端提交Id，设为只读也可以达到类似效果
    public int Id { get; }

    public string Username { get; set; }

    // 反序列化时忽略，客户端无法通过JSON提交该属性
    [JsonIgnore]
    public string Password { get; set; }

    [JsonIgnore]
    public DateTime CreatedAt { get; set; }
}

⚠️ 注意：这种方式会影响属性的序列化输出（比如返回用户数据时，Password和CreatedAt也会被忽略），如果你的API需要返回这些属性，这种方式就不太适合，还是DTO更灵活。

3. 自定义Action过滤器（备选方案） #

如果以上两种方式都不适合，你可以自定义一个Action过滤器，在模型绑定完成后检查提交的属性，禁止不允许的属性被赋值。这种方式比较繁琐，性能也不如前两种，只建议在特殊场景下使用。

示例代码：

public class AllowedPropertiesAttribute : ActionFilterAttribute
{
    private readonly string[] _allowedNames;

    public AllowedPropertiesAttribute(params string[] allowedNames)
    {
        _allowedNames = allowedNames;
    }

    public override void OnActionExecuting(ActionExecutingContext context)
    {
        foreach (var (key, value) in context.ActionArguments)
        {
            if (value == null) continue;

            var type = value.GetType();
            var properties = type.GetProperties(BindingFlags.Public | BindingFlags.Instance)
                .Where(p => p.CanWrite && !_allowedNames.Contains(p.Name));

            foreach (var prop in properties)
            {
                var propValue = prop.GetValue(value);
                if (propValue != null && !Equals(propValue, Activator.CreateInstance(prop.PropertyType)))
                {
                    context.ModelState.AddModelError(prop.Name, $"属性 {prop.Name} 不允许被提交");
                }
            }
        }

        if (!context.ModelState.IsValid)
        {
            context.Result = new BadRequestObjectResult(context.ModelState);
        }
    }
}

使用方式：

[HttpPost("users")]
[AllowedProperties("Username")] // 只允许提交Username属性
public IActionResult CreateUser([FromBody] User user)
{
    // 业务逻辑...
}

总结 #

• [Bind]不支持JSON是有意设计，因为JSON的处理机制和表单数据完全不同。
• 优先使用DTO，这是Web API设计的最佳实践，既安全又清晰。
• 若不想用DTO，可以用JSON序列化特性，但要注意对输出的影响。
• 过滤器作为最后的备选方案，仅在特殊场景下使用。

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