Azure函数配置KeyVault存储SQL连接字符串报错排查

问题原因 #

这个错误的核心矛盾在于：函数启动阶段的配置加载逻辑，和运行时的KeyVault引用解析逻辑不同步。

启动时（比如在Startup.cs配置DbContext服务的阶段），.NET配置系统还没完成Azure KeyVault的引用替换，直接把带@Microsoft.KeyVault(SecretUri=...)的原始占位符字符串传给了SQL连接字符串解析器——而SQLClient根本不认识这个前缀，因此抛出"Keyword not supported"错误。但到了运行阶段，Azure环境会自动替换该占位符为真实的连接字符串，所以函数实际能正常访问数据库，数据库也会生成操作日志，同时门户会捕获启动阶段的错误并弹出警告。

解决方案 #

方案一：跳过启动阶段的连接字符串验证 #

如果使用EF Core，可以在配置DbContext时，避免让SQLClient在启动时解析KeyVault占位符，依赖Azure运行时的自动替换逻辑：

var connectionString = Configuration.GetConnectionString("YourSqlConnection");
services.AddDbContext<YourDbContext>(options =>
{
    // 直接传入原始占位符字符串，运行时会自动替换为真实连接串
    options.UseSqlServer(connectionString);
});

这种方式不需要额外处理，适合大多数场景，启动时的报错本质是"假报错"，但如果想彻底消除日志警告，可以用下面的方案。

方案二：启动阶段主动加载KeyVault配置 #

通过手动配置KeyVault加载，让启动阶段就完成占位符的替换，从根源上消除报错：

1. 安装NuGet包：Microsoft.Extensions.Configuration.AzureKeyVault和Azure.Identity
2. 在Program.cs（隔离进程模型）或Startup.cs中添加KeyVault配置逻辑：

var host = new HostBuilder()
    .ConfigureAppConfiguration((context, config) =>
    {
        var builtConfig = config.Build();
        var vaultUri = new Uri(builtConfig["KeyVaultUri"]);
        // 使用默认Azure凭据加载KeyVault
        config.AddAzureKeyVault(vaultUri, new DefaultAzureCredential());
    })
    .ConfigureFunctionsWorkerDefaults()
    .Build();

host.Run();

这样启动时配置系统会直接从KeyVault拉取真实的连接字符串，SQLClient就能正常解析，门户警告也会消失。

门户警告说明 #

门户的警告只是捕获了启动阶段的错误日志，由于运行时连接串能正常替换，所以不会影响函数的实际执行。解决启动报错后，警告会自动消失。

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