MVC Core项目模型属性验证：是否应采用客户端验证并移除服务端属性？

1. 是否应该针对模型属性开展客户端验证？ #

完全应该，而且这是ASP.NET Core MVC推荐的高效做法！你提到的[Required]、[StringLength]、[DisplayName]这类模型属性，框架会自动帮你转换为客户端验证所需的HTML属性（比如data-val-required、data-val-length-min这类标识），配合jquery.validate.unobtrusive脚本就能自动实现客户端验证——根本不需要你手动把属性转成JavaScript或JSON，框架已经帮你完成了这部分繁琐的工作。

举个简单的实操例子：

public class UserFormModel
{
    [Required(ErrorMessage = "用户名不能为空")]
    [StringLength(20, MinimumLength = 3, ErrorMessage = "用户名长度需在3-20位之间")]
    [DisplayName("用户名")]
    public string Username { get; set; }
}

在Razor视图里用Tag Helper渲染输入框：

<input asp-for="Username" class="form-control" />
<span asp-validation-for="Username" class="text-danger"></span>

渲染后的HTML会自动带上验证相关的属性，客户端脚本会实时校验用户输入，不符合规则时立刻给出提示，用户体验非常流畅。

2. 采用HTML/JS客户端验证后，能不能移除模型中的属性？ #

绝对不行！ 客户端验证只是优化用户体验的手段，它完全可以被绕过——比如用户禁用浏览器JavaScript，或者直接用工具构造HTTP请求发送到后端。这时候服务端验证就是最后一道安全防线，而模型属性正是服务端验证的核心依据：你在Action里通过ModelState.IsValid判断验证结果，就是基于这些模型属性定义的规则。

哪怕你自己手动写了纯JS的客户端验证逻辑，也必须保留模型属性来做服务端校验，否则你的后端会直接接收非法数据，带来严重的安全风险和数据一致性问题。

3. 服务端与客户端验证的分工 #

你对两者的定位理解非常准确：

• 客户端验证：优先处理无需访问服务器的规则（比如必填、长度范围、邮箱格式校验），目的是快速给用户反馈，减少不必要的服务器请求，提升交互流畅度。
• 服务端验证：是必须保留的核心验证层，一方面处理客户端无法完成的逻辑（比如检查用户名是否已存在、验证用户权限、关联数据库的复杂校验），另一方面作为安全兜底，防止任何绕过客户端验证的恶意请求。

总结 #

模型属性是连接客户端验证与服务端验证的桥梁，千万别移除它们——利用框架自带的模型驱动验证，既能轻松实现客户端验证，又能保证服务端验证的完整性。两者配合使用，才能同时兼顾用户体验和系统安全性。

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