1. 为什么把图数据库接进SpringBoot这么让人挠头先交代一下背景。我在上一个系列里写了Neo4j的基础概念和Cypher查询入门不少朋友私信问我东西看明白了但项目里到底怎么用尤其是一个正经的业务系统怎么把图数据库和现有的SpringBoot服务结合起来总不能每个地方都自己拼Cypher字符串吧。这个问题确实值得单独写一篇。因为Neo4j的Java驱动和SpringBoot的整合方式跟咱们平时用MySQL、Redis完全不是一个套路。你拿MP那套思维去写Neo4j的Repository基本写不动但你要是理解了它的对象映射逻辑又会觉得真香——特别是做知识图谱、关系推荐、权限血缘这类场景Neo4j能把代码量砍掉一大半。这篇文章我从头到尾走一遍完整流程Neo4j服务端怎么准备、SpringBoot工程的依赖和配置怎么写、实体映射和Repository怎么设计、从单节点出发的多条路径查询怎么做以及我在真实项目里踩过的几个坑。末尾附一个频发的报错排查清单照着抄就行。这个方案适合谁正在做毕设、准备知识图谱相关项目、或者想把推荐/风控逻辑落到图模型的读者。我已经默认你掌握SpringBoot的基础用法用过JPA或者MP中的任意一种对Cypher有最基本的增删改查概念。2. Neo4j服务端准备社区版和桌面版怎么选数据放哪正式开始写代码之前得先把数据库服务跑起来。这一趴看着简单实际翻车率极高我见过太多人卡在“浏览器能打开、Spring连接报错”这个怪圈里。2.1 版本选择与安装方式的取舍Neo4j现在的版本号已经到5.x了主流选择是Community Server和Desktop两个形态。我个人建议本地开发用Desktop最省心因为它自带数据库管理界面、内置了浏览器客户端你不需要额外折腾Java环境变量。但你如果准备部署到服务器或者Docker里跑那就直接用Server包。这里有个重要的细节桌面版默认创建的数据库虽然是本地文件但它的bolt端口默认是7687HTTP端口7474这两个端口在SpringBoot配置里要精确对应。有人习惯性照抄网上的配置端口写错一位连接超时折腾一整晚。下载的话去官网的下载页选Community Server那个tar.gz或者zip包。Windows用户注意解压之后直接运行bin目录下的neo4j.bat是不行的先得执行neo4j.bat install-service把Windows服务装上再执行neo4j.bat start。Mac和Linux就简单得多直接bin/neo4j start。2.2 启动后的初始化与账号设置服务启动之后浏览器打开http://localhost:7474第一次会让你修改密码。默认账号是neo4j初始密码是首次启动时终端自动生成的那串随机字符不是网上教程里写的neo4j——老版本是固定初始密码新版本早改成随机生成了这一点坑了无数人。密码设置好之后建议顺手在浏览器里跑一条:RETURN 1 AS test能看到结果就说明服务端没问题。记一下自己设置的密码后面SpringBoot配置要用。还有一个容易被忽略的点Neo4j的数据文件默认放在data目录下如果你后面要迁移数据或者备份直接打包这个目录就行比MySQL的dump逻辑还简单粗暴。生产环境上面建议把dbms.memory.heap.initial_size这类参数写进配置文件开发环境默认就行不用折腾。3. SpringBoot工程集成依赖版本、连接配置、自动装配的三个关键点服务端起来了现在开始搭工程。我用的是SpringBoot 2.7.18 Neo4j 5.x的组合这个搭配是我目前实测最稳的。如果你用的是SpringBoot 3.x下面配置里的依赖坐标不变但javax包名要换成jakarta这个后面细说。3.1 依赖导入与版本冲突避坑项目里引入依赖核心就两个spring-boot-starter-data-neo4j以及neo4j-java-driver。前一个是Spring Data对Neo4j的封装后一个是官方驱动。dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-data-neo4j/artifactId /dependency dependency groupIdorg.neo4j.driver/groupId artifactIdneo4j-java-driver/artifactId /dependency版本号不用写SpringBoot的依赖管理会帮你匹配。但我强烈建议你确认一下自己SpringBoot版本对应的Neo4j驱动版本办法很简单看spring-boot-dependencies这个BOM里neo4j-java-driver的版本号然后去Neo4j官方文档查这个驱动兼容哪些服务端版本。这里最容易出的问题是SpringBoot 2.7默认管理的驱动版本是4.x你服务端装的是Neo4j 5.x虽然大多数功能能跑但某些5.x新增的Cypher语法会直接报语法错误。解决办法也很粗暴——单独指定驱动版本用新的。dependency groupIdorg.neo4j.driver/groupId artifactIdneo4j-java-driver/artifactId version5.13.0/version /dependency踩过这个坑之后我养成了个习惯每次新建这类整合项目先去mvnrepository把依赖的版本树看一遍别全指望BOM。3.2 application.yml配置项解析与动态库名接下来是配置文件。Neo4j的SpringBoot配置和其他数据源长得很不一样没有url和username连在一起的jdbc串而是分散的几个独立属性。spring: data: neo4j: uri: bolt://localhost:7687 username: neo4j password: your-password这三个属性是最基本的。如果你用的Neo4j是单实例开发模式写这些就够了。但有个细节spring.data.neo4j.uri支持bolt和neo4j两种协议前缀前者是纯二进制协议后者会自动做路由选择。开发环境用bolt就行生产如果有集群换成neo4j://前缀更好。另外一个很容易忽视的参数是数据库名。Neo4j默认的库名是neo4j如果你配置了多数据库企业版特性需要这么指定spring: data: neo4j: database: neo4j这个配置不写也不会报错默认就是neo4j库。但你在公司项目里如果用了AOP切面动态切换库这个字段就有用了。我建议显式写出来为了可读性也为了后面排查问题方便。3.3 验证连接用CommandLineRunner做启动自检配置写完之后别急着写实体先做一次连接验证。新建一个启动类里加个CommandLineRunner启动时跑个最简单的查询能立刻发现配置问题比等第一次调用接口报错要快很多。Component public class Neo4jConnectionChecker implements CommandLineRunner { private final Driver driver; public Neo4jConnectionChecker(Driver driver) { this.driver driver; } Override public void run(String... args) { try (Session session driver.session()) { var result session.run(RETURN 1 AS test); if (result.hasNext()) { System.out.println(Neo4j连接成功); } } catch (Exception e) { System.err.println(Neo4j连接失败: e.getMessage()); } } }注意这里直接注入了Driver对象说明SpringBoot的自动装配已经生效了。如果启动报错说找不到Driver这个Bean多半是starter依赖没引进来或者是SpringBoot版本跟驱动版本冲突导致自动配置被跳过。4. 实体建模与Repository设计图模型和关系型到底差在哪连接跑通了接下来是最核心的部分怎么把图里的节点和关系映射成Java对象。这一节是整个整合的灵魂因为Neo4j的实体映射逻辑跟JPA完全不同理解对了后面写查询就是水到渠成。4.1 Node注解与属性映射规则先看一个完整的实体定义。拿电影评分这个场景来说——这也是网上面试高频题某电影网站需要支持查看某个演员演过的所有电影、每部电影的导演和平均分这样一个典型的三层关系模型。Node(Movie) public class MovieEntity { Id GeneratedValue private Long id; Property(title) private String title; Property(released) private Integer released; Property(rating) private Double rating; // 构造函数、getter、setter省略 }这个类映射的是图里的一个Movie节点label是Movie。Node(Movie)里的字符串对应节点的label不写的话默认用类名。Id GeneratedValue是Neo4j自动生成内部ID注意这个ID是数据库内部维护的不是你业务里的主键。Property注解可以不写不写的情况下默认把驼峰属性名转成节点属性名——JPA也是这个套路。但我建议显式写出来因为图数据库的属性命名习惯是下划线风格snake_case你跟别人对接存量数据时属性名对不上就会查出全是null。4.2 Relationship关系是有方向的别写成双向关系是图数据库区别关系型数据库的关键。在Spring Data Neo4j里关系用Relationship注解表达。还是以电影三层模型为例Node(Person) public class PersonEntity { Id GeneratedValue private Long id; Property(name) private String name; Relationship(type ACTED_IN, direction Relationship.Direction.OUTGOING) private ListMovieEntity actedIn; Relationship(type DIRECTED, direction Relationship.Direction.OUTGOING) private ListMovieEntity directed; // 构造函数、getter、setter省略 }这里有两个点必须说清楚。第一关系类型type是必须的它对应Cypher里的-[r:ACTED_IN]-这个箭头上的类型名。第二direction方向是必须的——图里的关系天生有方向OUTGOING表示从这个节点指出去INCOMING表示别人指向它。很多人第一次写的时候会想既然关系是双向的那我是不是两边都得注解上答案是不用。你在Person里写了ACTED_IN指向Movie那Movie那边通常不需要再维护一个ListPersonEntity actors反向引用。就算需要也要在两边的实体里分别定义而不是依赖框架自动补全。我实际项目里的习惯是从查询频率高的一侧定义关系属性另一侧需要的时候再补永远不要让两侧同时维护同一个关系集合——那样序列化的时候会死循环这个坑后面专门讲。4.3 Repository接口SDN的查询方法命名规则与Query自定义查询Spring Data Neo4j的Repository接口写法和JPA极为相似核心接口是Neo4jRepositoryT, ID。如果你的查询方法能通过方法名推导框架会自动生成Cypher。public interface MovieRepository extends Neo4jRepositoryMovieEntity, Long { ListMovieEntity findByTitle(String title); ListMovieEntity findByReleasedGreaterThan(Integer year); ListMovieEntity findByActorsName(String actorName); }第三个方法名findByActorsName框架会自动理解成先找到所有ACTED_IN关系的目标节点再按目标节点的name属性过滤。这个能力很强大但有个前提——你的实体关系映射要跟图里的结构完全对应稍微差一点就推导不出来。复杂查询就不要硬靠方法名了直接上Query注解写Cypher更痛快public interface MovieRepository extends Neo4jRepositoryMovieEntity, Long { Query(MATCH (p:Person)-[r:ACTED_IN]-(m:Movie) WHERE p.name $actorName RETURN m ORDER BY m.rating DESC LIMIT 10) ListMovieEntity findTop10MoviesByActor(Param(actorName) String actorName); }注意几个用法$actorName是参数占位符对应Param(actorName)Cypher里的大小写敏感Person、Movie这些label必须跟实体里Node定义完全一致差一个字母直接查不到数据。4.4 评分和评论的ER图怎么画图模型设计三要素热搜词里有一条“画出电影评分与评价的er图”这里顺带把这题解了。关系型里你会画三张表电影表、用户表、评分表评分表外键关联电影和用户。图数据库里没有“中间表”这个概念评分本身有两种建模方法。第一种评分作为关系上的属性。(:User)-[:RATED {score: 8.5, comment: 好看}]-(:Movie)这种建模适合只想存简单数值评分的场景借助关系的属性承载分数和评论内容。第二种评论作为独立的节点。(:User)-[:WROTE]-(:Review {content: ..., score: 8.5})-[:REVIEWS]-(:Movie)这种建模适合需要单独管理评论的场景比如按时间排序、点赞、审核状态等。ER图画法跟关系型完全不同——节点就是实体边就是关系没有第三张表的事。我给的建模建议很简单如果你只在查询的时候关心评分那就用关系属性如果评论本身有独立的业务生命周期审核、修改、删除那就建独立节点。图模型不要过早设计得太细致边建边改图数据库的变更成本比关系型低得多——改一条关系的type一行Cypher的事不用跑SQL迁移脚本。5. 从一个节点出发的多条路径查询可变长度关系与联合匹配这是热搜词里“neo4j查询从一个节点出发如何查询多条”对应的核心知识点。很多人在这一步卡住是因为习惯了关系型数据库join那套思维不会用路径的视角思考。这一节我把三种最常见的“多路径”场景全过一遍。5.1 场景一一个节点向外查两层过滤中间层属性需求已知演员A找出他演过的所有电影再找出这些电影的导演。这是从一个节点出发的两条路径。MATCH (p:Person {name: $actorName})-[:ACTED_IN]-(m:Movie)-[:DIRECTED]-(d:Person) RETURN m.title AS movieTitle, d.name AS directorName这里用的是同一条路径里的多段匹配。MATCH后面的链式结构里(p:Person)-[:ACTED_IN]-(m:Movie)和(m:Movie)-[:DIRECTED]-(d:Person)两段靠共享变量m连接起来。对应Spring Data里的写法Query(MATCH (p:Person {name: $actorName})-[:ACTED_IN]-(m:Movie)-[:DIRECTED]-(d:Person) RETURN m.title AS movieTitle, d.name AS directorName) ListMapString, Object findActorMovieAndDirector(Param(actorName) String actorName);返回值直接用ListMapString, Object接收就行不非要套实体类。这种场景在推荐系统里极其常见——根据用户看过的电影推荐相似风格的电影本质就是两步路径的扩展。5.2 场景二同一个节点分支出去的两条独立路径需求查演员A的所有电影和演员A的所有社交粉丝。这两条路径之间没有交点。MATCH (p:Person {name: $actorName})-[:ACTED_IN]-(m:Movie) MATCH (p)-[:FOLLOWED_BY]-(f:Person) RETURN collect(DISTINCT m.title) AS movies, collect(DISTINCT f.name) AS followers注意这里用了两个独立的MATCH而不是在一条链上串起来。因为两个路径之间没有交集节点硬串会导致笛卡尔积——所有电影和所有粉丝两两组合数据量分钟级膨胀。在Neo4j里写多个MATCH时脑子里一定要有个意识单条MATCH是过滤逻辑多条MATCH是拼接逻辑别把过滤条件和拼接条件混在一起。5.3 场景三可变长度路径深度不确定的递归查询需求查从某个员工出发所有多级下级的组织树。这个在权限体系和组织架构里是刚需。MATCH (e:Employee {empNo: $empNo})-[:REPORTS_TO*1..5]-(sub:Employee) RETURN sub.name AS subordinateName, length(relationships(p)) AS depth*1..5是可变长度关系的语法表示一到五层。这个写法的性能开销随着深度增加会指数级增长生产环境慎用。我在实际项目里通常限制深度最大为3再深就批量查询或者用路径规划算法了。Spring Data里的调用方式和前面一样参数传进来即可。可变长度路径返回的结果需要自己处理树的层级结构框架不会帮你组装父子关系——这里建议在Service层用HashMap做一次分组归并。5.4 多个查询条件组合时避免Cypher注入的技巧最后一个开发层面的细节用Query写动态条件时不要字符串拼接。// 错误示范 Query(MATCH (m:Movie) WHERE m.released year RETURN m) // 正确示范 Query(MATCH (m:Movie) WHERE m.released $year RETURN m)Cypher的注入风险和SQL一模一样。Spring Data Neo4j提供了参数绑定机制$year这种语法就能把参数安全地传进去。这是我见过最常见的安全隐患尤其是从别的体系转过来的人习惯了用拼条件。提示所有用户可输入的查询关键字一律使用参数绑定不要拼接。图数据库通常承载的是企业核心关系数据一旦被注入攻击损失比关系型更严重。6. 事务边界与懒加载SDN里最容易翻车的两个机制这一节是给那些已经跑通增删改查、开始上复杂业务的人看的。事务和懒加载这两个机制用不明白会很痛苦项目一复杂就各种莫名其妙的异常。6.1 事务注解的语义和边界Neo4j的事务模型跟MySQL有很大区别但Spring的Transactional注解用法基本一致。SDN里的写操作都需要事务Service层方法上加上注解即可。Service public class MovieService { Transactional public void createMovieWithActor(MovieEntity movie, PersonEntity actor) { movieRepo.save(movie); actorRepo.save(actor); // 如果这两步之间抛异常两个节点都不会保存 } }关键区别在于Neo4j的写事务要求所有写操作在一个会话里完成Spring Data Neo4j的Repository事务继承了这一特性。你如果在同一个事务里先存了Movie再存Person框架会确保两个节点在同一个物理事务里要么同时成功要么同时回滚。有个性能相关的点值得注意Neo4j是单写入架构同时只能有一个写事务在线写并发高了会有排队等待。Transactional就不要乱加在那些只读查询方法上了能不加就不加——它能显著减少锁等待和死锁的概率。6.2 懒加载引发的LazyReferenceExceptionSDN默认的关系集合是懒加载的。也就是说加载一个PersonEntity时他关联的ListMovieEntity并不会立刻查出来只有你代码里访问personEntity.getActedIn()时才会触发一次懒加载查询。这个设计能显著提升查询速度但有个大坑当实体从Repository返回走到Service层再传到Controller层序列化时如果JSON序列化发生在事务之外访问懒加载属性就会抛LazyReferenceException。我之前的解决思路是这样的RestController public class PersonController { GetMapping(/person/{id}) public PersonEntity getPerson(PathVariable Long id) { PersonEntity person personService.getWithRelations(id); // 在Service里已经访问过actedIn强制完成了加载 person.getActedIn().size(); return person; } }在Service层强制访问一次集合触发懒加载后续JSON序列化时数据已经在内存里了。这个方案丑但稳定比配置全局懒加载开关要安全得多——全局关掉懒加载等于每次查询都把整张图拉出来性能直接雪崩。6.3 Jackson序列化循环引用的经典报错这是关系型转过来的人必踩的坑而且报错信息特别唬人org.springframework.http.converter.HttpMessageNotWritableException: Could not write JSON: Infinite recursion (StackOverflowError)场景是这样的你在MovieEntity里也加了ListPersonEntity actors反向引用同时PersonEntity里有ListMovieEntity actedIn。Jackson序列化的时候从Person进去访问actedIn每个Movie又访问actors每个actor又进去访问actedIn……无限循环。两种解决思路第一种在一侧的反向引用字段上标注忽略JsonIgnore private ListMovieEntity actors;第二种在DTO层手动组装视图对象不直接把实体返回前端。我用的是第二种理由很简单实体是给持久层用的DTO是给前端用的混在一起迟早要出事。你不想在一个字段级别来回纠结序列化配置的话就老老实实建DTO。7. 踩坑实录连接失败、驱动冲突、类型转换排查思路全记录这一节是我把踩过的坑和帮别人排查过的坑汇总起来每条都配上现象、原因、解决步骤。按照从高到低的频率排序。7.1 浏览器能打开Neo4jSpringBoot连不上这个排在我个人避坑榜单的第一名出现频率高得离谱。现象浏览器打开7474完全正常但SpringBoot启动时Unable to create session或者连接超时。排查步骤我都写得比较详细照着走一遍先看Neo4j日志里的bolt端口有没有变化。新版Neo4j支持在配置里同时开多个bolt端口你浏览器用的是HTTP端口7474SpringBoot用的bolt端口7687两个端口是独立的。如果本机7687被别的服务占了Neo4j可能会把bolt端口改成7688之类的日志里会显示。再看防火墙。服务器上部署时阿里云/腾讯云的安全组默认只开放了80/443/22/3389这些端口7687不在默认放行列表里需要在安全组手动放行。最后看配置文件里的uri是不是bolt开头的有人的拼成了bolt:http://localhost:7687这种格式驱动解析不了直接抛异常。7.2 版本不匹配导致的Cypher语法错误现象比较迷惑一部分Cypher能跑一部分报语法错误比如Unknown function point.distance这类。原因基本都是驱动版本和服务端版本差距太大。Neo4j 4.x的驱动连接Neo4j 5.x的服务端很多新函数识别不了。解决办法就是前面说的在pom里显式指定更高的驱动版本。排查版本问题最快的方式是看驱动包里的META-INF版本信息别靠猜。7.3 NaN和double精度导致的关系属性查不出来这个坑比较冷门但遇到了会怀疑人生。场景给评分rating存了Double类型数据库里看着是8.5但查询WHERE m.rating 8.0就是查不出来。原因Java的Double序列化到Neo4j后可能带浮点误差8.5在数据库里存成8.499999999或者8.500000001的情况很常见。解决办法有两个第一图里的数值属性尽量用Integer/Integer类型评分这种数据放大十倍存成85查询时除以10第二实在要存Double查询条件就别用精确比较用范围区间m.rating 8.0 AND m.rating 8.6。7.4 SDN自动生成的密码加密策略变了如果你是升级到Spring Boot 2.7.x之后出现了The authentication scheme is not enabled可以检查一下Neo4j服务端的认证方式。新版本默认用basic认证老配置里可能写的是none或者kerberos。在Neo4j配置文件里把dbms.security.auth_enabled设为true重启即可。7.5 中文数据存储乱码Neo4j默认的字符集就是UTF-8但有些环境变量或者Java默认编码设置会导致中文乱码。SpringBoot这边配置里显式设置server: servlet: encoding: charset: UTF-8 force: true同时在Neo4j的配置文件里设置server.default_databaseneo4j的编码参数基本能解决九成的乱码问题。还有一个隐蔽原因JDBC驱动和Neo4j驱动混用时连接串的编码参数不一致导致中文字段从MySQL同步过来就乱了如果是数据同步场景优先检查源头编码。8. 性能调优与最佳实践这些坑我在生产环境里才真正想明白最后一部分聊点进阶的关于图数据库在SpringBoot项目里的性能优化设计思路。这些内容我在开发环境里也没意识到直到压测和生产遇到问题才一条条验证出来。8.1 Cypher查询的profiling思路Neo4j自带查询计划分析在浏览器里可以执行EXPLAIN和PROFILE查看执行计划。这在排查慢查询时很管用——PROFILE会给出实际行数和数据库命中数。我要提醒你一个很关键的认知转变图数据库没有“索引失效”这个说法的直觉但同样有“未走索引”的情况。Cypher里如果对节点的某个属性做了过滤就应该给这个属性建索引CREATE INDEX FOR (p:Person) ON (p.name);索引不建全图扫描就是慢。这在SDN实体里没有直接对应的注解需要单独执行Cypher来建索引——或者放在初始化脚本里。我习惯在项目启动时通过CommandLineRunner执行建索引语句避免上线后手动补。8.2 批量保存与分页查询的取舍SDN的Repository提供了saveAll批量保存但Neo4j的批量写入主要是靠UNWIND不是循环调save。大批量导入数据时一条UNWIND语句比一万次save高效一个数量级以上UNWIND $dataList AS row MERGE (p:Person {name: row.name}) MERGE (m:Movie {title: row.title}) MERGE (p)-[:ACTED_IN]-(m)代码里把数据组装成List通过参数传进去即可。分页查询建议用Pageable参数配合Repository接口但深翻页时性能会急剧下降图数据库的深翻页尤其严重——跳过多层关系时聚合计算量极大我一般做数据导出时会限制最大翻页深度。8.3 图数据库不是万能的什么时候不适合把业务耦合进来最后说一个容易被热血上头的观点绑架的问题。我看到很多初学者把所有关系全塞进图数据库包括那些天然就是关系型结构的流水账数据。这种设计很危险。判断标准很简单如果一条记录只被自己所属的聚合根访问它的关联关系是静态固定的那就留在MySQL如果一条数据的价值在于跟其他数据之间的动态关联、多层路径查询、扇出扩展才适合进图。我现在的项目是MySQL和Neo4j共存的订单流水、用户结算信息都在MySQL知识图谱、用户多维关系、权限血缘在Neo4j。这种混合架构会多一层数据同步的逻辑比如写MySQL时同步发消息到Neo4j更新关系数据。麻烦是麻烦点但每一层都在它最擅长的地方干活长期看是值得的。8.4 关于实体关系设计的一句个人体会图模型的设计有一个口诀倒是可以分享节点是你的名词关系是你的动词关系属性是形容词。设计节点的时候脑子里过一遍业务里有哪些主体和客体设计关系的时候问自己这两个节点之间到底发生了什么动作至于关系属性是你为了查询和展示给这个“动作”附加的描述。这套思路帮我避开了很多把图模型做成关系型模型的尴尬。你如果做知识图谱项目这个思路更加适用——实体、属性、关系的划分本质上就是在定义一套领域的本体模型。9. 从这篇开始动手的落地路径建议我在实战中反复验证过一套推进路径照着做可以少走很多弯路。第一步先把Neo4j服务端跑起来浏览器里跑通增删改查的Cypher语句。这一步花了半天时间都不算多基础打扎实后面全是顺水推舟。第二步搭建SpringBoot工程把连接配置跑通这个阶段不要写任何业务代码就靠那个CommandLineRunner打印连接成功就够了——先保证路是通的再上路跑车。第三步建实体和Repository。从最简单的单节点查开始先搞明白Node Id Relationship这几个注解的行为再去碰复杂查询。每个查询方法对应的Cypher先在浏览器里验证一遍结果再往Repository里贴。第四步等所有正向链路都通了再做懒加载、序列化、事务边界这些优化。不要一上来就在实体里加一堆关联关系——图的优势是查询灵活但Java实体的加载策略如果设计不好反而会拖累整体性能。第五步也是我特别想强调的一步每写一个Repository方法前先自己在Neo4j浏览器里跑一遍对应的Cypher确认数据结果正确。把Cypher调试从“代码跑出问题再回头看数据”提前到“先验证数据再有代码”能省掉你非常多的debug时间。这个习惯是我被连续几周的LazyReferenceException折磨之后才痛定思痛养成的——每次先看数据形状再想代码结构效率提升不是一点半点。好了Neo4j结合SpringBoot的完整链路算是捋清了一遍。下一篇有望写一下知识图谱方向的实战应用——怎么设计一个实用的知识图谱查询服务以及图算法比如最短路径、社区发现怎么在业务里落地。到时候见。