appsettings.development.json没生效的最常见原因是aspnetcore_environment环境变量未设为严格大小写的“development”；需检查该变量值、launchsettings.json配置、cli或docker启动参数，并确保文件路径正确且具有读取权限。
appsettings.Development.json 为什么没生效？
最常见原因是 ASPNETCORE_ENVIRONMENT 环境变量没设对，或者根本没设。框架只在该变量值为 Development（严格大小写）时才加载 appsettings.Development.json。它不会根据项目名、文件存在与否或调试模式自动触发。
检查方式：在代码里加一行日志：Console.WriteLine(Environment.GetEnvironmentVariable("ASPNETCORE_ENVIRONMENT"));；或在终端运行 echo $ASPNETCORE_ENVIRONMENT（Linux/macOS）或 echo %ASPNETCORE_ENVIRONMENT%（Windows）。
- Visual Studio 默认从
launchSettings.json读取环境变量，确保其中environmentVariables节点包含"ASPNETCORE_ENVIRONMENT": "Development" - .NET CLI 启动时可显式指定：
dotnet run --environment Development - Docker 容器需在
docker run中加-e ASPNETCORE_ENVIRONMENT=Development - 若环境变量为空或为
Production，appsettings.Development.json直接被跳过，不报错也不警告
同名配置项到底谁覆盖谁？
优先级顺序是硬规则：appsettings.json ← appsettings.{Environment}.json ← 环境变量 ← 命令行参数。后加载的同名键（key）会完整覆盖前面的值，不是合并。
例如：
{
"Logging": {
"LogLevel": {
"Default": "Warning"
}
}
}
在 appsettings.Development.json 中写：
{
"Logging": {
"LogLevel": {
"Microsoft.AspNetCore": "Debug"
}
}
}
结果是：Logging:LogLevel:Default 变成 Warning（被覆盖），而 Logging:LogLevel:Microsoft.AspNetCore 是 Debug（新增）。注意：它不会保留 Default 的原始值 —— 因为整个 Logging:LogLevel 对象没被完整写出，框架只按路径逐层覆盖。
- 想保留基础配置又只改局部，必须在环境文件中重复写出完整层级，或改用
IOptionsMonitor<t></t>+ 强类型绑定做逻辑合并 - 环境变量如
Logging__LogLevel__Default=Information（双下划线替代冒号）优先级更高，会压倒所有 JSON 文件里的同名项 -
launchSettings.json本身不参与 IConfiguration 加载，它只负责启动时设置环境变量和端口等，不提供配置项
开发环境敏感数据放哪更安全？
appsettings.Development.json 仍属源码文件，不适合存密码、密钥等。它比 appsettings.json 优先级高，但比环境变量低，且容易误提交到 Git。
推荐组合方案：
- 本地开发用
User Secrets：执行dotnet user-secrets init && dotnet user-secrets set "Jwt:Key" "dev-key-123"，它自动注入到IConfiguration，优先级与appsettings.Development.json相同，但不进源码 - CI/CD 流水线用环境变量：比如 Azure Pipelines 的变量组、GitHub Actions 的
secrets，它们会作为环境变量注入，优先级更高 - 绝对不要在
appsettings.Development.json里写"ConnectionStrings:DefaultConnection": "Server=...;Password=123456;"—— 即使是本地 SQL Server 账户，也建议用 Windows 身份验证或临时凭据
为什么修改 appsettings.Development.json 后配置没变？
默认情况下，reloadOnChange: true 只对 appsettings.json 和 appsettings.{Environment}.json 生效，但有前提：文件必须位于应用工作目录（通常是项目根或发布输出目录），且进程有读取+文件系统监视权限。
典型失效场景：
- 发布到 IIS：网站物理路径下没有
appsettings.Development.json，或ApplicationPoolIdentity没有读取权限 - Docker 容器：JSON 文件挂载为只读，或使用
COPY --chown=www-data:www-data但未给文件加读权限 - 控制台工具或单元测试：手动构建
ConfigurationBuilder时漏了reloadOnChange: true参数，或路径用错了（Directory.GetCurrentDirectory()在某些上下文返回 bin 目录） - 编辑器保存时用了 BOM 头或尾逗号，导致 JSON 解析失败，框架静默跳过该文件 —— 查看日志里是否有
Failed to parse the JSON file提示
真正可靠的做法不是依赖文件热重载，而是把开发期可变配置（如端口、调试开关）通过环境变量传入，启动即确定，避免运行时不确定性。
