EF Core迁移命令不生效的主因是CLI无法解析DbContext，需安装Design包、确保构造函数支持DI、正确执行目录及避免设计时连接；空Up因未对比快照，应检查并补全InitialCreate；update报错源于库状态与迁移假设不符，建议手动编辑SQL或生成脚本审核；多环境迁移须指定对应provider并动态配置。
迁移命令不生效，dotnet ef migrations add 没反应或报错
常见现象是执行后无输出、提示“找不到 DbContext”、或报 Unable to create an object of type 'AppDbContext'。根本原因是 EF Core CLI 工具找不到可实例化的 DbContext 类，通常因为缺少设计时服务注册或构造函数参数不匹配。
实操建议：
- 确保项目中已安装
Microsoft.EntityFrameworkCore.Design包（运行时不需要，但 CLI 迁移必须） -
AppDbContext构造函数不能只接受非注入参数（如string connectionString），必须能被依赖注入容器解析——推荐保留一个接受DbContextOptions的构造函数 - 若使用
Program.cs中的AddDbContext注册，需确认迁移命令在含DbContext的项目目录下执行，且该目录有.csproj文件 - 避免在
DbContext构造函数里调用Database.EnsureCreated()或其他会触发连接的逻辑，设计时迁移阶段数据库可能不可达
迁移生成了空 Up 方法，表结构没变
这是最常被忽略的问题：EF Core 只对比当前模型与上一次迁移的快照（ModelSnapshot），不是和数据库实时比对。如果之前没成功生成过迁移，或手动删了迁移文件但没删快照，EF 就认为“模型没变”。
实操建议：
- 检查
Migrations文件夹下是否存在*_InitialCreate.cs或类似快照文件；若无，先执行一次dotnet ef migrations add InitialCreate - 删迁移文件时，务必同步删掉对应时间戳前缀的
.cs和.Designer.cs，否则快照仍指向旧状态 - 改完实体类后，别直接跑
update-database——必须先add新迁移，否则 EF 不知道要改什么 - 若想强制重置迁移链（如开发早期），可删光
Migrations目录 + 数据库，再重新add，但生产环境严禁此操作
dotnet ef database update 报错：列名已存在或约束冲突
典型错误如 There is already an object named 'XXX' in the database 或 Cannot drop column 'YYY' because it is bound to a default constraint。本质是 EF 生成的 SQL 假设目标库为空白或严格按迁移顺序演进，而实际库可能被人手改过、或有历史数据/约束残留。
实操建议：
- 开发环境可临时启用
--force参数（dotnet ef database update --force），但它不解决约束冲突，只跳过某些校验 - 更稳妥做法：打开刚生成的迁移文件，手动编辑
Up(MigrationBuilder migrationBuilder)方法，在执行DropColumn或AlterColumn前加判断，例如用migrationBuilder.Sql("IF EXISTS (...) ALTER TABLE ...") - 涉及主键变更、列重命名等高危操作，EF 默认生成的是删表重建，数据会丢失——此时应禁用自动迁移，手写 SQL 并在
Sql()中处理 - 上线前务必在预发库执行
dotnet ef migrations script生成 SQL 脚本，人工审核后再执行
不同环境用同一套迁移，但连接字符串或配置不同
本地连 SQLite，测试环境连 SQL Server，生产连 PostgreSQL——迁移命令却总按默认 provider 生成，导致 add 出来的迁移含 SQL Server 语法，部署到 PostgreSQL 就失败。
实操建议：
- 迁移过程本身不依赖数据库连接，但 provider 决定生成的 SQL 语法和类型映射，所以
dotnet ef命令必须指定对应 provider 的程序集。例如用 PostgreSQL 时，需确保项目引用Npgsql.EntityFrameworkCore.PostgreSQL，且 CLI 能加载它 - 在
DbContext的OnConfiguring中不要硬编码 provider，改用UseSqlServer/UseNpgsql等扩展方法，并通过IConfiguration动态选择 - 若多个 provider 共存，可在
dotnet ef migrations add后加--context AppDbContext显式指定上下文，避免 CLI 扫描出错 - CI/CD 中执行迁移时，用
dotnet ef database update --connection "xxx"显式传入连接字符串，绕过代码里的配置逻辑，更可控
迁移真正的复杂点不在命令怎么敲，而在模型变更和数据库现状之间那层看不见的契约——EF 的迁移文件只是“差分快照”，不是“数据库终态描述”。手改过表、跨库同步、多团队共用一个数据库时，这层契约最容易撕裂。
