c#如何创建WebAPI_c#WebAPI的几种常见用法-C#.Net教程-PHP中文网

dotnet new webapi -n MyApi 创建默认启用Controllers路由、JSON序列化和Swagger的基础项目，.NET 6+使用Minimal Hosting模型，Program.cs统一配置；常见404因缺少[ApiController]或路由错误，返回应优先用ActionResult以支持状态码控制。

c#如何创建webapi_c#webapi的几种常见用法

用 `dotnet new webapi` 创建最简 WebAPI 项目

命令行执行 dotnet new webapi -n MyApi 就能生成一个带 WeatherForecastController 的基础项目。它默认启用 Controllers 路由、JSON 序列化和 Swagger（访问 /swagger 可见）。注意：.NET 6+ 默认使用 Minimal Hosting 模型，Program.cs 里没有 Startup 类，所有配置都在一个文件里完成。

常见错误：运行后返回 404 —— 很可能是没加 [ApiController] 特性，或控制器没继承 ControllerBase；也可能是路由模板写错，比如误写成 [Route("api/[controller]/[action]")] 却没定义 Action 方法。

dotnet new webapi 默认禁用 HTTPS 重定向，开发时可忽略，上线前需确认 app.UseHttpsRedirection() 是否启用
若需兼容 .NET 5 风格（带 Startup.cs），加参数 --framework net5.0，但不推荐新项目这么做
Swagger 页面空白？检查是否漏掉 builder.Services.AddEndpointsApiExplorer() 和 builder.Services.AddSwaggerGen()

用 `[HttpGet]`、`[HttpPost]` 等特性定义 REST 接口

控制器方法必须显式标注 HTTP 方法特性，否则不会被路由识别。例如：[HttpGet] 绑定 GET 请求，[HttpPost] 绑定 POST，且默认按参数名匹配 URL 或请求体。

容易踩的坑：POST 方法接收 JSON 数据时，参数必须是类类型并标记 [FromBody]；若传的是简单类型（如 int、string），必须加该特性，否则绑定失败返回 400 Bad Request。

URL 路径参数用 [FromRoute]（默认行为），查询参数用 [FromQuery]，表单数据用 [FromForm]
[Route("api/[controller]/[action]") + [HttpGet] 是冗余的，优先用更细粒度的 [HttpGet("detail/{id}")]
多个同名方法（如两个 [HttpGet]）会导致编译报错，需靠路由模板或参数类型区分

用 `ActionResult` 统一返回类型与状态码

返回 ActionResult 而不是裸的 WeatherForecast，能让你在方法内灵活返回 Ok()、NotFound()、BadRequest() 等带状态码的结果，同时保持 Swagger 正确推断响应结构。

"避开 C# 常见错误——空陷阱、异步陷阱、LINQ 陷阱及资源泄漏。"

下载

如果只返回 Task，就只能返回 200，无法主动控制 HTTP 状态码，调试时容易误判失败响应。

返回 Ok(model) → 200 + JSON；NotFound() → 404，无响应体；BadRequest("msg") → 400 + 字符串
不要混用 IActionResult 和 ActionResult 在同一控制器中，会干扰 Swagger 生成和客户端类型推导
.NET 7+ 支持 Results.Ok(...) 等静态工厂方法，适合 Minimal API 场景，但传统控制器中仍推荐用 ActionResult

跨域（CORS）配置不当导致前端请求被浏览器拦截

前端用 fetch 或 axios 调用本地 WebAPI 时，若端口不同（如 http://localhost:3000 → http://localhost:5000），浏览器会先发 OPTIONS 预检请求。没配 CORS 就直接被拦，控制台报 No 'Access-Control-Allow-Origin' header。

正确做法是在 Program.cs 中注册策略，并在中间件中启用：

builder.Services.AddCors(options =>
{
    options.AddPolicy("AllowFrontend", policy =>
        policy.WithOrigins("http://localhost:3000")
              .AllowAnyMethod()
              .AllowAnyHeader());
});
...
app.UseCors("AllowFrontend");

策略名（如 "AllowFrontend"）必须在 AddCors 和 UseCors 中完全一致
AllowAnyOrigin() 在生产环境禁止使用，会暴露安全风险；务必指定明确域名
CORS 中间件位置很关键：必须在 UseRouting() 之后、UseAuthorization() 和 UseEndpoints() 之前调用

.NET WebAPI 的复杂点不在创建，而在接口契约稳定性、模型验证绑定时机、以及中间件顺序这类“看不见”的地方。尤其当加入 JWT 验证、限流、全局异常过滤时，任意一步顺序错位都可能导致 401 不触发、异常不被捕获、或 CORS 失效。这些细节比写接口本身更值得花时间验证。