根据你描述的情况，静态文件能正常访问但API接口无法工作，大概率是部署配置或运行时环境的细节遗漏导致的，给你几个针对性的排查步骤：

• 确认部署产物的完整性与web.config配置
  你提到用Azure DevOps执行的是构建而非发布操作，这可能是核心问题——.NET Core API的部署需要发布产物（而非单纯的构建输出），其中关键的web.config文件会包含IIS模块的请求转发配置。你需要检查站点根目录下是否存在正确的web.config，并且配置内容是否准确：

  <?xml version="1.0" encoding="utf-8"?>
  <configuration>
    <location path="." inheritInChildApplications="false">
      <system.webServer>
        <handlers>
          <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModuleV2" resourceType="Unspecified" />
        </handlers>
        <aspNetCore processPath="dotnet" arguments=".\YourApiProject.dll" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" hostingModel="inprocess" />
      </system.webServer>
    </location>
  </configuration>
  

  重点核对arguments里的DLL名称是否和你的API项目一致，hostingModel（inprocess或outofprocess）是否符合项目的设置。

• 启用stdout日志排查具体错误
  这是最有效的调试手段：修改web.config里的stdoutLogEnabled="true"，然后在站点目录下创建logs文件夹，给IIS_IUSRS或应用池身份授予该文件夹的写入权限。之后尝试访问API，查看logs目录下的日志文件，里面会详细记录启动失败的具体原因（比如依赖缺失、配置文件错误、端口占用等）。

• 验证应用池与权限配置细节
  除了确认.NET CLR版本为“无托管代码”，还要检查：

  • 应用池的身份（比如默认的ApplicationPoolIdentity）是否拥有API目录的读取权限，有时候单独给IIS_IUSRS权限不够，需要给应用池身份单独授权。
  • 应用池是否启用了32位应用程序？如果你的API是64位编译的，要确保这个选项是禁用状态，否则会导致程序集加载失败。

• 确认服务器上的.NET Core Runtime版本
  确保服务器安装了与你的API项目目标框架完全匹配的.NET Core Runtime（比如你的项目用.NET 6，服务器就要装.NET 6 Runtime）。可以在服务器命令行运行dotnet --info查看已安装的运行时版本，如果版本不匹配，下载对应版本的Runtime安装即可。

• 本地直接运行API验证应用本身
  登录到远程服务器，打开命令行进入API的目录，运行dotnet YourApiProject.dll，看是否能正常启动并监听端口。如果本地运行失败，说明是应用本身的问题（比如appsettings配置错误、依赖缺失）；如果本地能正常运行，再回到IIS的配置排查请求转发问题。

• 检查站点物理路径与路由配置
  确认IIS站点的物理路径是否直接指向包含web.config和API DLL的根目录，不要错误指向子目录。另外，确保API的路由配置正确，比如你访问的/api/xxx是否和代码里的路由注解完全匹配。

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