这个问题我之前在项目里踩过坑——ASP.NET Core启动阶段的ConfigureServices和Configure方法里的日志调用，刚好卡在NLog从appsettings加载配置的节点之前，导致数据库Target拿不到完整连接字符串，直接报错。给你几个实用的解决方案，按需选择：

先让NLog用临时Target（比如控制台、本地文件）处理启动初期的日志，等配置完全加载后再动态启用数据库Target，步骤如下：

1. 在你的NLog配置文件（比如nlog.config）里，先把数据库Target设为禁用状态：

<target xsi:type="Database" name="DatabaseTarget" enabled="false"
        connectionString="${configsetting:name=ConnectionStrings.YourDbConn}">
    <!-- 数据库Target的其他配置（比如命令文本、参数） -->
</target>

2. 在Startup的Configure方法末尾（或者ConfigureServices加载完所有配置后），手动更新并启用数据库Target：

// 从已就绪的配置中获取完整连接字符串
var dbConnString = Configuration.GetConnectionString("YourDbConn");

// 获取NLog当前配置
var nlogConfig = LogManager.Configuration;
var dbTarget = nlogConfig.FindTargetByName<DatabaseTarget>("DatabaseTarget");

if (dbTarget != null)
{
    // 更新连接字符串（可选，如果你确认configsetting已经能正确读取的话也可以跳过）
    dbTarget.ConnectionString = dbConnString;
    // 启用数据库Target
    dbTarget.Enabled = true;
    // 让NLog重新加载配置，生效新的设置
    LogManager.ReconfigExistingLoggers();
}

这样启动初期的日志只会走临时Target，等配置就绪后才会切换到数据库写入。

通过NLog的条件过滤规则，只在配置就绪标记生效后，才允许日志写入数据库：

1. 在Startup里设置一个全局标记，当配置加载完成后激活它：

// 在ConfigureServices或Configure的合适位置（确保配置已加载）
GlobalDiagnosticsContext.Set("AppConfigReady", "true");

2. 在NLog配置文件里给数据库Target的日志规则添加过滤条件：

<rules>
    <!-- 所有日志默认写入控制台，确保启动日志不丢失 -->
    <logger name="*" minlevel="Trace" writeTo="console" />
    <!-- 只有当AppConfigReady标记为true时，才写入数据库 -->
    <logger name="*" minlevel="Info" writeTo="DatabaseTarget">
        <filters>
            <when condition="${gdc:item=AppConfigReady} != 'true'" action="Ignore" />
        </filters>
    </logger>
</rules>

启动初期这个标记还没设置，数据库Target会自动忽略这些日志，不会触发连接错误。

默认情况下如果在Program.cs早期就初始化NLog，可能会赶在配置加载完成前启动。可以把NLog的初始化移到主机构建的后期，确保配置已经就绪：

public static IHostBuilder CreateHostBuilder(string[] args) =>
    Host.CreateDefaultBuilder(args)
        .ConfigureWebHostDefaults(webBuilder =>
        {
            webBuilder.UseStartup<Startup>();
        })
        // 把NLog初始化放在最后，确保配置已加载完成
        .UseNLog();

不过要注意：Startup的ConfigureServices里的早期日志可能会使用ASP.NET Core的默认日志提供者（比如控制台），等NLog初始化完成后才会接管后续日志。如果能接受启动初期日志走默认提供者，这个方案最省心。

给数据库Target添加失败降级机制，即使启动初期写入失败，也不会抛出错误，而是自动切换到其他Target：

<target xsi:type="Database" name="DatabaseTarget"
        connectionString="${configsetting:name=ConnectionStrings.YourDbConn}"
        writeToFailOnError="false" fallbackTarget="console">
    <!-- 数据库Target的其他配置 -->
</target>

writeToFailOnError="false"会让NLog忽略数据库写入的错误，fallbackTarget指定失败时转存的Target。这个方案不能阻止初期的连接尝试，但能避免NLog自身报错，同时保证日志不丢失。

如果推荐的话，方案一和方案二更精准，能完全避免启动初期的数据库连接尝试；方案三最简洁，适合对启动日志提供者要求不高的场景。

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