必须为图遍历加深度限制和结果截断，服务端需配置熔断、配额与合理堆内存，并通过压力测试验证。
核心问题很明确：遍历没设深度上限，图查询像脱缰野马，一口气拉上亿节点进内存，Heap 直接撑爆。
必须加深度限制和结果截断
所有递归或可变跳数的遍历语句，必须显式指定最大跳数和返回条数。比如 Cypher 风格的查询：
-
危险写法（禁止）：
MATCH (n:User)-[*]->(m:Product) RETURN n, m—— 星号 * 表示无上限遍历，极易失控 -
安全写法（强制）：
MATCH (n:User)-[:BUYS*1..3]->(m:Product) RETURN n, m LIMIT 1000—— 限定关系类型、跳数范围（1到3跳）、返回最多1000条
服务端要加查询熔断与资源配额
不能只靠客户端写对语句，后端必须兜底：
- 在查询入口层（如 API 网关或图查询代理）设置单次请求的最大节点访问数（例如 50 万）、最大路径生成数（例如 20 万）、超时时间（例如 8 秒）
- 为不同业务方或用户角色分配独立的查询配额桶，超出即拒绝，避免一个误操作拖垮整库
- 记录高开销查询日志，自动识别并告警
nodes_scanned > 10e6或paths_generated > 5e5的请求
堆内存配置需匹配真实负载
Heap 不是越大越好，但也不能小得离谱：
- 用
-Xmx显式设置最大堆（如-Xmx8g），避免 JVM 动态伸缩引发 GC 震荡；实际 RSS 内存通常比 -Xmx 高 15%~20%，要预留空间 - 禁用
-Xms过大（如设成和 -Xmx 一样），否则启动即占满，空闲时也无法释放，挤压系统其他进程 - 开启 GC 日志（
-XX:+PrintGCDetails -Xloggc:gc.log），重点观察老年代是否频繁晋升、Full GC 是否密集——这是遍历类查询溢出的典型前兆
上线前必须做深度压力验证
光测功能正确性不够，要专门打“深链查询”：
- 构造含长链路径的数据集（如 10 跳以上的用户-好友-订单-商品-供应商链），跑
-[:REL*1..10]查询，观察 Heap 增长曲线和 GC 频率 - 用 JFR（Java Flight Recorder）录制一次典型遍历请求，分析对象分配热点，确认是不是大量
PathImpl、NodeProxy类占满老年代 - 对比加限与不加限的内存峰值差异，确保限值设在业务可接受且系统稳态的交界点上
