Entity Framework Core自定义迁移失效 更新数据库时未生成存储过程与函数

一、先确认迁移类本身是否被EF Core正确识别 #

• 检查迁移类的命名空间是否和DbContext配置的迁移程序集路径完全匹配。EF Core只会扫描指定迁移程序集下符合规则的迁移类，命名空间偏移、类放错目录导致程序集扫描不到的情况，会直接跳过类的加载。
• 检查手动新建的迁移类是否缺少[Migration("迁移标识")]特性。EF Core不会自动根据类名识别迁移，所有纳入迁移序列的类必须携带该特性，特性值通常是“时间戳_类名”的格式，缺少该特性的类哪怕在正确的程序集里，也会被EF完全忽略，根本不会执行内部的Up/Down方法。
• 核对DbContext配置的迁移程序集指向：如果启动项中配置了MigrationsAssembly("外部程序集名称")，但你把自定义SQL的迁移类写在了当前项目目录下，EF永远不会加载到这个类。
• 执行dotnet ef migrations list命令，查看返回的迁移列表中是否存在你写的AdditionalSQLObjects项。如果列表中没有该迁移，说明识别环节就已经出问题，顺着上面的配置逐项核对就行。

二、核对迁移的实际执行状态 #

• 检查__EFMigrationsHistory表的记录：如果列表里能看到这个迁移，但执行update时提示所有迁移已应用，说明历史表里残留了该迁移的记录。哪怕你重新删除数据库，如果连接时选错了库、或者删库操作未彻底清除历史表残留，EF会默认该迁移已经执行过，完全跳过Up方法的逻辑。
• 检查迁移的排序：手动创建迁移类时如果填写的迁移时间戳早于Initial迁移的时间戳，会导致迁移排序异常。部分EF Core版本遇到排序不符合规则的迁移时，会直接跳过执行，建议把自定义SQL迁移的时间戳设为比所有结构迁移都靠后的数值，让它在所有表、字段创建完成后最后执行。

三、排查SQL执行阶段的静默失败 #

• 执行dotnet ef database update --verbose打开详细日志输出，查看控制台日志里是否打印了你写的创建函数、存储过程的SQL语句，以及对应的执行报错。很多时候迁移本身被正常触发了，只是SQL执行失败（比如语法错误、权限不足），默认日志级别不展示详细错误，容易被误判为迁移完全没执行。
• 检查数据库连接账号的权限：确认当前使用的数据库账号拥有CREATE FUNCTION、CREATE PROCEDURE的schema操作权限，权限不足导致的SQL执行被拒绝，会触发事务回滚，最终表现为表结构创建完成、SQL对象未生成，且无明确报错提示。
• 检查SQL字符串的拼接正确性：重新写迁移类时如果忘记给SQL字符串加@逐字前缀，或者字符串内的单引号、注释符号未正确转义，会导致实际执行的SQL被截断，语法错误无法通过校验。
• 针对PostgreSQL场景补充：在执行创建函数的SQL前，手动添加一行搜索路径配置migration.Sql("SET search_path TO public;")，避免因为默认schema偏移导致对象创建到错误的schema下，看起来就像没创建成功。

常见踩坑提醒：很多人手动新建迁移类时，会直接复制旧类的代码但忘记把类名、迁移特性对应的值改成唯一值，导致EF把新类和旧的同名迁移判定为同一个，直接跳过重复内容的执行。

四、版本兼容类问题排查 #

• 核对最近是否升级过EF Core、对应的数据库提供程序（比如Npgsql）：部分版本更新后会调整迁移的方言转换规则，如果之前写的SQL和新版本的方言规则不兼容，会导致执行时被拦截。
• 检查是否有编译残留：如果迁移程序集配置指向了固定路径的dll，重新写迁移类后没有重新编译生成最新的dll，EF加载的还是旧版本程序集，自然找不到你新增的迁移类。

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