GitHub Actions数据库迁移显示成功但实际未创建表

1. 先确认连接串是否指向正确的数据库 #

• 检查GitHub Actions里用的数据库连接串，和你SSMS/ADS连接的是不是同一个Azure SQL实例、同一个库——别搞混测试库和生产库，或者拼错了数据库名。
• 去App Service的配置里看Connection Strings项，也可以在Kudu控制台跑echo $ConnectionStrings__YourDbConnName（替换成你的连接串名称），验证实际生效的连接串。

2. 检查数据库用户的权限与架构 #

• 迁移如果是用自动化账号（比如服务主体）执行的，而你用自己的账号登SSMS/ADS，要确认表是不是建在你有权限查看的架构下。比如自动化账号默认用dbo，但你的账号没dbo的访问权限，自然看不到表。
• 给自动化账号加db_owner权限（或者至少是创建表、修改架构的权限），同时确保你登录的账号对目标架构有SELECT和VIEW DEFINITION权限。

3. 别信表面日志，查迁移真的成功没 #

• 翻GitHub Actions的完整日志，别只看“已创建表”的提示，找迁移步骤的详细输出——说不定有隐藏的错误（比如超时、约束冲突）导致迁移回滚了，但日志只显示了开始执行的信息。
• 直接在Azure SQL里跑查询确认表是否存在：

  SELECT name FROM sys.tables WHERE schema_id = SCHEMA_ID('dbo'); -- 换成你的架构名
  

  如果查不到，说明迁移根本没成功，日志是假的。

4. 确认迁移工件被正确发布 #

• 检查CI/CD流程里有没有包含Migrations文件夹的文件——如果迁移类没进发布包，应用找不到历史迁移记录，每次构建都会重新跑初始迁移。
• 看项目的.csproj文件，确保Migrations文件夹的Build Action是Content：

  <ItemGroup>
    <Content Include="Migrations\**" />
  </ItemGroup>
  

5. 注意Blazor WASM不能在客户端执行迁移 #

• Blazor WASM是纯客户端应用，根本没法直接连Azure SQL执行迁移！如果你的迁移逻辑写在客户端项目里，那完全是错的——迁移要么放在配套的ASP.NET Core Web API项目里，要么在CI/CD流程里单独跑dotnet ef database update命令。
• 确认GitHub Actions里的迁移步骤是对着服务器端项目执行的，用的是正确的连接串。要是在客户端项目跑迁移，日志里的“创建”提示根本没用，客户端连不上数据库。

内容的提问来源于stack exchange，提问作者David.Warwick