创建 WebAPI 项目时应加 --no-https 参数避免 HTTPS 重定向循环；控制器推荐使用 ActionResult 统一返回类型以兼顾类型安全与灵活响应；POST 接收 JSON 需 DTO 属性 public、参数加 [FromBody]、请求头含 Content-Type: application/json；CORS 应按需配置精确源而非 AllowAnyOrigin。
用 dotnet new webapi 创建项目时要注意什么
默认命令生成的模板带 Swagger 和 HTTPS 重定向，但很多内网服务或调试场景根本不需要 HTTPS——不关掉会卡在重定向循环里，curl http://localhost:5000/api/values 直接返回 307，接口看似“不通”。
创建时加 --no-https 参数最省事：
dotnet new webapi --no-https -n MyApi。如果已生成，删掉
app.UseHttpsRedirection() 和 app.UseHsts() 这两行，再检查 launchSettings.json 里的 applicationUrl 是否同时包含 http 和 https 地址，删掉 https 那条。
Controller 返回类型选 IActionResult 还是具体模型类
初学者容易无脑全用 IActionResult，结果丢失编译时类型检查和 OpenAPI（Swagger）自动推导；全用具体类型（比如 Task<weatherforecast></weatherforecast>）又没法灵活返回 NotFound() 或 BadRequest()。
推荐统一用 ActionResult<t></t>：它既支持 return Ok(data)，也允许 return NotFound()，还能让 Swagger 正确生成响应体 Schema。
示例：
[HttpGet("{id}")]<br>public ActionResult<WeatherForecast> Get(int id)<br>{<br> var item = _context.WeatherForecasts.Find(id);<br> return item == null ? NotFound() : Ok(item);<br>}
-
ActionResult<t></t>在 .NET 6+ 是首选，别退化回裸IActionResult - 如果控制器只读不写，且所有路径都保证有数据，可用
Task<t></t>，但实际业务中几乎不存在这种理想情况 - 别给 GET 方法加
[FromBody]——Web API 默认从路由或查询字符串取参数，FromBody 只对 POST/PUT 有意义
POST 接收 JSON 数据失败的常见原因
发 curl -X POST http://localhost:5000/api/values -H "Content-Type: application/json" -d '{"name":"test"}' 却收到 400 Bad Request，大概率是模型绑定没过。
必须同时满足三个条件：
- DTO 类属性要有
public访问修饰符（private或字段（field）都不行） - 控制器方法参数要加
[FromBody]标记（.NET 5+ 默认不再隐式尝试从 Body 绑定） - 请求头
Content-Type: application/json缺一不可——用 Postman 时别只改 Body 类型而漏设 Header
错误示范：public IActionResult Post([FromBody] MyDto dto) 但 MyDto 里写的是 string Name { get; private set; } → 绑定失败，因为 setter 不可访问。
如何让 API 支持跨域（CORS）但又不放得过宽
前端跑在 http://localhost:3000，调后端 http://localhost:5000 就报 CORS 错误，不是简单加个 AllowAnyOrigin() 就完事——这会让任意网站都能调你的 API，生产环境等于裸奔。
开发阶段建议按域名精确放行：
builder.Services.AddCors(options =><br>{<br> options.AddPolicy("DevPolicy", policy =><br> {<br> policy.WithOrigins("http://localhost:3000")<br> .AllowAnyHeader()<br> .AllowAnyMethod();<br> });<br});<br>// 中间件里启用<br>app.UseCors("DevPolicy");
- 别在
UseCors前调用UseResponseCaching或UseStaticFiles，顺序错会导致 CORS 头不生效 - 生产环境禁用
AllowAnyOrigin()，必须显式列出可信域名，哪怕多个也用WithOrigins("https://a.com", "https://b.com") - 如果前端用 fetch 且带 credentials（如 cookies），
AllowAnyOrigin()会直接失效，必须指定具体 origin
真正麻烦的不是写几个 endpoint，而是每个环节的隐式约束：模型绑定规则、中间件顺序、HTTP 方法语义、CORS 的凭据模式……漏掉一个，前端就只会看到“Network Error”或者空 400，连日志都不报错。
