我来帮你拆解这个问题，你遇到的情况其实是Docker和EF Core Migrate配合时的常见小坑，咱们一步步来捋清楚原因和解决办法：

一、为什么重启容器后会触发「数据库已存在」的报错？ #

首先得明确context.Database.MigrateAsync()的真实作用：它会应用所有未执行的迁移，只有当数据库不存在时才会自动创建数据库。正常情况下如果数据库已经存在，它只会跑迁移，不会尝试创建，那你遇到的报错是怎么来的？

核心原因有两个：

1. SQL Server容器启动慢，API抢跑了
   当你用docker-compose start重启容器时，ASP.NET Core容器启动速度远快于SQL Server容器（SQL Server需要加载数据、初始化服务，启动至少要几秒）。API容器启动后立刻执行MigrateAsync()，这时候SQL Server可能处于「进程已启动但还没完全就绪接受连接」的中间状态，EF Core的连接检测出现误判，误以为数据库不存在，尝试创建时才发现数据库其实已经存在（因为你用了卷持久化数据），于是抛出报错。

2. 你的SQL Server卷挂载路径可能不对（隐藏的持久化风险）
   你Compose文件里给SQL Server挂载的路径是/var/lib/mssql/data，但SQL Server on Linux的默认数据存储路径是/var/opt/mssql/data。虽然你第一次重启后数据库还在（可能是镜像版本差异或者容器缓存），但这个错误路径会导致后续如果删除容器再重建，数据会完全丢失，必须先修正这个问题。

二、完整解决方案：三步搞定报错+持久化 #

1. 先修正SQL Server的卷挂载路径（确保数据不丢） #

把Compose文件里db服务的volumes配置改成正确的路径：

services:
  db:
    # ... 其他配置不变
    volumes:
      - db-data:/var/opt/mssql/data # 把这里的路径改对

改完后，你可以用docker volume inspect db-data命令查看卷在宿主机的物理存储位置，确认数据会被持久化保存。

2. 给API加「SQL Server就绪等待逻辑」，避免抢跑执行Migrate #

我们需要在EF Core执行Migrate之前，先循环检测SQL Server是否真的能正常接受连接，直到就绪再继续。

首先在你的项目里加一个扩展方法（比如放在AppDbContext的同一个类库或者API项目里）：

using Microsoft.EntityFrameworkCore;
using System.Data.SqlClient;

public static class DbContextExtensions
{
    public static async Task WaitForSqlServerReadyAsync(this AppDbContext context, int maxRetries = 15, int delayMs = 1000)
    {
        for (int retry = 0; retry < maxRetries; retry++)
        {
            try
            {
                // 尝试打开并关闭连接，验证SQL Server是否就绪
                await context.Database.OpenConnectionAsync();
                await context.Database.CloseConnectionAsync();
                Console.WriteLine("SQL Server is ready!");
                return;
            }
            catch (SqlException)
            {
                Console.WriteLine($"Waiting for SQL Server to be ready... ({retry + 1}/{maxRetries})");
                if (retry == maxRetries - 1) throw; // 重试到上限就抛出原错误
                await Task.Delay(delayMs);
            }
        }
    }
}

然后修改你Program.cs里的数据库初始化代码，加上等待逻辑：

try{
    using var scope = app.Services.CreateAsyncScope();
    var context = scope.ServiceProvider.GetRequiredService<AppDbContext>();
    
    // 先等SQL Server完全就绪，再执行Migrate
    await context.WaitForSqlServerReadyAsync();
    
    await context.Database.MigrateAsync(); // 现在就不会报「数据库已存在」的错了
    await DbSeeder.SeedData(context);
}catch (Exception ex){
    Console.WriteLine($"An error occurred while seeding the database: {ex.Message}");
    throw;
}

3. 优化数据初始化逻辑，避免重复插入数据 #

你的DbSeeder.SeedData方法如果没有判断数据是否已存在，每次重启API都会重复插入数据，导致数据冗余。给Seed方法加个判断：

public static async Task SeedData(AppDbContext context)
{
    // 示例：检查是否已经有会议室数据，没有再插入
    if (!context.Rooms.Any())
    {
        var sampleRooms = new List<Room>
        {
            new Room { Name = "会议室A", Capacity = 10 },
            new Room { Name = "会议室B", Capacity = 5 }
        };
        context.Rooms.AddRange(sampleRooms);
        await context.SaveChangesAsync();
        Console.WriteLine("Sample data seeded successfully!");
    }
    else
    {
        Console.WriteLine("Sample data already exists, skipping seed.");
    }
}

三、验证效果 #

做完以上修改后，你可以：

1. 先停止并删除所有现有容器和卷（如果之前的卷路径不对，需要清理旧数据）：

   docker-compose down -v
   

2. 重新启动容器：

   docker-compose up -d
   

3. 等容器启动完成后，测试API是否正常；然后用docker-compose stop停止，再docker-compose start重启，观察API日志，应该不会再出现「数据库已存在」的报错，而且之前的数据也会被保留。

这样就能彻底解决你遇到的重启报错和数据持久化问题了！