本地调试Azure Function时Angular调用HTTP触发接口遭遇CORS阻止如何解决

第一步：先排除配置读取失败的基础问题 #

• 确认local.settings.json的文件属性：在Visual Studio的解决方案资源管理器中，选中该文件，将「复制到输出目录」的属性设置为如果较新则复制。如果保持默认的「不复制」，调试启动时函数运行时根本不会读取你写的配置，所有CORS设置都是无效的。
• 严格核对配置项的大小写：Azure Functions对Host配置的键名是严格大小写匹配的，不能把"CORS"写成小写"cors"或混写"Cors"，键名拼写错误会导致整段Host配置被运行时直接忽略。
• 核对启动参数的实际生效状态：你在项目调试属性里加的启动命令，启动后要在函数控制台的日志里确认是否加载了对应CORS配置。如果日志里显示的CORS值为空，说明参数被VS默认的启动流程覆盖了，没有实际传达到运行时。

第二步：解决预检请求（OPTIONS）被拦截的核心问题 #

• 清理函数代码中的冗余CORS响应头：很多人会在函数逻辑里手动给响应加Access-Control-Allow-Origin之类的头，这会和运行时自动注入的CORS头产生冲突，导致浏览器检测到响应头重复或值不匹配，直接判定跨域失败。需要把所有代码里手动写的CORS相关响应头全部删除，交给Azure Functions运行时统一处理。
• 协议对齐校验：如果你用--useHttps参数启动了HTTPS模式的函数服务，要确认Angular前端请求的协议和函数服务的协议完全一致。比如前端跑在http://localhost:4200，函数跑在https://localhost:7071，就算开了CORS，预检请求返回的头也会因为协议匹配问题不被浏览器认可。
• 通配符的适用边界：当CORSCredentials设为false时，"CORS": "*"是可以正常工作的；但如果后续请求需要携带Authorization头、Cookie等凭证信息，绝对不能用*作为CORS值，此时要把CORS配置成前端的实际访问地址，比如"CORS": "http://localhost:4200"，否则带凭证的请求会直接被浏览器拦截。

第三步：快速验证配置是否生效 #

不要直接用Postman测试（Postman不触发CORS校验），直接模拟浏览器的预检请求看响应头：

• 用curl发送带预检头的OPTIONS请求，比如：

  curl -i -X OPTIONS http://localhost:7071/api/你的函数路由 -H "Origin: http://localhost:4200" -H "Access-Control-Request-Method: POST"
  

• 检查返回的响应头里是否包含Access-Control-Allow-Origin、Access-Control-Allow-Methods、Access-Control-Allow-Headers这几个预检必需的字段，如果没有，说明配置根本没被运行时读取。

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