这种情况我之前处理过好几次，结合SQL Server 2016和Hibernate的特性，给你几个逐步排查的方向：

1. 确认实体类的架构指定是否正确 #

Hibernate默认会使用数据库的默认架构（通常是dbo），如果你的表在非默认架构下，必须在实体类的@Table注解中明确指定schema属性：

@Table(name = "your_table_name", schema = "your_schema_name")
public class YourEntity {
    // ...
    @Column(name = "claim_number", nullable = true, length = 30)
    private String claimNumber;
}

如果需要操作两个架构下的同结构表，你要么为每个架构创建对应的实体类，要么通过动态切换架构的方式处理——否则Hibernate可能访问了未修改的默认架构下的表，自然找不到新增列。

2. 清除Hibernate的元数据缓存 #

Hibernate会缓存数据库表的元数据，哪怕你已经修改了表结构，缓存可能还停留在旧状态。可以尝试：

• 直接重启应用，彻底清空内存中的缓存
• 开发环境临时开启hibernate.hbm2ddl.auto=validate，让Hibernate启动时自动验证实体与表结构的一致性（生产环境不建议长期开启）
• 若使用了二级缓存，手动调用sessionFactory.getCache().evictAll()清空缓存

3. 验证SQL Server中列的存在性 #

虽然你说已经添加了列，但最好用SQL语句确认，避免手动操作时的疏漏：

-- 替换为你的架构和表名
SELECT name 
FROM sys.columns 
WHERE object_id = OBJECT_ID('your_schema.your_table') 
AND name = 'claim_number';

如果查询无结果，说明列确实没添加成功，或者架构/表名写错了；如果能查到，再检查列名大小写（SQL Server默认不区分大小写，但如果数据库设置了大小写敏感，需要完全匹配）。

4. 查看Hibernate生成的实际SQL #

开启Hibernate的SQL日志，看看它实际生成的插入语句是什么，这能直接定位问题：

• 若用Log4j/Logback，把org.hibernate.SQL的日志级别设为DEBUG
• 查看日志中的INSERT语句，确认是否包含claim_number列，以及访问的表是否属于正确的架构

比如日志中如果出现：

insert into dbo.your_table (...) values (...)

这里用了dbo而非你修改的架构，那就是架构指定的问题。

5. 检查数据库用户的权限 #

连接数据库的用户可能没有访问目标架构或新增列的权限，导致查询时提示列不存在。可以用该用户执行测试语句：

-- 测试是否能访问目标列
SELECT claim_number FROM your_schema.your_table WHERE 1=0;

如果执行报错，说明权限不足，需要给用户分配对应架构的访问权限或列的权限。

6. 排查命名策略的影响 #

如果项目配置了Hibernate的全局命名策略（比如spring.jpa.hibernate.naming.physical-strategy），可能会自动转换列名。比如命名策略设置错误的话，可能会把claim_number转换成claimnumber这类不符合预期的格式。可以检查配置文件中的命名策略设置，确保它不会修改你指定的列名。

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