ASP.NET Core 2.1.4应用在macOS命令行使用user-secrets运行失败

我之前也碰到过类似的诡异场景——同一ASP.NET Core 2.1.4项目在Windows命令行、macOS/Windows的Visual Studio里都能正常读取用户密钥，偏偏macOS终端执行dotnet run就不行，还好dotnet user-secrets list能正常输出，说明密钥本身是存在的，咱们一步步来排查解决：

1. 先确认你是不是在正确的目录下执行命令 #

macOS终端里，dotnet run必须在项目文件（.csproj）所在的目录下运行，要是你在解决方案（.sln）目录执行，它可能找不到和项目绑定的用户密钥配置：

• 先敲pwd查看当前路径，确认是不是和.csproj文件在同一层级；
• 要是不在，用cd命令切换到项目根目录后，再执行dotnet run。

2. 核对用户密钥ID和项目的绑定关系 #

用户密钥是靠唯一的UserSecretsId和项目关联的，有可能macOS这边项目的ID和密钥存储目录的ID不匹配：

• 打开你的.csproj文件，找到<UserSecretsId>配置项，记下来里面的唯一ID；
• 前往macOS的密钥存储目录查看：~/.microsoft/usersecrets/，里面的文件夹名称必须和刚才的ID完全一致；
• 要是对不上，要么更新.csproj里的UserSecretsId为存储目录对应的ID，要么重新执行dotnet user-secrets init生成正确的关联。

3. 检查当前的环境变量是不是Development #

用户密钥默认只在Development环境下加载，说不定你macOS终端里的环境变量配置不对：

• 执行echo $ASPNETCORE_ENVIRONMENT查看输出是否为Development；
• 要是不是，先执行export ASPNETCORE_ENVIRONMENT=Development，再重新运行dotnet run试试。

4. 清理项目缓存再重建 #

有时候macOS下的配置缓存会出问题，试试清理重建项目：

dotnet clean
dotnet restore
dotnet build

跑完这三个命令后再执行dotnet run，大概率能解决缓存导致的读取异常。

5. 确认代码里的配置加载逻辑没问题 #

ASP.NET Core 2.1的CreateDefaultBuilder已经默认包含了用户密钥的加载（仅限Development环境），但如果你自定义了配置构建逻辑，得确保添加了读取用户密钥的代码：
比如在Program.cs中：

public static IWebHost BuildWebHost(string[] args) =>
    WebHost.CreateDefaultBuilder(args)
        .ConfigureAppConfiguration((context, config) =>
        {
            // 自定义配置时，确保添加这行来加载用户密钥
            config.AddUserSecrets<Startup>();
        })
        .UseStartup<Startup>()
        .Build();

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