EF Core数据库初始化策略有哪些
EF Core本身不再内置数据库初始化器（如EF6的
CreateDatabaseIfNotExists等），这些策略在EF Core 1.0之后已被移除。取而代之的是更可控、更明确的初始化方式——主要靠迁移（Migrations）和手动种子数据（Seeding）来完成。但开发者仍可通过自定义逻辑模拟类似行为，常见思路有： 首次运行时建库+填默认数据：检查数据库是否存在，若无则执行迁移并填充种子数据 每次启动都重建库（仅开发用）：调用
context.Database.EnsureDeleted()+
EnsureCreated()，注意会丢失所有数据 模型变更时自动同步结构（不推荐生产）：监听
DbContext初始化时机，比对模型快照差异后触发迁移 完全禁用自动初始化：只靠显式迁移命令管理，最安全、最符合团队协作规范
EF Core数据库初始化方法
实际项目中，主流且推荐的方式是迁移 + 种子数据分离处理，分两步走：
结构初始化：用迁移命令创建/更新表结构在终端执行：
dotnet ef migrations add InitialCreate
dotnet ef database update
这会生成迁移文件并应用到目标数据库，支持增量演进 数据初始化：在程序启动时注入种子逻辑
通常写在
Program.cs（.NET 6+）中，通过依赖注入获取
DbContext和服务提供器，检查关键表是否为空，再插入默认用户、角色、配置项等
示例片段：
if (!context.Users.Any()) { context.Users.Add(new ApplicationUser { UserName = "admin" }); context.SaveChanges(); }
连接字符串决定初始化位置数据库是否真被创建，取决于连接字符串指向的实例是否可访问+是否有权限。本地调试常用
Sqlite或
LocalDB；生产环境必须使用带完整权限的SQL Server/PostgreSQL连接串
如何选择初始化方式
看所处阶段：
开发初期：用EnsureCreated()快速验证模型，但别提交到共享分支 团队协作/测试环境：统一使用迁移，每次模型改完必须跑
add migration并提交迁移文件 生产部署：禁止任何自动删库建库操作；只允许
dotnet ef database update或生成SQL脚本人工审核后执行 需要预置业务数据：把种子逻辑封装成独立服务，在
HostedService或
Program.cs中按需调用，避免重复插入
基本上就这些。不复杂但容易忽略的是：迁移 ≠ 种子数据，结构和内容要分开管。
