本文详解 asp.net mvc 中通过 ajax 调用 post 接口时传递防伪令牌（antiforgerytoken）的两种标准方式：以表单字段形式提交或通过自定义请求头传递，并指出常见错误及修复方案。
在 ASP.NET MVC 应用中，[ValidateAntiForgeryToken] 特性用于防止跨站请求伪造（CSRF）攻击。它要求每个受保护的 POST 请求必须携带一个名为 __RequestVerificationToken 的有效令牌。该令牌通常由 @Html.AntiForgeryToken() 生成并嵌入页面 HTML 中（如 ）。然而，当使用 jQuery AJAX 发起请求时，开发者容易误将令牌放入请求头（headers）而非请求体（data），或错误设置 contentType: 'application/json'，导致服务端无法解析令牌，最终抛出 “The required anti-forgery form field '__RequestVerificationToken' is not present” 错误。
✅ 正确做法一：作为表单字段提交（推荐）
这是最兼容、最稳妥的方式，适用于默认的 application/x-www-form-urlencoded 编码格式：
$('#confirmActionBtn').on('click', function () {
var token = $('[name="__RequestVerificationToken"]').val();
var url = actionConfirmModal.attr("data-actionUrl");
$.ajax({
url: url,
type: 'POST',
// ⚠️ 不要设置 contentType: 'application/json'
// ⚠️ 不要将 token 放入 headers
data: {
__RequestVerificationToken: token,
id: /* 你的实际 ID，例如从 data-id 属性获取 */
},
success: function (response) {
setupModal('result');
if (response.success) {
var redirectUrl = response.redirectUrl;
if (redirectUrl) {
var targetPlaceHolder = actionConfirmModal.attr("data-targetPlaceHolder");
if (targetPlaceHolder) {
$(targetPlaceHolder).load(redirectUrl);
} else {
window.location.href = redirectUrl;
}
}
} else {
$('#resultMessage').text("Error: " + response.message);
}
},
error: function (xhr, status, error) {
setupModal('result');
$('#resultMessage').text("Error: " + error);
}
});
});✅ 优势：无需额外服务端配置；与 MVC 默认模型绑定完全兼容；支持 id 等其他参数自然合并。
✅ 正确做法二：通过自定义请求头传递（需服务端配合）
若坚持使用 application/json 或需要更严格的 API 风格，可将令牌放入请求头，但必须确保服务端启用对应验证器配置（ASP.NET MVC 5.1+ 支持）：
前端代码：
$.ajax({
url: url,
type: 'POST',
contentType: 'application/json',
headers: {
'RequestVerificationToken': token // ⚠️ 注意：此处应为 '__RequestVerificationToken'（双下划线）
},
data: JSON.stringify({ id: /* your id */ }),
success: function (response) { /* ... */ }
});后端配置（Global.asax 或 Startup.cs）：
// 在 Application_Start() 中添加（MVC 5.1+）
AntiForgeryConfig.UniqueClaimTypeIdentifier = ClaimTypes.NameIdentifier;
// 并确保控制器方法使用以下特性（注意命名一致性）：
[ValidateAntiForgeryToken(AdditionalFields = "__RequestVerificationToken")]
public ActionResult Delete(int id) { ... }⚠️ 关键注意点：
- 请求头名称必须严格为 "__RequestVerificationToken"（含两个前导下划线），否则服务端无法识别；
- 若使用 contentType: 'application/json'，则 data 必须是字符串（JSON.stringify(...)），且服务端需手动读取 HttpContext.Request.Headers["__RequestVerificationToken"] 并调用 AntiForgery.Validate() —— 这会显著增加复杂度，不推荐普通场景使用。
? 常见错误排查清单
| 错误现象 | 原因 | 修复建议 |
|---|---|---|
| __RequestVerificationToken is not present | contentType: 'application/json' + data 未序列化，或 headers 键名拼写错误 | 改用 data: { __RequestVerificationToken: token }，移除 contentType 和 headers |
| 400 Bad Request / 500 Internal Server Error | id 参数未传入，导致模型绑定失败 | 在 data 中显式包含 id 字段（如 data: { __RequestVerificationToken: token, id: 123 }） |
| 页面刷新后令牌失效 | 多次调用 @Html.AntiForgeryToken() 或缓存了旧视图 | 确保每个页面仅渲染一次 @Html.AntiForgeryToken()，AJAX 成功后如需局部刷新，应重新加载含新令牌的 Partial View |
✅ 总结
对于绝大多数 ASP.NET MVC 项目，将 __RequestVerificationToken 作为普通表单字段（data 对象属性）提交是最简洁、可靠且符合框架设计意图的方式。避免混合使用 application/json 与传统 MVC 表单验证机制；如确有 JSON API 需求，建议升级至 ASP.NET Core 并采用其现代化的 [ValidateAntiForgeryToken] 与 [FromBody] 协同机制。始终确保前端获取的令牌值非空，并与服务端 @Html.AntiForgeryToken() 输出一致——这是 CSRF 防护生效的前提。
