为何不建议在传统非API MVC控制器中使用特性路由？

首先你不需要给返回视图的MVC控制器标记[ApiController]就能用特性路由——特性路由从ASP.NET MVC 5、ASP.NET Core 1.0版本开始就原生支持普通MVC控制器，和传统路由表方案是并行支持的路由能力，本身不存在「不适合MVC视图场景」的问题。你之前测试时加[ApiController]才是所有兼容性问题的根源，这个特性是专门为REST API场景设计的，自带的一整套约定都和面向用户的HTML页面场景不匹配，除了你已经发现的默认强制禁用HTTP缓存之外，还有以下几个明确的问题：

• 自动模型验证逻辑打断表单流程
  [ApiController]默认开启自动模型校验，只要入参的DataAnnotations校验不通过，会直接返回400 Bad Request的结构化ProblemDetails响应，根本不会进入Action内部的逻辑。但MVC表单场景下，校验失败的标准处理逻辑是返回带错误提示的表单页，引导用户修正输入，这个默认行为会直接让所有表单提交的错误处理失效，除非你全局关闭这个自动响应配置，后续新增Action很容易踩坑。

• 默认参数绑定规则不匹配表单提交
  [ApiController]对未标记绑定来源的复杂类型参数，默认采用[FromBody]绑定，也就是从请求体读取JSON格式数据。但普通MVC表单提交默认是application/x-www-form-urlencoded或者multipart/form-data编码，需要用[FromForm]从表单字段绑定数据，如果你忘了给每个复杂参数手动指定绑定来源，会直接出现参数绑定为null、表单提交数据全部丢失的问题，排查成本很高。

• 错误响应格式不符合页面访问预期
  [ApiController]默认会将所有错误状态码、未处理异常统一转换为JSON格式的ProblemDetails响应。但面向公众的MVC站点通常会配置对应状态码的友好HTML错误页（比如404提示页、500异常页），如果用带[ApiController]的控制器返回视图，用户访问出错时会直接看到一段JSON文本，而不是预期的友好错误页面。

• 存在跨站请求伪造(CSRF)安全隐患
  API控制器默认不会自动验证防伪请求令牌（因为API通常采用JWT、API Key等身份凭证，不依赖Cookie认证），但面向公众的MVC站点如果用Cookie做登录态，所有POST表单提交必须开启防伪令牌校验，否则会存在CSRF攻击风险。使用[ApiController]时你需要手动给所有表单Action加[ValidateAntiForgeryToken]，很容易因为遗漏配置留下安全漏洞。

• 内容协商逻辑会导致HTML响应异常
  [ApiController]默认开启内容协商机制，会根据请求头里的Accept字段选择响应格式，如果请求头携带Accept: application/json，原本应该返回HTML视图的接口会直接把页面对应的模型序列化成JSON返回，导致页面加载异常。

如果你只是想在MVC项目里用特性路由，直接去掉控制器上的[ApiController]标记即可，普通MVC控制器直接使用[Route]、[HttpGet]等特性标记路由的体验和API控制器完全一致，不会出现上面说的任何兼容性问题。

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