简介：基于知识图谱的可视化问答系统毕业设计项目源码，适合正在准备毕业设计或搭建知识图谱应用系统的开发学习者，尤其适合医疗问答、图谱可视化方向。项目以医疗数据为背景，完整覆盖了药品、疾病、症状、食物、科室等实体关系的清洗与组织，并能将其导入图数据库生成知识图谱，再通过问答解析与图查询返回答案，同时在前端页面完成图谱与交互展示，是一个可运行的闭环案例。压缩包共 82 个文件，主要包含 Python 脚本、前端样式与脚本、超文本页面及医疗数据文本，辅以少量图片、字体和配置文件，整体大小 45.19MB，结构划分清晰。该资源已有 372 人浏览学习。代码中提供数据预处理与图谱构建脚本、问答解析与检索模块，以及配套可视化页面；在预先安装并启动 Neo4j 5.16.0、配置 Python 3.10 环境后，可参照说明逐项执行脚本完成入库并启动系统，便于从数据层、逻辑层到表现层完整理解知识图谱项目的实现脉络。
1. 知识图谱可视化项目：拿到这个代码包后究竟该怎么下手
如果你是在做课程设计、毕业设计，或者公司内部想快速搭一个“实体—关系”展示原型，那这个基于知识图谱的可视化项目代码包，应该能帮你省掉从零写全套逻辑的功夫。它有 Neo4j 数据库做底层存储，用 Python 写后端查询，再靠 JavaScript 和 CSS 渲染前端页面，整套链路正好对应知识图谱可视化的标准技术栈。我在接手这类项目时第一反应不是急着跑代码，而是先把“数据从哪来、关系怎么定义、前端怎么消费”这三件事理顺。这个包的价值不在于代码量多大，而在于它把图谱查询、接口封装、可视化配置串成了一条完整可复现的流程，你照着调数据就能替换成自己的业务场景。接下来我会从架构、数据灌入、前后端对接、常见踩坑一直拆到验证技巧。
2. 技术选型与整体架构：为什么偏偏是 Neo4j、Python 和 ECharts 这套组合
2.1 知识图谱的核心数据模型：一切可视化都建立在三元组之上
知识图谱这个概念听起来玄乎，拆到底层其实就是一张由“实体—关系—实体”组成的大网，技术上叫作三元组。比如“某开发者”掌握“Python”，那就是(某开发者)-[掌握]->(Python)这样一条有向边。图谱可视化要做的，就是把这类三元组变成屏幕上看得见的节点和连线。
Neo4j 之所以在这个场景里用得最多，是因为它的查询语言 Cypher 天生就是为这种模型设计的。你不需要像关系型数据库那样先设计一堆表再 JOIN，只需要写MATCH (n)-[r]->(m) RETURN n, r, m就能把整张网查出来。我在拆这个代码包时发现，它的数据文件里已经帮你构造好了实体和关系的 CSV，里面有节点表的 id、名称、类型，也有关系表的起点、终点、关系类型。你拿到手之后，最值得改的就是这两个文件，换成自己的业务数据就能得到一套新的图谱。
2.2 前后端框架的选型逻辑：这个组合为什么是毕业设计和原型验证的稳妥解
先说后端。这个包选 Python 做服务层，我拆下来看用的是 Flask 框架。Flask 的定位就是轻量、无侵入，一个app.py文件就能把路由、Cypher 查询、JSON 返回全部写完，不需要像 Django 那样搭一套完整的工程骨架。对于图谱可视化这种“查询多、写操作少”的场景，Flask 的简洁反而是优势。
前端部分，JavaScript 负责调用 ECharts 的 graph 系列。ECharts 图谱类型对知识图谱可视化的适配度很高，它内置了 force 和 circular 两种布局算法。force 布局模拟物理引力，节点会自动分散，适合关系比较复杂的图；circular 把节点排列在圆环上，适合展示层级或循环结构。CSS 在这里承担了页面样式和节点自定义样式的职责，比如不同实体类型用不同颜色区分，就是通过 CSS 类或 series 里的 itemStyle 控制的。
有同学会问为什么不用现成的 Gephi 或者 Neo4j Browser 直接展示。这两个工具确实能看图，但它们的定位是“数据探索工具”，不是“业务系统前端”。你要把图谱嵌到自己的网页里，或者按业务需求定制交互，就必须走“后端查数据、前端画图”这条路线。这个代码包解决的问题就是把这条路线打通。
2.3 代码包目录结构与核心文件职责：先看清文件再动手
拿到 zip 包之后，先不要急着跑，花几分钟看清目录结构。这个包的主目录大致是这样组织的：
knowledge-graph-visualization/ ├── app.py # Flask 后端主入口，提供 /api/graph 接口 ├── requirements.txt # Python 依赖清单 ├── data/ │ ├── nodes.csv # 节点表：id、name、category │ └── relations.csv # 关系表：source、target、type ├── static/ │ ├── index.html # 前端主页面 │ ├── echarts.min.js # ECharts 库文件 │ └── style.css # 页面样式 └── import_data.cypher # 把 CSV 导入 Neo4j 的脚本app.py是整个项目的核心枢纽，它做的事情有三件：连接 Neo4j 数据库、执行 Cypher 查询、把查询结果转换成前端能直接消费的 JSON。import_data.cypher是初始化脚本，你只需要在 Neo4j 的 Web 控制台里执行一遍，就能把 CSV 数据灌进图数据库。看清这个结构之后，你的任务就变成了三步：改数据、灌数据、启动前后端。
提示：如果下载包里没有 requirements.txt，可以根据导入的包自行生成。这个项目我们通常需要
flask和neo4j两个 Python 包。
3. 数据灌入 Neo4j 的完整流程：从环境准备到 CSV 批量导入
3.1 环境准备：Neo4j 安装与初始账号配置
先把 Neo4j 装好。官方提供了 Desktop 版和 Community Server 版，做本地开发我建议用 Community Server，因为它的启动方式更透明，适合排查问题。安装完成之后，在终端里执行启动命令：
# 进入 Neo4j 安装目录，启动服务 ./bin/neo4j start # 查看服务状态，通过 7474 端口确认是否正常 ./bin/neo4j status启动成功后打开浏览器访问http://localhost:7474，首次登录需要输入默认账号密码，初始账号是neo4j，密码是neo4j。登录后系统会强制要求修改密码，这一步建议直接设置成你项目里要用的密码。我在实际操作中习惯把密码设置成graph123456这种自己容易记住的值，然后统一写到app.py的认证配置里。
接下来创建一个专用的数据库。Neo4j 4.x 之后支持多数据库，用下面的命令创建并切换到新库：
CREATE DATABASE knowledge_graph; :USE knowledge_graph;注意：
app.py里连接的是默认数据库还是新建的knowledge_graph，取决于连接 URI 里的database参数。如果连接失败，优先检查这个参数是否匹配。
3.2 用 Cypher 先小批量验证数据模型
在灌大量数据之前，我习惯先用手写几个 Cypher 节点试试模型是否合理。比如这个包里的数据是“课程—掌握—知识点”之类的关系，那我会先创建两个节点和一条关系：
CREATE (c:Course {name: '数据结构', id: 'C001', category: '课程'}) CREATE (k:KnowledgePoint {name: '二叉树', id: 'K001', category: '知识点'}) CREATE (c)-[:COVERS]->(k)这一步的意义在于验证三件事。第一，节点标签和属性名是否和import_data.cypher里一致；第二，关系方向是否按业务语义定义，是从课程指向知识点，还是反过来；第三，你设想的属性能不能支撑后续前端展示，比如category字段是用来做节点分类着色的，前端代码里会按它的值映射颜色。如果这个小批量创建查询执行成功，就能确定模型没问题，然后再放开灌入完整数据。
3.3 批量导入的正确姿势：LOAD CSV 的字段映射与编码坑
完整数据放在data/nodes.csv和data/relations.csv里。批量导入用到的是 Cypher 的LOAD CSV功能。我用这个包自带的import_data.cypher做一个示例，它的核心流程是先删掉旧数据，再加载节点，最后加载关系：
// 清空数据库，防止重复导入造成脏数据 MATCH (n) DETACH DELETE n; // 导入节点表 LOAD CSV WITH HEADERS FROM 'file:///nodes.csv' AS row MERGE (n:Entity {id: row.id}) SET n.name = row.name, n.category = row.category; // 导入关系表 LOAD CSV WITH HEADERS FROM 'file:///relations.csv' AS row MATCH (source:Entity {id: row.source}) MATCH (target:Entity {id: row.target}) MERGE (source)-[r:RELATED {type: row.type}]->(target) SET r.name = row.type;先说为什么用MERGE而不是CREATE。MERGE的逻辑是“有则匹配，无则创建”，它能保证重复执行脚本不会创建重复节点。在开发阶段你会频繁清空和重导数据，用MERGE相当于给自己留了后悔药。关系表里的MATCH用id去定位节点，这就要求节点表里的id字段必须全局唯一，否则一条关系可能连到错误的节点上。
LOAD CSV有个常见限制：它默认只能读取 Neo4j 安装目录下的import文件夹。很多第一次用的人报错Couldn't load the external resource，就是因为 CSV 文件没放到import目录下。解决办法有两个，要么把 CSV 复制到import文件夹，要么在 Neo4j 配置文件neo4j.conf里放开dbms.security.allow_csv_import_from_file_urls=true。我一般直接走第一个方案，省事且稳定。
另外一个隐藏比较深的坑是文件编码。CSV 文件在 Windows 下保存时经常是 ANSI 或 GBK 编码，Neo4j 默认按 UTF-8 读取，结果就是导入后中文全部变成乱码。我的习惯是导入之前用编辑器把 CSV 转存成 UTF-8 编码，或者用脚本统一转一下：
import pandas as pd # 读取时指定源编码，写出时统一为 utf-8-sig for file_name in ['nodes.csv', 'relations.csv']: df = pd.read_csv(f'data/{file_name}', encoding='gbk') df.to_csv(f'data/{file_name}_utf8.csv', index=False, encoding='utf-8-sig')这里写成utf-8-sig而不是utf-8，是因为它会在文件头写入 BOM 标记。Neo4j 读取带 BOM 的文件时能自动识别编码，这比不带 BOM 的纯 UTF-8 更保险。导入成功之后，可以执行一条计数查询确认数据量：
MATCH (n) RETURN count(n) AS node_count; MATCH ()-[r]->() RETURN count(r) AS relation_count;如果节点数和关系数和 CSV 行数一致，就说明数据灌入成功，可以进入后端接口开发了。
4. 可视化核心实现：Flask 后端查询与 ECharts 前端渲染的对接细节
4.1 Flask 后端：把图查询结果构造成前端能直接消费的 JSON
后端接口是整个可视化链路的中转站。前端不是直接连 Neo4j 的，因为 Neo4j 的 Bolt 协议不适合浏览器直接访问，而且 Cypher 查询语句暴露在前端也不安全。所以常规做法是后端封装一个/api/graph接口，把图查询结果转成 ECharts 需要的nodes和links数组。下面这段代码就是app.py里的核心逻辑：
from flask import Flask, jsonify from neo4j import GraphDatabase app = Flask(__name__) # 连接 Neo4j 数据库 driver = GraphDatabase.driver( "bolt://localhost:7687", auth=("neo4j", "graph123456") ) @app.route("/api/graph", methods=["GET"]) def get_graph(): # 查询全部节点和关系，只取前 200 条避免响应过大 query = """ MATCH (n)-[r]->(m) RETURN n.name AS source_name, n.category AS source_category, m.name AS target_name, m.category AS target_category, type(r) AS relation_type LIMIT 200 """ nodes_map = {} links = [] with driver.session() as session: result = session.run(query) for record in result: src = record["source_name"] dst = record["target_name"] # 用节点名称作为唯一标识，补充到 nodes_map if src not in nodes_map: nodes_map[src] = {"name": src, "category": record["source_category"]} if dst not in nodes_map: nodes_map[dst] = {"name": dst, "category": record["target_category"]} # 组装关系数组 links.append({ "source": src, "target": dst, "relation": record["relation_type"] }) return jsonify({ "nodes": list(nodes_map.values()), "links": links }) if __name__ == "__main__": app.run(host="0.0.0.0", port=5000, debug=True)这段代码的关键点有几个。第一个是把查询结果里的节点去重，因为在MATCH (n)-[r]->(m)查询里，同一个节点可能出现在多条关系的起点或终点，如果不去重直接往前端塞，ECharts 会渲染出大量重复节点，图上看起来就会有一堆重叠的点。这里的nodes_map就是用来处理这个问题的，用名称做 key，天然完成去重。
第二个关键点是LIMIT 200。知识图谱的数据量一旦超过几千条关系，前端渲染就会明显变卡，这在后面排查章会细说。加LIMIT是开发阶段最实用的手段，保证接口响应速度和页面流畅度。
第三个注意点是type(r)函数。它返回的是关系类型的名称字符串，比如COVERS、RELATED。这个值在可视化里通常用来做关系线的标签或颜色映射。如果你的 CSV 里关系类型的值存在type属性里而不是类型名本身，那查询改成下面这样更合理：
MATCH (n)-[r]->(m) RETURN n, m, r.type AS relation_type4.2 前端 ECharts 配置：graph 系列的核心参数逐个拆开
后端把数据返回之后，前端index.html里的 JavaScript 就要接管渲染了。这里用的是 ECharts 的graph类型，核心配置如下：
const chart = echarts.init(document.getElementById('graph-container')); fetch('/api/graph') .then(res => res.json()) .then(data => { // ECharts 要求节点必须是数组，关系字段为 source/target const nodes = data.nodes.map(item => ({ id: item.name, name: item.name, category: item.category, symbolSize: 40, itemStyle: { color: getColorByCategory(item.category) } })); const links = data.links.map(item => ({ source: item.source, target: item.target, label: { show: true, formatter: item.relation } })); chart.setOption({ tooltip: { trigger: 'item' }, legend: { data: ['课程', '知识点'] }, series: [{ type: 'graph', layout: 'force', roam: true, draggable: true, data: nodes, links: links, force: { repulsion: 300, // 节点之间的斥力 edgeLength: [80, 200] // 边长的最小值和最大值 }, label: { show: true, position: 'right' }, emphasis: { focus: 'adjacency' } }] }); });layout: 'force'是图的布局方式。force 布局会模拟带电粒子的物理效果，节点之间互相排斥，有关系的节点通过边拉近距离。渲染初期你会看到节点从中心炸开再慢慢稳定下来，这个动态过程本身就是可视化的加分项。如果你希望图谱尽量稳定、不要每次刷新位置都变，可以改成layout: 'circular'，所有节点按环形排列，适合节点数小于 50 的场景。
repulsion参数控制节点之间的斥力大小，数值越大节点间距越大。默认是 300，但如果你有 200 个以上节点，我一般会调到 500 左右，否则节点会挤成一团看不清标签。edgeLength控制边的长度范围，它是两个值的数组，ECharts 会在这个范围内按关系强度调整边长。
emphasis.focus: 'adjacency'是个比较有用的交互参数，鼠标悬停在一个节点上时，只有它相邻的节点保持高亮，其他节点变灰。这个效果能直观地突出“某个实体和谁直接相连”，在答辩或汇报演示时效果很明显。
4.3 交互能力扩展：点击节点、筛选面板与详情联动
基础渲染跑通之后，可以再加一层交互。最常见的扩展是点击节点展示该实体的详细信息，或者在侧边栏显示它的直接邻居。实现方式是利用 ECharts 的点击事件：
// 点击节点时，从后端单独查询该节点的邻居节点和关系 chart.on('click', params => { const nodeName = params.data.name; fetch(`/api/neighbors?name=${encodeURIComponent(nodeName)}`) .then(res => res.json()) .then(data => { // 更新右侧侧边栏内容 document.getElementById('detail-panel').innerHTML = `<h3>${nodeName}</h3>` + `<ul>${data.neighbors.map(n => `<li>${n}</li>`).join('')}</ul>`; }); });对应的后端接口也很简单，本质就是一次带参数的 Cypher 查询：
@app.route("/api/neighbors", methods=["GET"]) def get_neighbors(): from flask import request name = request.args.get("name", "") query = """ MATCH (n {name: $name})-[r]->(m) RETURN m.name AS neighbor, type(r) AS relation """ with driver.session() as session: records = session.run(query, name=name).data() return jsonify({"neighbors": [f"{rec['relation']} -> {rec['neighbor']}" for rec in records]})session.run的第二个参数是参数化查询的格式，用$name占位而不是直接拼字符串，这样可以防止 Cypher 注入，虽然图数据库的注入面没那么大，但养成参数化的习惯没坏处。
5. 知识图谱可视化常见问题排查：五个必须提前知道的踩坑点
5.1 节点挤在页面左上角或原点：布局参数与容器尺寸的坑
现象：页面加载后，图谱所有节点或全部重叠在左上角，或者堆在画布正中间成一个团。
原因：这个现象最常见的原因有两个。第一个是图容器没有高度，div的高度是 0，ECharts 初始化时画布尺寸无效，所有节点只能在坐标系原点附近。第二个是 force 布局渲染时节点还没完全散开，数据量小、斥力不足时也会堆在一起。
解决：先在 CSS 里给容器设置明确的高度，比如#graph-container { width: 100%; height: 600px; }，不要在初始化时依赖自动撑开。然后检查force配置里的repulsion是否设得太小，低于 200 时节点间距会明显不够。如果两个都改了还是挤在一起，可以用 ECharts 的chart.resize()方法在页面加载完成后手动刷新一次画布。
5.2 中文标签显示乱码：三个环节逐一排查
现象：节点名称和关系标签在页面上显示成锟斤拷或问号。
原因：这个坑在中文数据项目里出现的频率最高，而且排查点不止一个。第一个是 CSV 文件编码不对，Neo4j 按 UTF-8 读取了 GBK 编码的文件，入库时就已经是乱码。第二个是 Neo4j 数据库本身没配置对字符集。第三个是前端页面的<meta charset="utf-8">没写，或者 HTML 文件本身不是 UTF-8 保存的。
解决：从源头查起。在 Neo4j 里执行MATCH (n) RETURN n.name LIMIT 5，如果返回结果里的中文是正常的，说明数据没问题，问题在浏览器渲染；如果返回就是乱码，那就是导入环节的问题，按前面提到的转码方案把 CSV 统一转成utf-8-sig再重新导入。同时确认index.html的<head>里有一行<meta charset="utf-8">。
5.3 前端图渲染卡顿：节点量级与配置的平衡方案
现象：数据量稍微大一点，浏览器就明显掉帧，拖动节点时卡顿，甚至页面直接崩溃。
原因：ECharts 的 graph 在超过 500 个节点左右就会开始有性能压力，超过 1000 个节点时 force 布局的物理计算量会让普通电脑扛不住。这个包默认的LIMIT 200就是为了规避这个问题。
解决：我的处理方案分三档。第一档，写死LIMIT 200，适合开发调试阶段；第二档，在 SQL 之外加一个前端阈值判断，数据超过 300 个节点就弹出提示，让用户输入筛选条件后再查询；第三档，如果数据量真的很大，考虑在后端做按类别的子图切割，一次只加载一类实体和它们的关系。记住一个原则：知识图谱可视化优先展示的是“结构”，不是“全部数据”。一次看清楚 200 个节点的关系网，比模糊地看到 2000 个点更有价值。
5.4 请求跨域失败：前后端分离部署的隐藏障碍
现象：浏览器控制台报Access to fetch at ... has been blocked by CORS policy，接口返回不了数据。
原因：前端页面和后端 Flask 服务分别跑在不同端口，比如页面在localhost:5500，接口在localhost:5000，这就是跨域请求。浏览器默认拦截跨域响应，而项目里 Flask 没有配置 CORS 头。
解决：两个方案。最省事的方案是安装 Flask 的 CORS 扩展：
pip install flask-cors然后在app.py里加两行：
from flask_cors import CORS CORS(app) # 允许所有来源跨域访问另一个方案是不装扩展，在后端手动加响应头。但我推荐直接用 flask-cors，因为代码改动最小，而且能避免一些直接操作响应头时容易漏掉的 preflight 请求处理。这类项目一般不会部署到生产环境，全放开 CORS 没有风险。
5.5 关系线不显示文字或方向箭头：symbol 配置的细节问题
现象：图上节点正常显示，但关系线上既没有箭头，也没有标签文字，看起来像一堆无向线段。
原因：ECharts 的 graph 系列里，边标签默认是关闭的，箭头的symbol默认是none，不手动配置就不会显示。这个问题不算 bug，是配置项没写全。
解决：在links数组的每一项里补充symbol和label配置：
const links = data.links.map(item => ({ source: item.source, target: item.target, symbol: ['none', 'arrow'], // 箭头画在线段的终点 symbolSize: 10, label: { show: true, formatter: item.relation }, lineStyle: { width: 1.5, curveness: 0.1 } }));symbol数组有两个元素，第一个是起点样式，第二个是终点样式，['none', 'arrow']表示起点无标记、终点画箭头。curveness: 0.1给关系线加一点点弧度，这样当两个节点之间存在多条不同关系时，线不会完全重叠，能明显区分出不同路径。
6. 演示前的验证清单与进阶扩展思路：从“功能能跑”到“结构能讲”
6.1 一套完整的验证流程清单
每次改完数据或代码，我会强制自己走一遍完整的验证流程，按顺序是：先确认 Neo4j 服务状态，再检查导入数据量，然后启动 Flask，最后开着浏览器控制台看请求和渲染。具体照着做是这样的：
# 第一步：确认 Neo4j 在运行 ./bin/neo4j status # 第二步：确认数据已导入 # 在 http://localhost:7474 执行： # MATCH (n) RETURN count(n) # MATCH ()-[r]->() RETURN count(r) # 第三步：启动后端 python app.py # 第四步：打开 index.html，按 F12 看 Network # 确认 /api/graph 返回 200 且有 JSON 数据验证时重点看两个一致性：接口返回的节点数和 Neo4j 里查询到的节点数是否一致，前端图上渲染的节点数是否等于接口返回的数组长度。这三个数字如果对不上，说明链路某个环节丢了数据，最常见的是节点重名被nodes_map合并了，这种情况要考虑用 Neo4j 内部 id 或唯一业务 id 替代名称作为节点标识。
6.2 进阶技巧：图谱搜索和最短路径高亮
演示的时候，如果能加一个搜索和路径高亮功能，整个项目的完成度会直接上一个台阶。搜索的做法是在前端加一个输入框，把用户输入的关键词传到后端，用CONTAINS做模糊匹配：
MATCH (n) WHERE n.name CONTAINS $keyword RETURN n LIMIT 20找到目标节点后，在图谱上定位并高亮它以及它的邻居。这个方法在答辩场景很管用，面试官或评审老师会提“我想看某个实体”，你现场输入关键词，图自动聚焦过去，比从头讲一遍代码有说服力得多。
更高级一点是最短路径查询。两个实体之间的关联路径是知识图谱可视化里最能体现“图”价值的功能，比如“某开发者”和“某种编程语言”之间隔了几层关系。后端的 Cypher 用内置的最短路径算法：
MATCH p = shortestPath((a {name: $start})-[*..6]-(b {name: $end})) RETURN [node IN nodes(p) | node.name] AS path_nodes, [rel IN relationships(p) | type(rel)] AS path_rels前端拿到路径后，把路径上的节点和关系重新渲染一遍，其他节点统一置灰。这个处理方式我在实际做数据中台项目时用过一次，领导当时就说“这个能看到业务链路全景”。从那以后我做图谱可视化，都会把最短路径功能当成标配而不是附加项。这类功能代码量不大，但投入产出比很高，强烈建议你也把这一块加上，用好了效果比堆一堆节点更直观。希望这份拆解能帮你有方向地把这个知识图谱可视化项目跑起来、调顺、讲明白。
本文还有配套的精品资源，点击获取
