基于Neo4j的知识图谱电影问答系统：建模、实现与避坑指南

简介一套面向计算机相关专业毕业设计的高分项目源码基于Python与Neo4j构建知识图谱电影问答系统涵盖后端服务、爬虫采集、图谱构建及小程序端交互展示。项目源出大四毕设评审分99分代码完整可直接运行适合正在做毕设、需要项目实战练习或完成课程设计、期末大作业的学生使用。资源压缩包共59个文件约6.28MB主要包含py格式的Flask后端与爬虫脚本、csv和json格式的实体关系数据、png和svg格式的系统流程与界面图、js/wxml/wxss格式的小程序前端页面以及txt和md格式的说明文档目录清晰便于查阅。目前已有77人学习下载。通过该资源可系统理解知识图谱构建、实体关系抽取、问答匹配与前端展示的完整链路还可参考其项目结构、文档写法与答辩准备思路为自身毕业设计提供扎实范本有助于快速搭建同类系统。1. 知识图谱电影问答系统为什么它是一个少见的高分毕设方向毕业设计如果只做“一个能回答问题的机器人”大概率会被老师认为没有技术含量但如果你在前面加上“知识图谱”、后面加上“Neo4j”整个项目的性质就不一样了。它解决的并不是“让AI更懂人话”而是一个更实际的工程问题当用户问“周星驰主演过哪些电影”时系统怎么把这句话拆成实体“周星驰”、关系“主演”、目标“电影”再转换成一条Cypher查询从图数据库里把答案捞出来。适合什么人群计算机科学、软件工程、数据科学方向的大四和研二学生以及想快速把Python和Neo4j组合用在实际项目里的开发者。我的判断是这个选题对算法要求没那么高但数据建模、链路设计、工程细节点都不少做出来后你既能完整讲解知识图谱落地流程又能现场演示真实可用的问答系统答辩的主动权基本在自己手里。2. 电影知识图谱的数据建模实体、关系与Neo4j写入代码2.1 为什么电影领域适合用知识图谱而不是关系型数据库知识图谱本质上是一种用“节点-边-属性”描述世界的组织方式电影领域恰恰是这种结构最自然的展示场。一部电影不是孤立存在的它有导演、有演员、有类型、有上映年份、有评分一个演员又参演了多部电影、和某些导演反复合作、还拿过不少奖。这种多对多的网状关系如果用MySQL来建模你要为film、actor、director、genre各建一张表中间还要加film_actor、film_director、film_genre三张关联表。想查“某演员评分最高的五部电影”至少三个JOIN写过去数据量一大性能就会成为肉眼可见的瓶颈。而Neo4j图数据库把实体存成节点、把关系存成边查同一个问题只需要一条MATCH把所有路径找出来。图的遍历天然避免JOIN这个操作特别是电影数据本身是稀疏的——大多数演员之间并没有合作这种“大部分路径不存在”的场景图数据库的优势会更明显。给毕设做技术选型时这个比较结构要写进文档MySQL做到万级节点时三表JOIN的响应时间、Neo4j同规模下的响应时间两者一旦放到一个对比表格里答辩老师对你技术选型的认可度会明显不一样。对比维度MySQL方案Neo4j知识图谱方案数据模型多表外键关联表节点关系天然网状查询“演员的电影”JOIN 2~3张表索引是前提MATCH路径遍历一行Cypher扩展新关系类型加表/加字段迁移直接加一种关系类型零迁移可视化呈现表格为主图可视化答辩展示效果好2.2 图谱Schema设计实体类型、属性与七种关系动手写代码之前先定Schema这一步不要省略。公开的电影数据集大部分来自TMDB、IMDb或者豆瓣的整理版本几部主流格式是CSV或JSON。我采用的Schema包含四个实体标签Movie电影、Person人物、Genre类型、Award奖项。每个标签配一组属性Movie有title中文名、original_title原名、year上映年份、rating评分、votes评分人数、description简介Person有name姓名、birth_year出生年份Genre和Award各只需一个name属性。这里有个关键设计取舍Person要不要拆成Actor和Director两个标签我的建议是不拆。原因很实在很多真实的人既当导演又当演员姜文、徐峥都是典型例子。拆成两个标签会让同一个实体在图中出现两个节点之后查询会一直纠结要不要做去重。用一个Person标签演员和导演的身份由关系类型来区分图谱才跟真实世界对得上。关系类型建议控制在能数完的个数内我最终保留了七种ACTED_IN出演、DIRECTED执导、HAS_GENRE属于类型、REMAKE_OF翻拍自、SEQUEL_OF续接、WON_AWARD获奖、GOT_AWARD影片获奖。两个关系带属性ACTED_IN带role角色名WON_AWARD带category比如“最佳男主角”。这个设计能支撑的问答类型已经覆盖了百分之八十常见场景——查演员作品、查导演、查类型片、查翻拍关系、查获奖情况。2.3 用Python把电影数据清洗成三元组并写入Neo4j数据来源选什么我不建议毕业答辩项目去实时爬豆瓣。爬虫本身不是难点但豆瓣反爬策略不稳定、演示现场网络环境不可控、爬回来的字段还需要大量对齐清洗任何一个环节出问题都会耽误进度。更稳妥的方案是找一份整理好的公开电影数据集GitHub上有不少TMDB和IMDb的清洗版本然后用Python脚本清洗成三元组再导入Neo4j。下面这段写入代码是我在项目里实际采用的模式from py2neo import Graph, Node, Relationship, NodeMatcher # 连接Neo4j注意把密码替换为你自己的 graph Graph(bolt://localhost:7687, auth(neo4j, your_password)) matcher NodeMatcher(graph) # movies 是一个 list[dict]每个dict包含 # {title: 霸王别姬, year: 1993, rating: 9.6, # actors: [张国荣, 张丰毅], directors: [陈凯歌], genres: [剧情, 爱情]} def import_movie(movie: dict): # 用MERGE而不是CREATE避免重复执行导入脚本时产生重复节点 movie_node matcher.match(Movie, titlemovie[title]).first() if movie_node is None: movie_node Node(Movie, titlemovie[title], yearmovie[year], ratingmovie.get(rating, 0)) graph.create(movie_node) for actor_name in movie.get(actors, []): person_node matcher.match(Person, nameactor_name).first() if person_node is None: person_node Node(Person, nameactor_name) graph.create(person_node) # 关系带上role属性方便后续查扮演了什么角色 graph.create(Relationship(person_node, ACTED_IN, movie_node, role演员)) for director_name in movie.get(directors, []): director_node matcher.match(Person, namedirector_name).first() if director_node is None: director_node Node(Person, namedirector_name) graph.create(director_node) graph.create(Relationship(director_node, DIRECTED, movie_node)) for genre_name in movie.get(genres, []): genre_node matcher.match(Genre, namegenre_name).first() if genre_node is None: genre_node Node(Genre, namegenre_name) graph.create(genre_node) graph.create(Relationship(movie_node, HAS_GENRE, genre_node)) for movie in movies: import_movie(movie) print(导入完成节点数, graph.run(MATCH (n) RETURN count(n)).evaluate())这里几个参数要特别关注。第一个是bolt://localhost:7687这个地址Neo4j 4.0之后默认推荐bolt协议而不是http连接失败的时候先检查Neo4j配置里bolt端口开没开。第二个是auth(neo4j, your_password)Neo4j第一次启动会强制修改初始密码不同版本密码策略不一样。第三个是性能隐患——graph.create一条一条写入几千条关系没问题但你的数据集一旦超过三万条关系建议改成事务批量提交具体做法在第五章节讲。另外matcher.match(...).first()这段避免了重复创建节点但它的前提是数据源里的title和name已经做了去重和清洗。清洗这一步很关键一条电影的title和另一条电影的title如果有前后空格哪怕只有一个字符的差异MERGE也会把它当成两个节点。3. 环境搭建与Python连接Neo4j安装、驱动选择和最小查询链路3.1 Neo4j社区版安装与配置Desktop版本和conf参数这一节先说一个关于版本的“玄学”判断Neo4j 5.x虽然更新但很多老版本的py2neo库跟它配合不好如果你用的Python版本是3.8到3.10我更推荐选择Neo4j 4.4.x的LTS版本配合起来翻车概率最低。如果Python环境是3.11以上Neo4j 5.x反而是更稳的选择因为py2neo已经基本停止维护官方驱动neo4j包对5.x的支持更完整。这是一个取舍问题没有绝对正确答案选定了就不要再中途换版本。安装路径有两个直接装Neo4j Desktop桌面版或者用Docker跑官方容器。给毕设项目做演示我推荐桌面版。理由很朴素——桌面版自带可视化浏览器界面答辩的时候切到图谱页面那一整屏的节点和连线比任何截图都更有视觉说服力。而且Desktop版的数据目录和日志目录都有图形化入口真出了问题排查起来比较省心。安装完成后的第一件事是检查conf/neo4j.conf里的三个配置项dbms.connector.bolt.listen_address:7687不能注释掉dbms.connector.http.enabledtrue要保持开启dbms.security.auth_enabledtrue维持默认。然后启动并验证状态# 在Neo4j安装目录下执行或直接在Neo4j Desktop里点Start bin/neo4j start # 确认返回 Neo4j is running 字样 bin/neo4j status启动后用浏览器打开http://localhost:7474第一次登录会让你修改neo4j初始密码。改完记住它后面Python连接全都要用。此外如果你是在Linux服务器上跑Neo4j还要注意默认端口不能被防火墙挡住不然本机能连、用另一台机器来连接就报超时——这个坑我在带学生项目时见过很多次。3.2 Python驱动连接Neo4jpy2neo和官方驱动的选择Python接Neo4j的路子主要有两条社区维护的py2neo和官方提供的neo4j驱动。py2neo的API比较友好Node、Relationship、Graph这几个概念封装得很直观适合快速实现功能。但问题是对Neo4j 5.x的支持基本停滞如果你跟着5.x版本走下去后面出了问题不太好查。官方驱动neo4j包初看API要繁琐一些不过胜在持续维护而且支持异步、支持多数据库。在这个项目里我更推荐官方驱动做主体代码核心逻辑用一个封装类包起来写起来也不差from neo4j import GraphDatabase class MovieGraph: def __init__(self, uri, user, password): # GraphDatabase.driver是官方驱动的入口可复用连接池 self.driver GraphDatabase.driver(uri, auth(user, password)) def close(self): self.driver.close() def query(self, cypher, paramsNone): # session自动关闭避免连接泄漏 with self.driver.session() as session: result session.run(cypher, params or {}) return [record.data() for record in result] graph MovieGraph(bolt://localhost:7687, neo4j, your_password) count graph.query(MATCH (n) RETURN count(n) AS total) print(count)这段代码里record.data()是一个关键细节。官方驱动返回的是一个Record对象列表.data()方法会把Cypher查询的返回列转成Python字典之后处理的时候直接用row[total]取数就行。封装了query()方法之后后面所有问答模块只需要一行graph.query(...)就能执行Cypher不用每个地方都重新连接、开session、关session也方便你在一个位置统一加上日志打印。尤其在做问答系统调试时能把每一条Cypher执行时间打出来对后续优化帮助特别大。3.3 Cypher索引设计与查询验证让图谱查询不拖后腿问答系统的隐性要求是响应快。用户在前端界面上问一句“周星驰演过什么电影”如果系统卡了三秒才返回体验会非常差。Cypher查询性能的瓶颈十次里有九次是全库扫描——你没有索引的时候Neo4j只能把带某个标签的所有节点扫一遍再逐个比对属性值。这个操作在节点数少的时候没什么感知但电影图谱做到两万以上节点时响应时间会明显拉长。所以建完图谱后的下一个动作就是创建索引这个动作应该在导入数据前或导入后尽快执行CREATE INDEX movie_title_idx IF NOT EXISTS FOR (m:Movie) ON (m.title); CREATE INDEX person_name_idx IF NOT EXISTS FOR (p:Person) ON (p.name); CREATE INDEX genre_name_idx IF NOT EXISTS FOR (g:Genre) ON (g.name);注意Neo4j 4.x的语法是CREATE INDEX ON :Movie(title)如果你用的是5.x以上版本上面的IF NOT EXISTS FOR ... ON语法才适用报语法错误时先检查版本。建好索引后用EXPLAIN关键字查看查询计划如果执行计划里的访问路径是NodeIndexSeek而不是NodeByLabelScan说明索引确实被命中了。你在文档说明里可以把这个点作为性能优化的实证十万级节点规模下带索引的精确查询和不带索引的标签扫描耗时差距可能在个位数毫秒和数百毫秒之间。这个是答辩老师比较感兴趣的量化对比。4. 问答系统实现从中文问句到Cypher查询的完整链路4.1 意图识别基于模板匹配的轻量方案问答链路最核心的工作是把用户的自然语言问句转换成一条可执行的Cypher。这一步拆成两个子任务意图识别和槽位填充。意图识别要回答“用户想查什么”——是查某演员的作品列表查某部电影的导演还是按类型和年份查高分片。在这个项目规模下我强烈不建议用BERT做意图分类你需要标注大量训练数据换来的提升却不一定比模板匹配明显。毕设要做的是稳定可复现的工程模板方案已经能覆盖绝大部分常见问题。常见的做法是维护一个意图模板库每个意图由一组触发词或正则表达式激活。触发词的权重完全来自人工经验比如“主演、出演、演过、演的”都是查询演员作品的高置信词。我常用的实现是这样的INTENT_PATTERNS { actor_movies: [主演, 出演, 演过, 演的], movie_director: [导演, 执导, 谁拍的], movie_rating: [评分, 评分多少, 评价如何], genre_movies: [类型的电影, 题材的], actor_cooperation: [合作, 一起演过], } def detect_intent(sentence: str) - str: for intent, patterns in INTENT_PATTERNS.items(): for p in patterns: if p in sentence: return intent return fallback s1 周星驰主演过哪些电影 s2 《霸王别姬》的导演是谁 print(detect_intent(s1)) # actor_movies print(detect_intent(s2)) # movie_director这段代码的匹配顺序很重要因为INTENT_PATTERNS中的顺序代表规则优先级。“主演”的置信度最高就放在最前面把“导演”放第二这样如果一个问句同时包含“导演”和“主演”两个字系统会优先按“主演”处理。但实际项目中我一般会显式给每个意图加一个priority字段用排序而不是字典顺序来控制优先级这样后加入新意图时不用纠结放在哪个位置。意图模板覆盖到二十到三十种就够用了这个在文档说明里不用谦虚直接写“覆盖电影问答常见意图X种”老师会觉得你做过需求调研。4.2 实体链接词典构造、同义词与最大匹配识别出意图之后下一步是从问句中捞出关键实体。实体链接最经典的实现是词典匹配——提前从Neo4j里把所有的Movie.title和Person.name取出来构建一个实体词典然后用这个词典对用户问句做字符串匹配。但如果直接这么做会有个很现实的尴尬用户问的是“霸王别姬”你的库里可能存的是“霸王别姬(1993)”匹配直接失败。所以词典构建时要给每个实体扩展出多个别名。别名来源就是去书名号、去年份后缀、补上常见外号。这个环节是“黑匣子”最集中的地方因为别名覆盖的质量很难预判只能靠后续测试不断补。我的做法是构建一个entity_alias字典key是别名value是标准实体名匹配时按长度降序做最大正向匹配class EntityLinker: def __init__(self, aliases: dict): self.aliases aliases # 按别名长度降序排列保证最长匹配优先 self.sorted_aliases sorted(aliases.keys(), keylen, reverseTrue) def link(self, sentence: str) - list: hits [] for alias in self.sorted_aliases: if alias in sentence: hits.append((alias, self.aliases[alias])) # 用占位符替换已命中的实体避免短词被重复匹配 sentence sentence.replace(alias, 【ENTITY】) return hits这个replace占位符的操作是个容易忽略但非常实用的小技巧。如果不做替换用户问“张国荣和梁朝伟合作过哪些电影”短别名“国荣”可能会在更长别名“张国荣”命中之后又被重复匹配一次导致实体槽位出现两条“张国荣”的记录。加占位符之后每一段原文只会命中一次主实体槽位填充就干净了。同义词映射也直接挂在词典里比如“哥哥”映射到“张国荣”、“星爷”映射到“周星驰”这类别名不需要太多手工维护几十条就能覆盖大多数演示场景。4.3 Cypher生成与答案拼接参数化查询的安全红线意图和实体都拿到手之后最后一步是组装Cypher并执行。这里有一条安全红线必须写进代码规范所有从用户问句中提取的字符一律作为参数传入Cypher禁止拼进查询字符串。你一旦允许拼接用户输入“霸王别姬’ OR 11 RETURN 1”这类内容时会直接变成Cypher注入轻则查询报错重则数据被删答辩演示现场出现这种情况就基本没翻盘的余地了。安全的写法如下def answer_actor_movies(actor_name: str) - str: query MATCH (p:Person {name: $name})-[:ACTED_IN]-(m:Movie) RETURN m.title AS title, m.year AS year, m.rating AS rating ORDER BY m.rating DESC LIMIT 10 result graph.query(query, {name: actor_name}) if not result: return f抱歉没有找到演员 {actor_name} 参演的电影信息 movies_str 、.join( [f{r[title]}({r.get(year, 未知)}) for r in result] ) return f{actor_name} 参演的主要电影有{movies_str}$name就是Cypher的参数占位符实际传参的时候通过{name: actor_name}传入。这样做除了安全性之外还有一个性能红利Neo4j会让相同结构的Cypher模板复用执行计划只要你问句生成的Cypher模板是固定的、只是参数值不同后续查询会跳过重新解析的步骤响应延迟比每次都拼新查询要低。在工业知识图谱的实现中这个机制也是同样的用法。ORDER BY m.rating DESC LIMIT 10这段是防止演员作品太多导致回复消息过长你的图谱数据量越大这个LIMIT越重要否则一个出演过两百部电影的演员他一个人的作品列表就能把回复消息撑爆。5. 避坑手册知识图谱电影问答项目最常见的5个踩坑记录5.1 连接失败Unsupported authentication token 和协议错误现象Python脚本执行GraphDatabase.driver(...)创建连接时报Unsupported authentication token或者一直卡在连接超时。我见过不少学生在答辩前一周卡在这个问题上非常折腾。原因两个因素叠加造成。第一是Neo4j 5.x调整了认证机制对旧版Python驱动的兼容性没那么好新版本要求auth参数必须是(user, password)元组你如果传入了字符串类型就会报错。第二是密码里的特殊字符被URI解析时转义出问题、#、$这些字符放在bolt://user:passwordhost这种URI格式里会被浏览器或驱动当成URI语法处理掉密码就错了。解决不要用URI内嵌密码的方式改成独立传参。具体来说就是GraphDatabase.driver(bolt://localhost:7687, auth(neo4j, your_password))让驱动库去处理认证而不是自己拼URI。另外确认一下协议头写的是bolt://而不是http://这两个协议对应完全不同的端口和握手方式一旦写错一直报认证失败。5.2 中文分词把实体名切碎了现象用户问“霸王别姬的导演是谁”实体链接返回的却是“霸王别姬的导”然后匹配不到库里任何实体。原因如果你用了jieba分词默认词典里没有“霸王别姬”这个词它会被切成“霸王/别姬”分词结果一拆散后续对实体词典的匹配就全乱了。如果你不用分词直接做字符串包含匹配又会遇到“霸王别姬”和“霸王别姬(1993)”这种不同实体名互相干扰的问题。解决通用分词工具和实体链接是两回事建议直接不走通用分词用上面4.2节的别名词典优先做最大匹配。如果非要接jieba才能满足某些意图模板就把所有电影名和人物名注入词典多一步jieba.add_word(霸王别姬, freq1000)。实测下来模板匹配方案里不接分词模块反而更稳定词边界问题完全由词典控制更好排查。5.3 重复执行导入脚本产生大量重复节点现象图谱里“霸王别姬”节点出现了三个演员节点的重复更严重各种查询结果变成重复数据大杂烩。原因数据导入脚本里用了CREATE而不是MERGE或者用MERGE但没有带完整的属性匹配条件。重复执行脚本时同样的电影和人物会被再创建一遍。这个翻车点在我国图上应该是最普通的了却经常被忽略。解决所有创建节点的地方都改成MERGE (n:Movie {title: $title})这样的形式让Neo4j自己判断是否存在完全相同的节点。MERGE在属性完全一致时不会再创建新节点但要注意它只在有属性索引的前提下效率才高所以上一章节提到的索引要先建好。导入完成后再跑一条统计MATCH (m:Movie) RETURN count(m)和源数据集的电影条数对比不一致就说明重复还在继续排查。5.4 关系方向建反导致查询返回空结果现象图谱里的节点都对Cypher也能执行但“演员演过哪些电影”这种查询就是返回空。去浏览器里用可视化看图里的节点和线看起来也正常就是查询结果不对。原因关系中箭头方向反了。常见的就是把(Person)-[:ACTED_IN]-(Movie)建成了(Movie)-[:ACTED_IN]-(Person)。在Neo4j中关系是单向的方向一旦建反你按(p:Person)-[:ACTED_IN]-(m:Movie)去找路径时根本走不通因为所有边都是反向的。解决导完数据后立刻做一次方向验证跑一条带方向的路径统计MATCH (p:Person)-[:ACTED_IN]-(m:Movie) RETURN p.name, count(m) LIMIT 20把结果和源数据集的演员作品数做对照。如果发现数量对不上优先检查导入脚本里Relationship的传参顺序。我的经验是在导数据时就在关系加上一个relation_type属性做区分方便可视化里一眼看出问题。数据量大的时候改写一个方向要重新跑全套导入脚本所以检查这一条花十分钟比事后花两小时修数据划算得多。5.5 大数据量写入时Neo4j卡死或OOM现象一次性graph.create()写入几万条关系时Neo4j界面长时间无响应日志里报OutOfMemoryError。原因graph.create()把每一批节点的创建放到同一个事务里一次性提交事务过大时超出了Neo4j JVM的可用堆内存。这种情况在数据量在几千条关系内不会暴露一旦你的电影数据增加到几百部、演员几千人关系总量上到几万条卡死就来了。解决导入脚本改成小批量事务提交。常见做法是每200条记录begin()一次、commit()一次更省事的方式是用Cypher的UNWIND批处理把所有数据以参数形式传给一条语句分批写入。示意代码如下batch [] for item in movie_relations: batch.append({title: item[title], name: item[name]}) if len(batch) 200: graph.run( UNWIND $batch AS row MATCH (m:Movie {title: row.title}) MERGE (p:Person {name: row.name}) MERGE (p)-[:ACTED_IN]-(m) , batchbatch ) batch.clear()这个UNWIND MERGE的组合是Neo4j批处理数据最常用的模式。$batch是一个Python list作为参数整体传入CypherUNWIND会把list展开成一行行数据逐个处理。相比逐条graph.create这里每200条才提交一个事务效率和稳定性都很平衡。如果你的数据量更大还可以把batch size调整到500或1000但不要一次搞太大事务提交的粒度要控制在几秒内完成这样卡死和OOM都不会再出现。6. 答辩验证与收尾用评测集和演示脚本让项目稳稳落地6.1 用QA评测集量化准确率让系统能力可复现毕设答辩最怕主观评价最不怕的就是量化数据。我习惯在项目里固定维护一份QA评测集格式很简单30到50条人工标注的问答对每条包含问句、期望意图、期望实体、答案关键词。每次改完代码跑一遍评测循环统计意图识别准确率、实体链接准确率、端到端答案准确率。答辩时直接说“在48条测试问句上端到端准确率86%”这句话比“效果感觉还不错”有说服力一百倍。评测脚本核心逻辑就是关键词包含判断def evaluate(test_cases: list): correct 0 for case in test_cases: answer chatbot.answer(case[question]) if all(kw in answer for kw in case[keywords]): correct 1 return correct / len(test_cases)注意这里all(kw in answer for kw in case[keywords])用的是子串判断而不是精确匹配因为答案模板里带了年份和书名号关键词只要出现在回复里就算命中。评测集里要故意加入三种类型的样本正常问句、带同义实体名的问句、完全超出知识范围的问题这样兜底逻辑的自由发挥也能被正确评估。6.2 源码组织与演示编排答辩现场的主动权最后说说源码和文档的组织。答辩项目最常见的丢分点是源码一团乱老师根本不愿深看。源码目录尽量按链路分层data放原始数据集和清洗脚本graph_builder放数据导入和Schema定义qa_engine放意图识别、实体链接、Cypher生成三个模块app放Web接口和前端页面。文档说明按这条路径写选题背景和技术选型、知识图谱Schema设计、数据获取清洗过程、问答链路实现、性能优化和评测方案。这样源码和文档一一对应老师提问时你能快速索引到对应模块代码。演示编排也是可以预演的。不要一上来就演示复杂问题先走平稳路径第一步查询单实体电影信息第二步查询“某演员主演电影列表”这类关系路径第三步切到Neo4j浏览器展示图谱可视化结果。每一条路径提前跑三遍确认没有偶发问题。如果老师问“遇到没收录的实体怎么办”直接把兜底回答打开真实跑一遍这也是一种能力验证。我现在做这类项目时会先搭好评测脚本再做功能相当于给系统装了仪表盘而不是凭感觉调代码这个习惯帮我省了大量调试时间。希望帮到你。本文还有配套的精品资源点击获取