首先可以明确说：这种通过setManagedTypes()指定单个实体类而非扫描整个包的方式，是Spring官方认可的合法方案——从你贴出的LocalContainerEntityManagerFactoryBean.setManagedTypes的Javadoc就能看出来，它本身就是作为实体扫描的替代方案被设计出来的，完全不存在“不被支持”的问题。

不过针对你担心的维护成本和功能遗漏风险，确实有几个需要注意的点：

一、潜在的维护与兼容性问题 #

1. 手动维护实体列表的繁琐度
   每次新增需要被管理的实体类，你都得手动把它添加到PersistenceManagedTypes的列表里，不像@EntityScan那样把类丢到指定包就自动生效。在团队协作场景下，新人很容易忽略这个规则，导致新增实体不被JPA管理，引发奇怪的持久化问题。

2. Spring Boot版本升级的兼容性风险
   你现在手动接管了EntityManagerFactory的创建，而这个Bean是Spring Boot JPA自动配置的核心组件。后续Spring Boot版本升级时，官方可能会调整这个Bean的默认配置逻辑（比如新增默认绑定的配置项、优化与其他组件的联动逻辑），你需要自己跟进这些变化，确保手动配置的Bean能覆盖这些默认行为，否则可能出现兼容性问题。

二、容易踩的功能遗漏坑 #

Spring Boot的@EntityScan背后做了很多隐式的联动工作，手动配置EntityManagerFactory时很容易遗漏这些细节：

• 配置属性的绑定：原本Spring Boot会自动把application.properties/yml里的JPA相关配置（比如spring.jpa.hibernate.ddl-auto、spring.jpa.properties.hibernate.dialect）绑定到EntityManagerFactory上，你手动创建Bean时，需要自己通过setJpaProperties()或者setJpaPropertyMap()把这些配置传进去，否则这些配置会完全失效。
• 与Spring Data JPA的联动：@EntityScan和@EnableJpaRepositories是默认联动的，手动配置时要确保实体类和对应的Repository能正确关联，比如Repository的domainClass能被正确识别。
• 高级特性的集成：如果用了Spring Data JPA的审计（@CreatedDate、@LastModifiedDate）、实体监听器、多数据源等特性，要确认手动配置的EntityManagerFactory已经正确集成了这些功能，避免特性悄无声息地失效。

三、一些优化建议 #

如果你决定采用这种方式，可以做一些优化来降低风险：

• 把需要管理的实体类列表抽离成一个单独的配置类或者甚至通过外部配置文件维护，减少硬编码的维护成本；
• 可以结合Spring的条件配置（@Conditional系列注解），在不同环境下加载不同的实体类，这反而能成为这种方式的优势——精准控制不同环境的实体范围；
• 如果你只是想避免扫描过大的包，其实@EntityScan的basePackageClasses参数可以作为折中：传入某个实体类，Spring会扫描该类所在的包，但这本质还是扫描包，不是单个类，适合实体类相对集中的场景。

最后说一句 #

你找不到相关资料的核心原因是：这种精准指定单个实体类的场景太小众了——大部分项目都会按业务模块组织实体类，扫描整个包是更符合常规开发习惯的做法，所以相关讨论自然少，但这完全不代表这种方式有技术问题。

只要你能接受手动维护实体列表的繁琐，并且仔细核对EntityManagerFactory的配置没有遗漏Spring Boot自动配置的关键项，这种方式是完全可以在生产环境使用的。

备注：内容来源于stack exchange，提问作者franok