我之前也碰到过几乎一模一样的问题——本地调试一切正常，部署到正式IIS后PUT请求全报405 Method Not Allowed。结合你的场景（Angular嵌入Web API项目），大概率是服务器端的配置限制，而非代码本身的问题。下面给你拆解最可能的原因和对应的解决办法：

最常见元凶：IIS的WebDAV模块拦截了PUT请求 #

WebDAV是IIS默认启用的模块，它会优先抢占PUT、DELETE这类HTTP方法的处理权，导致你的Web API根本接收不到请求。本地开发用的IIS Express默认没启用WebDAV，所以不会触发这个问题，但部署到正式IIS就会踩坑。

解决方法： #

• 方法一：通过web.config禁用WebDAV
  在你的Web API项目的web.config文件中，找到<system.webServer>节点，添加以下配置：

  <modules runAllManagedModulesForAllRequests="true">
    <remove name="WebDAVModule" />
  </modules>
  <handlers>
    <remove name="WebDAV" />
    <remove name="ExtensionlessUrlHandler-Integrated-4.0" />
    <add name="ExtensionlessUrlHandler-Integrated-4.0" path="*." verb="GET,HEAD,POST,DEBUG,PUT,DELETE,PATCH,OPTIONS" type="System.Web.Handlers.TransferRequestHandler" preCondition="integratedMode,runtimeVersionv4.0" />
  </handlers>
  

  这段配置会移除WebDAV的模块和处理程序，同时确保无扩展名的URL处理程序允许PUT等所有需要的HTTP方法。

• 方法二：在IIS管理器中手动禁用WebDAV
  登录服务器打开IIS管理器，找到你的站点：

  1. 进入「模块」功能，找到WebDAVModule，右键点击「移除」；
  2. 再进入「处理程序映射」，找到WebDAV，右键移除即可。

检查IIS的请求筛选规则 #

IIS的请求筛选功能可能限制了PUT方法的使用，直接拦截了请求。

解决方法： #

1. 打开IIS管理器，找到目标站点，进入「请求筛选」；
2. 切换到「HTTP方法」标签，检查列表中是否包含PUT；
3. 如果没有，点击「允许添加」，输入PUT并确认；
4. 同时确保列表中没有拒绝PUT的规则。

验证Web API的路由与动作配置 #

虽然本地运行正常，但部署后可能因为新增功能导致路由冲突，或者动作定义存在隐性问题。

检查点： #

• 确认PUT动作方法上是否正确标记了[HttpPut]特性，且路由模板无误，比如：

  [HttpPut]
  [Route("api/items/update/{id}")]
  public IHttpActionResult UpdateItem(int id, [FromBody] ItemDto model)
  {
      // 业务逻辑
  }
  

• 排查新增功能后是否添加了重叠的路由，导致原有PUT路由被覆盖；
• 可以在服务器上启用Web API的日志记录，查看请求是否真的到达API，以及路由匹配的详细情况。

最后确认CORS配置（别忽略这个小细节） #

虽然你认为Angular嵌入API项目就不会有CORS问题，但部署后可能因为环境差异导致CORS配置未生效，而405错误有时会伴随预检请求失败出现。

检查点： #

• 确认Web API的CORS配置正确，比如在WebApiConfig.cs中：

  config.EnableCors(new EnableCorsAttribute("*", "*", "*"));
  

  或者在控制器/方法上标记[EnableCors]特性；
• 部署后打开浏览器控制台，查看网络请求中的OPTIONS预检请求，确认响应是否正常，有没有CORS相关的报错。

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