使用ASP.NET发送DELETE请求报400 Bad Request Postman测试正常

第一步：先修正前端AJAX代码里的配置硬伤 #

你当前写的jQuery AJAX代码存在多处配置拼写、结构错误，会直接导致生成的请求不符合规范，被后端判定为非法请求返回400：

• 请求头配置参数错误：jQuery中设置请求头的配置项是headers（采用对象结构），你写的header:"Content-Type:application/json"既不对参数名，结构也错，完全不会生效；而且DELETE请求没有请求体载荷，根本不需要强制设置Content-Type:application/json，强行设置反而可能触发后端的请求校验规则报错。
• 跨域配置参数错误：jQuery识别的跨域开关是驼峰命名的crossDomain，你写的全小写crossdomain: true会被jQuery直接忽略，没有任何效果。
• 状态码判断逻辑偏差：你后端接口返回的是204 No Content，不是200，就算请求调通了，现有判断逻辑也走不到成功分支，这属于额外的代码坑，不是400的根因但会影响正常交互。

第二步：排查跨域预检请求拦截问题 #

你用Postman测试接口是正常的，是因为Postman不会触发浏览器的跨域预检流程；但前端跨端口调用时，DELETE属于非简单请求，浏览器会在发正式DELETE请求前，先发一个OPTIONS类型的预检请求，询问后端是否允许跨域调用。
如果后端ASP.NET的CORS配置没有放行OPTIONS请求、没有放开允许的请求头，甚至接口加了全局认证过滤器拦住了不带认证信息的OPTIONS请求，这个预检请求会直接返回400，前端控制台报的400其实就是预检请求的报错，和正式DELETE请求本身没关系。
验证方法：打开浏览器开发者工具的Network面板，找到报错的400请求，看请求方法是不是OPTIONS，如果是，就去后端CORS配置里补全规则：允许跨域来源、允许DELETE方法、放行OPTIONS预检请求、放开需要的请求头，同时给OPTIONS请求开匿名访问通道，避免被认证逻辑拦截。

第三步：核对实际请求的URL与参数 #

在Network面板里点开报错的DELETE请求，核对实际请求的URL格式：

• 检查拼接的URL后面是不是带着有效的数字ID，比如是不是因为deleteid取值为undefined、null、非数字，拼出来的URL变成了http://localhost:12091/api/post/，根本匹配不到后端Delete(int id)的接口路由，后端路由匹配失败就会返回400。
• 确认ID的类型是后端要求的int类型，如果传了带特殊字符、非数字的字符串，后端模型绑定失败，也会直接返回400，这和你Postman手动传正确数字ID的测试场景是有区别的。

修正后的前端代码参考 #

var deletepost = function(deleteid){
    // 前置校验ID有效性，避免拼出错误请求
    if(!deleteid || isNaN(Number(deleteid))) {
        console.error("待删除的帖子ID无效：", deleteid);
        return;
    }
    $.ajax({
        url: `http://localhost:12091/api/post/${deleteid}`,
        method: "DELETE",
        // 正确的请求头配置写法，DELETE无请求体无需额外设置Content-Type
        headers: {},
        // 正确的驼峰跨域参数名
        crossDomain: true,
        complete: function(xmlhttp) {
            // 兼容后端返回的204无内容状态
            if(xmlhttp.status === 200 || xmlhttp.status === 204) {
                alert("Post Deleted");
            } else {
                console.log(`${xmlhttp.status}: ${xmlhttp.statusText}`);
                console.log("unsuccessful");
            }
        }
    })
}

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