首先，让我表达一些一般性的想法：
它基本上取决于您的基线是什么，何时更改列，在哪里维护这样的更改以及代码中所做的更改如何传播到实际数据库。由于代码通常是“静态的”，并且及时表示项目的状态，因此您可能需要部署了以前版本的代码的外部数据库进行比较。这通常会使测试复杂化，因为测试通常需要检查当前版本代码的功能，而不是将其与以前的版本进行比较。
所以我会考虑不把这样的检查作为测试来实现，而是作为一个可以在构建过程中运行的外部验证工具（比如在CI中）。如果这个工具失败了怎么办？好吧，有人确实改变了专栏，那又怎样？整个建筑会失败吗？如果是，项目将如何发展？在所有的数据库更改发生后，可能有很好的理由...
所以，假设你仍然想实现这样一个工具，请继续阅读：
一种方法是维护迁移，像Flyway和Liquibase这样的工具可以帮助解决这个问题。
这个想法是，每个更改都将通过特殊的“迁移”脚本/文件记录在代码中。例如，在Flyway中，db中有一个特殊的表，其中包含已应用的迁移的状态，因此您可以在测试中查询它，并查看是否有更新的迁移要应用（例如，每次迁移都会更改db模式）。
另一种方法是例如在实体注解中使用HibernateMap。在这种情况下，您可以尝试检查当前Map是否可以应用于当前数据库状态（其称为Map验证）：从技术上讲，有一个属性hibernate.hbm2ddl.auto可以设置为validate（阅读this question了解更多细节）
我想到的最后一个可能的选项概念是：比较两个模式的元数据：一个基线（预先准备好的--这是你用来验证Map的基线）--查询它的元数据（表，列名，索引，约束，任何你需要的）然后创建一个“样本模式”，我们的hibernateMap（如果可能的话，你可能想为db使用测试容器）或者甚至是真实的数据库来创建一个“模拟”模式。现在查询这个新模式的元数据，并与第一个“基线”模式进行比较。可能它会使用一些自定义的解决方案，因为你最终会与一些自定义检查迟早（这个变化是好的，但变化是不是），我相信..