Ionic Framework中如何处理（而非修复）API维护时的CORS异常

以下是三个可落地的实现方向，你可以根据团队的改造成本选择适配方案：

方案1：调整IIS配置，保留app_offline.htm机制的同时允许预检请求通过 #

改造成本最低，无需修改前端代码。
首先确保IIS已经安装URL重写模块，然后在API站点的web.config中添加如下规则：

<system.webServer>
  <rewrite>
    <rules>
      <rule name="Allow CORS Preflight even when app_offline exists" stopProcessing="true">
        <match url=".*" />
        <conditions>
          <add input="{REQUEST_METHOD}" pattern="OPTIONS" />
        </conditions>
        <action type="CustomResponse" statusCode="204" statusReason="No Content" statusDescription="Preflight OK" />
        <serverVariables>
          <set name="RESPONSE_Access-Control-Allow-Origin" value="*" /> <!-- 替换为前端实际域名安全性更高 -->
          <set name="RESPONSE_Access-Control-Allow-Methods" value="GET, POST, PUT, DELETE, OPTIONS" />
          <set name="RESPONSE_Access-Control-Allow-Headers" value="*" /> <!-- 替换为实际允许的自定义头 -->
          <set name="RESPONSE_Access-Control-Max-Age" value="86400" />
        </serverVariables>
      </rule>
    </rules>
  </rewrite>
  <!-- 原有配置保持不变 -->
</system.webServer>

该规则执行优先级高于app_offline.htm的拦截逻辑，所有OPTIONS预检请求会直接返回合法的CORS响应，不会被拦截为503。预检通过后，实际业务请求会被app_offline.htm拦截返回503，前端可以正常捕获状态码并展示维护页面。

也可以直接配置IIS全局503错误响应的CORS头，让503响应本身符合CORS规则，浏览器就不会拦截错误信息，前端可直接读取503状态。

方案2：Ionic/Angular端调整请求逻辑，捕获维护状态 #

如果不方便调整后端IIS配置，可以修改前端逻辑：

• 替换Angular默认的HttpClient为Ionic原生HTTP插件：原生HTTP请求不受浏览器CORS规则限制，不会自动发送OPTIONS预检请求，可以直接拿到所有HTTP状态码（包括503），直接判断状态码展示维护页即可。
• 增加全局错误拦截逻辑：在Angular的HTTP拦截器中，判断如果请求返回无状态码的跨域错误、且请求目标是你的API域名，可以统一判定为维护状态弹出提示。为了避免和用户无网络的情况混淆，可以新增一个轻量健康检查接口，该接口部署在独立于业务API的站点路径下，不会被app_offline.htm拦截，当出现跨域错误时调用该接口，如果健康检查接口正常返回则判定为API维护，否则判定为用户网络异常。

方案3：避免触发OPTIONS预检请求 #

如果业务规则允许，可以调整请求格式让所有请求符合浏览器简单请求规则，从根源上避免预检：

• 移除自定义请求头，把原本放在自定义头里的参数移动到URL查询参数、请求体或者标准请求头（如Authorization）中
• 将Content-Type限制为application/x-www-form-urlencoded、multipart/form-data或text/plain三种类型
  调整后不会发送OPTIONS预检请求，业务请求返回的503状态码可以直接被前端捕获。

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