集合已查到，Gson 序列化为什么仍报 LazyInitializationException

服务已经查出 List<CustomerInfo>，普通字段也能读取，调用 Gson 序列化时却报 Customer.customerInfoList 的 LazyInitializationException: ... no Session。先沿报错中的关联路径检查：查到这份列表，不代表列表中每个实体指向的关联都已初始化。

CustomerInfo 可能仍有 customer 引用，那个 Customer 又有惰性的 customerInfoList。序列化继续遍历这条对象图时，触碰了没有加载且已脱离持久化上下文的集合。根对象能打印或第一层查询成功，不能证明整张图都能在事务结束后安全遍历。

对照报错的 role 与真正交给 Gson 的对象

检查传给 toJson 的实际对象及其字段，特别是 List<?>、Object 或 DTO 中保存的实体引用。名为 Request 的包装类里装着实体列表，仍然会把实体对象图带到序列化阶段。

不要为了排查在会话外到处调用 toString()、集合 size() 或关联 getter。调试器、日志或 Lombok 生成的方法也可能触发关联遍历，改变异常首次出现的位置。先看类型与字段路径，再在受控环境检查所需关联是否已加载。

Hibernate 的惰性关联需要与仍可用的持久化上下文关联，才有条件加载。返回实体之后再调用 Hibernate.initialize()，不会重新打开已经结束的 Session；只初始化一个集合，也不会保证所有反向和嵌套关联都被递归加载。

在有效事务内整理返回数据

仅用于输出的接口，可以在已有的、真实生效的事务内查询所需字段，转换成不含实体引用的 DTO，再交给 Gson。下面只是输出结构示例，getter 名称需对应实际模型：

public record InfoView(String metaKey, String metaValue) {}

List<InfoView> output = infos.stream()
    .map(info -> new InfoView(info.getMetaKey(), info.getMetaValue()))
    .toList();

这段使用 Java 17 可用的写法，并要求 Gson 支持 record；原生支持从 Gson 2.10 起提供。它不包含查询和事务入口。映射应发生在能够读取这些字段的持久化上下文内；InfoView 只保存这里需要的值，没有把 CustomerInfo 或 Customer 放进去。业务需要其他字段时明确增加，不要复制整张实体图。

如果需要客户名称，先按查询计划取得它，再复制成 DTO 字段。仅把实体换个包装类，或者 DTO 里仍放 customer，不能解决会话外遍历的问题。也要保留原来的字段授权，避免转换时把不应返回的值一并输出。

查询计划只加载这次真正需要的关联

需要关联数据时，可以按实际查询选择 fetch join、投影或 EntityGraph，再在事务内完成映射。不要统一把所有关系改成 EAGER；它会影响其他使用这些实体的查询，也不保证采用某一种固定 SQL 形态。

Spring Data JPA 的临时 EntityGraph 使用 attributePaths 表达属性路径。例如：

@EntityGraph(attributePaths = "customerInfoList")
Customer findBySessionId(String sessionId);

这里假设仓储方法确实查询 Customer，且该属性存在。@EntityGraph("customerInfoList") 的字符串则是命名图引用，不能在没有对应定义时当成属性路径的同义写法。加载这一项，也不等于可以任意遍历它下面的其他关联。

如果预期的 Service 事务没有生效，应另查实际代理调用和事务管理器；同类内部调用的边界可对照事务代理调用路径。但已经生效的事务在返回后结束，同样不保证后续 Gson 遍历安全。

用关闭会话后的输出验证边界

在与正式部署一致的 Open EntityManager in View 设置下验证原入口。确认返回对象仅含预期字段，离开服务事务后仍能序列化，且不会因为序列化或日志额外访问数据库。

同时核对查询数量、结果完整性和循环引用。开启 open-in-view 可能把加载延后到 Web 请求期间，它并没有消除隐含查询；需要采用时应明确评估，而不是用它掩盖对象图设计。

修改前保存查询和输出契约。若 DTO 改变了字段结构，应协调接口兼容与回退；消除异常不应以丢失业务必需字段或暴露额外实体字段为代价。