Hibernate Search 6 在双向关联中仅更新一端时，因 @IndexedEmbedded 关联未同步，导致新增子实体（如 TableRow）不触发父实体（TableDoc）的完整索引重建，从而无法搜索新字段值。
hibernate search 6 在双向关联中仅更新一端时，因 `@indexedembedded` 关联未同步，导致新增子实体（如 `tablerow`）不触发父实体（`tabledoc`）的完整索引重建，从而无法搜索新字段值。
在使用 Hibernate Search 6（基于 Lucene）构建全文检索能力时，一个常见却容易被忽视的问题是：新增子实体后，其被 @IndexedEmbedded 嵌入的字段无法被检索到。这并非框架 Bug，而是由 JPA 关联管理与 Hibernate Search 索引触发机制共同决定的行为。
核心原因在于：Hibernate Search 的索引更新依赖于被 @Indexed 标记的实体及其关联对象的状态变化。当您调用 tableRowRepository.save(tableRow) 创建新的 TableRow 时，虽然数据库持久化成功，但若未显式维护双向关联——即未将该 TableRow 添加到其所属 TableDoc 的 tableRows 集合中——那么在后续对 TableDoc 进行索引（或重新索引）时，@IndexedEmbedded 将无法“看到”这个新加入的子对象，自然也不会将其 cellValues 字段纳入索引文档。
对比您的 update 方法可发现关键差异：更新操作中，TableRow 已存在于 TableDoc.tableRows 集合中（因此前已加载并关联），因此修改 cellValues 后，TableDoc 的嵌入索引会被正确刷新；而 create 方法仅保存了子实体，却未同步父集合，造成索引视图与数据状态不一致。
✅ 正确做法是在保存前手动维护双向关联：
public TableRow create(TableRow tableRow) {
// ✅ 关键修复：确保父实体的关联集合包含新子实体
TableDoc tableDoc = tableRow.getTableDoc();
if (tableDoc != null && tableRow.getTableDoc().getTableRows() != null) {
tableRow.getTableDoc().getTableRows().add(tableRow);
}
return tableRowRepository.save(tableRow);
}⚠️ 注意事项：
- 此修复必须在 save() 调用之前执行，否则 @PreUpdate/@PostPersist 等生命周期回调可能已错过索引时机；
- 若使用 CascadeType.PERSIST，仍需确保内存中关联一致——级联仅影响持久化行为，不影响 Search 的索引决策；
- 推荐在 TableDoc 的 addTableRow() 辅助方法中封装此逻辑，提升可维护性与一致性；
- 避免在 TableRow 构造器或 setter 中反向操作 TableDoc（易引发循环引用或 NPE），应在业务层统一协调。
? 总结：Hibernate Search 不会“主动探测”数据库变更，它严格基于当前 Session 中托管实体的内存状态生成索引。因此，JPA 关联的完整性 = 搜索索引的完整性。始终遵循“双向关联，双向维护”原则，才能让 @IndexedEmbedded 发挥预期作用。
