基于 Flask+Vue 的智能文献管理系统：去重与检索排序实践

简介：这份答辩PPT完整呈现了基于Python+Flask+Vue的智能文献管理系统毕业设计项目，适合正在准备Web全栈方向答辩、或需要参考同类管理系统演示思路的高校学生使用。内容覆盖研究背景与意义、国内外现状、核心技术选型、需求分析与可行性分析、总体功能结构、主要功能模块（用户管理、文献类型管理、文献信息管理、文献注释管理、在线论坛、系统管理、我的信息等）、数据库设计以及系统测试过程，能够清晰展现项目的完整脉络与答辩要点。资源共1个文件，为pptx格式，压缩包大小为4.75MB，获取后可直接查看或调整。目前已有96人学习。其中对B/S架构、Flask后端框架、Vue前端界面、MySQL数据存储和协同过滤推荐等关键开发点均有涉及，既可作为答辩现场的演示底稿，也能帮助读者快速理解智能文献管理系统从设计到落地的实现思路。

1. 答辩前要把“智能”两个字落在可演示的功能上

文献管理系统是 Python 全栈项目里出现率最高的题目之一，但很多答辩版本只做到了增删改查，评审一问“智能体现在哪里”就冷场。这个题目的价值不在表单提交，而在文献导入去重和检索排序这两条看不见的主线上。

基于 Python + Flask + Vue 的智能文献管理系统，真正的增量是两件事：导入文献时自动去重，检索结果不按数据库默认顺序排，而是按标题命中、时间衰减和标签热度加权算分。Flask 负责把这两件事封装成稳定接口，Vue 负责把结果做成可操作的前后端分离页面。

下面按答辩前必须讲清的四条主线展开：Flask 后端分层与数据模型、Vue 前端与 API 的联调链路、智能检索参数标定、演示命令与追问应答。所有代码都按本地环境编写，不依赖外部服务，答辩现场断网也能完整演示。

2. Flask 后端的数据模型与去重逻辑：别让导入第一天就出重

答辩 PPT 里通常放一张分层架构图，但图下面的代码才是被追问的重灾区。Flask 开发最容易被问的三件事：应用怎么初始化、数据表怎么建、重复数据怎么处理。下面把这三件事按一个能实际运行的顺序串起来，每段代码都值得在答辩前单独跑一遍。后端以 app 工厂为入口，请求进来走 Blueprint，业务逻辑放 services，模型只负责表和关系，这种分层是最常见的 Flask 项目做法，也最容易对着架构图讲。

2.1 选型与依赖：为什么是 Flask，而不是 Django 全家桶

选型是答辩第一问，回答“因为轻量”太虚。更稳的说法是：Flask 的核心只负责路由和请求分发，数据库、登录、跨域都通过扩展按需装配，请求链路——路由进蓝图、蓝图调服务、服务操作 ORM——每一层都能在不读框架源码的情况下讲清楚。Django 的 admin、ORM、中间件开箱即用，但对一个核心逻辑只有几百行的文献系统，默认行为太多反而解释不清；答“Flask 让我们自己决定每一层做什么”是评审愿意听到的取舍。

环境准备这一步难度不大，但最容易出事故。Python 3.8 以上都能跑，建议直接装 3.10+；安装时注意让 pip 和 VSCode 的 Python 插件指向同一个解释器，避免装完 Flask 却在另一个环境里找不到模块。依赖写进 requirements.txt，平时用一条命令安装，答辩现场重装也快：

flask flask-sqlalchemy flask-cors flask-jwt-extended flask-caching jieba

这里故意不锁版本，实际项目里跑一次 pip freeze 把具体版本固定住。jieba 是中文分词，检索打分和 SimHash 去重都要靠它。想要现成的后台管理界面，扩展库里也有 Flask-Admin 这类插件，但文献系统的操作面很小，自己写蓝图反而更可控，答辩时这句主动讲出来能体现选型思考。接着按蓝图把目录搭好，从第一天就按模块拆而不是全写进 app.py，是能主动说的工程意识。

2.1.1 蓝图目录与 app 工厂，初始化只有二十行

literature-backend/ ├── app/ │ ├── __init__.py # create_app 工厂 │ ├── extensions.py # db / cors / jwt / cache 实例 │ ├── models/ │ │ ├── literature.py # 文献与标签模型 │ │ └── tag.py │ ├── api/ │ │ ├── literature.py # 文献增删改查 │ │ └── search.py # 智能检索 │ └── services/ │ ├── dedup.py # 两级去重 │ └── rank.py # 打分排序 ├── config.py └── run.py

# app/extensions.py from flask_sqlalchemy import SQLAlchemy from flask_cors import CORS from flask_jwt_extended import JWTManager db = SQLAlchemy() cors = CORS() jwt = JWTManager()

扩展实例放在独立模块里，是为了避免 app 和 models 互相导入时报循环引用。create_app 工厂负责把扩展绑定到应用、注册蓝图：

# app/__init__.py from flask import Flask from config import Config from .extensions import db, cors, jwt def create_app(config_class=Config): app = Flask(__name__) app.config.from_object(config_class) db.init_app(app) cors.init_app(app, resources={r"/api/*": {"origins": "http://localhost:5173"}}) jwt.init_app(app) from .api.literature import bp as literature_bp from .api.search import bp as search_bp app.register_blueprint(literature_bp, url_prefix="/api/literature") app.register_blueprint(search_bp, url_prefix="/api/search") return app

说明：CORS 的 origins 指向 Vue 开发服务器地址 localhost:5173，不是*；蓝图的 url_prefix 决定了前端请求路径，Vue 请求/api/literature就会命中这里。工厂函数让单测可以传入不同配置创建实例，答辩里加一句“测试环境可以换成 sqlite 内存库”就够了。入口文件 run.py 里 host 用0.0.0.0是为了能拿另一台设备连演示机访问，debug 模式在正式演示前建议关掉，否则 reloader 会开双进程，日志重复打印反而干扰讲解。

提示：CORS 的 origins 只配开发地址；生产环境同一域名由 nginx 转发后不需要 CORS。答辩时主动点出这个边界，比被动等问好得多。

2.2 文献、标签与引用关系：三张表的最小建模

数据模型是数据类问题的骨架，常见做法是拆成两张业务表加一张关联表：literature 存文献，tag 存标签，literature_tag 做多对多关联。一个文献挂多个标签、一个标签挂多篇文献，按标签筛选是所有检索功能的前置条件，这个关系不建好，后面所有聚合查询都别扭。字段定义上，能加唯一约束的地方不要手软：DOI 对期刊论文天然唯一，标题加 unique_hash 用来做精确判重。

# app/models/literature.py from datetime import datetime from ..extensions import db literature_tag = db.Table( "literature_tag", db.Column("literature_id", db.Integer, db.ForeignKey("literature.id"), primary_key=True), db.Column("tag_id", db.Integer, db.ForeignKey("tag.id"), primary_key=True), ) class Literature(db.Model): __tablename__ = "literature" id = db.Column(db.Integer, primary_key=True) title = db.Column(db.String(512), nullable=False, index=True) authors = db.Column(db.String(512), default="") abstract = db.Column(db.Text, default="") source = db.Column(db.String(256), default="") year = db.Column(db.Integer, default=0, index=True) doi = db.Column(db.String(128), unique=True) pdf_path = db.Column(db.String(256), default="") unique_hash = db.Column(db.String(64), index=True) created_at = db.Column(db.DateTime, default=datetime.utcnow) tags = db.relationship("Tag", secondary=literature_tag, back_populates="literatures") class Tag(db.Model): __tablename__ = "tag" id = db.Column(db.Integer, primary_key=True) name = db.Column(db.String(64), nullable=False, unique=True) literatures = db.relationship("Literature", secondary=literature_tag, back_populates="tags")

说明：title 给 index，因为所有查询都绕不开标题；abstract 用 Text，能塞下整段摘要；year 建索引配合排序和时间衰减；unique_hash 存 MD5，导入时先查这一列。关系里 secondary 指向关联表，back_populates 让两边都能拿到对方。字段合理性的核对，比代码量更重要：

导入方式一般有两种：CSV/Excel 批量导入，或者用爬虫脚本抓题录后走同一个导入接口。无论哪种，入库前都要过一遍下一节的去重函数，这才是“智能文献管理系统”里智能的第一层。

2.3 两级去重：MD5 抓精确重复，SimHash 抓近似重复

完全重复的文献，用 title 的 MD5 一比就命中；真正麻烦的是同一篇论文在不同数据库被改了标题里的个别字符，比如全角半角、加了个副标题。两级方案里，第一级是 MD5 精确判重，第二级是对“标题 + 摘要前几句”做 SimHash，得到 64 位指纹，再算汉明距离。距离小于等于阈值就判定为近似重复。中文文本要先分词，所以第二级用 jieba 把词拆开再逐词加权。

# app/services/dedup.py import hashlib import jieba BITS = 64 HAMMING_THRESHOLD = 3 # 汉明距离阈值，<=3 判定为近似重复 def _md5(text: str) -> int: # 取前 8 位十六进制转 int，足够做 64 位内的哈希分布 return int(hashlib.md5(text.encode("utf-8")).hexdigest()[:8], 16) def sim_hash(text: str) -> int: vector = [0] * BITS for word in jieba.cut(text): # 中文先分词 h = _md5(word) for i in range(BITS): # 按位投票 if h & (1 << i): vector[i] += 1 else: vector[i] -= 1 fp = 0 for i, v in enumerate(vector): if v > 0: fp |= (1 << i) return fp def hamming_distance(a: int, b: int) -> int: return bin(a ^ b).count("1") # 异或后数 1 的个数 def is_near_duplicate(fp_a: int, fp_b: int) -> bool: return hamming_distance(fp_a, fp_b) <= HAMMING_THRESHOLD

说明：每个词经过 MD5 得到一个整数，64 个位上出现则加一、否则减一，最后按位取正得指纹。汉明距离用 bin 再 count，是为了避开不同 Python 小版本里 bit_count 的可用性差异。阈值 3 是经验值：0～3 说明两篇在绝大多数分词位置一致，属于标题或摘要被轻微改写；4 以上通常是部分段落重叠，合并会误杀。完整实现里第二级要跟库内全部指纹比较，数据量到万级时建议按年份或第一作者分组缩小候选集——这个限制答辩时主动讲出来，比被追问好。

3. Vue 前端与 Flask API 联调：路由守卫、axios 封装和分页参数

答辩演示翻车率最高的一幕，是本地跑着默认端口，接口跨域报错，前端列表空白。Vue 项目实战里这类问题大多不在页面渲染，而在请求链路。下面把 Vite 开发代理、axios 拦截器和 Vue 路由守卫三件事扣死，再给一套前后端分页参数对照表，照着做，现场就不会出现“前端拿不到数据”。

3.1 用 Vite 搭 Vue 3 项目，并配置 /api 开发代理

创建项目用官方脚手架最快。vue-router 4 对应 Vue 3，element-plus 负责表格和分页组件，axios 负责请求。三条命令装完，是这几年 Vue 项目里最标准的起步动作：

npm create vite@latest literature-web -- --template vue cd literature-web npm install npm install vue-router@4 element-plus axios

说明：模板默认给的是组合式 API 写法，和后面代码风格一致。装完之后在 vite.config.js 里配置 dev server 代理，让前端把/api开头的请求转发到 Flask 的 5000 端口：

// vite.config.js import { defineConfig } from 'vite' import vue from '@vitejs/plugin-vue' export default defineConfig({ plugins: [vue()], server: { port: 5173, proxy: { '/api': { target: 'http://127.0.0.1:5000', // Flask 监听地址 changeOrigin: true } } } })

说明：代理生效后，前端代码里所有请求都写相对路径/api/...，浏览器根本看不到 5000 端口，从根上避开 CORS 预检。target 指向 Flask 监听地址，changeOrigin 让请求头里的 Host 改成目标地址，防止后端按 Host 做判断时出问题。如果坚持用 Flask-CORS 直接放开跨域，origins 参数一定要指向前端地址而不是写*。

注意：vite.config.js 改动后必须重启 dev server，代理配置不会热更新。这句话能省掉现场至少十分钟排查时间。

3.2 axios 实例统一注入 JWT，401 自动跳登录

登录接口返回的 token 每次都要塞进请求头，逐页复制粘贴最容易漏。把 axios 封装成单例，请求拦截器统一加 Authorization，响应拦截器统一处理 401，是 Flask + Vue 前后端分离项目的常规做法。演示时一旦 token 过期，页面自动跳回登录页，反而是个展示“鉴权闭环”的机会。

// src/utils/request.js import axios from 'axios' import { ElMessage } from 'element-plus' const request = axios.create({ baseURL: '/api', timeout: 8000 // 8 秒超时，防止慢接口卡死演示 }) request.interceptors.request.use((config) => { const token = localStorage.getItem('lit_token') if (token) { config.headers.Authorization = `Bearer ${token}` } return config }) request.interceptors.response.use( (resp) => resp.data, (err) => { if (err.response && err.response.status === 401) { localStorage.removeItem('lit_token') window.location.href = '/login' } else { ElMessage.error((err.response && err.response.data && err.response.data.message) || '请求失败') } return Promise.reject(err) } ) export default request

说明：baseURL 写成/api配合 3.1 的代理，页面里调request.get('/literature')实际发到/api/literature；timeout 8000 是毫秒，避免某个慢接口把演示卡死。响应拦截器直接返回 resp.data，业务代码拿到的就是 Flask 端 jsonify 出来的字典，省一层包壳。401 分支同时清 token 和跳登录页，后端由@jwt_required()兜底，前端这层只是体验优化，不是安全边界——这个分工要在答辩时说清楚。

3.3 Vue 路由守卫：未登录进不了文献页

Vue 路由的 meta 字段可以标注“这个页面需要登录”。守卫里每次跳转前查一下本地 token，没有就送回登录页。评审问“前端怎么防未授权访问”时，正确答法是：前端路由守卫只负责体验，真正的权限校验在 Flask，两层都得有。

// src/router/index.js import { createRouter, createWebHistory } from 'vue-router' const routes = [ { path: '/login', component: () => import('../views/Login.vue') }, { path: '/articles', component: () => import('../views/ArticleList.vue'), meta: { requiresAuth: true } }, { path: '/search', component: () => import('../views/Search.vue'), meta: { requiresAuth: true } } ] const router = createRouter({ history: createWebHistory(), routes }) router.beforeEach((to) => { const token = localStorage.getItem('lit_token') if (to.meta.requiresAuth && !token) { return '/login' // 中断当前导航，回登录页 } }) export default router

说明：requiresAuth 是路由元信息，守卫返回/login会中断当前导航。想演示角色权限，在路由里加 roles 字段，守卫里再比对登录接口返回的角色字段即可。createWebHistory 是 HTML5 history 模式，地址栏干净，部署时 nginx 记得配 try_files 回退到 index.html，否则刷新子路由会 404。

3.4 文献列表分页：前端参数与后端 paginate 的对应

分页参数是必问项。前端每翻一页发一次请求，后端用 SQLAlchemy 的 paginate 直接切页，两边参数名约定一致才不会出现“第二页数据对不上”。前端组件里只维护 page、page_size、keyword 三个响应式参数：

<script setup> import { ref, onMounted } from 'vue' import request from '../utils/request' const params = ref({ page: 1, page_size: 10, keyword: '' }) const total = ref(0) const rows = ref([]) async function fetchList() { const data = await request.get('/literature', { params: params.value }) rows.value = data.items total.value = data.total } onMounted(fetchList) </script>

后端对应读取参数并做约束：

# app/api/literature.py from flask import Blueprint, request, jsonify from ..extensions import db from ..models.literature import Literature bp = Blueprint("literature", __name__) @bp.get("") def list_literature(): page = request.args.get("page", 1, type=int) page_size = request.args.get("page_size", 10, type=int) keyword = request.args.get("keyword", "").strip() if page_size > 100: # 硬上限，防止一次拉全表 page_size = 100 query = Literature.query if keyword: like = f"%{keyword}%" query = query.filter( db.or_(Literature.title.ilike(like), Literature.abstract.ilike(like)) ) pagination = query.order_by(Literature.year.desc(), Literature.id.desc()) \ .paginate(page=page, per_page=page_size, error_out=False) items = [{ "id": lit.id, "title": lit.title, "authors": lit.authors, "year": lit.year, "tags": [tag.name for tag in lit.tags] } for lit in pagination.items] return jsonify({"items": items, "total": pagination.total, "page": pagination.page, "page_size": pagination.per_page})

说明：request.args.get 的第二个参数是默认值，第三个参数 type=int 负责类型转换，前端传 page=abc 也不会 500；error_out=False 让页码越界时返回空列表而不是 404。ilike 对 MySQL、PostgreSQL、SQLite 都兼容大小写不敏感匹配。page_size 设 100 的硬上限，防止有人一次拉全表。前端 el-pagination 拿到 total 后，把 current-page 绑 page、page-size 绑 page_size 即可：

提示：前后端参数命名不一致是联调里最常见的低级错误，约定 page、page_size 并写进接口文档，比在代码里各写各的省事得多。

4. 智能检索的排序公式与参数标定：标题权重、时间衰减和标签热度

检索是这套系统里智能浓度最高的模块，也最容易被深挖。不能说“用了搜索”就完事，要把排序公式写成能算的代码：最终得分由三部分加权合成——关键词在标题和摘要里的命中次数、论文年份折算的时间衰减、标签在全库的热度。下面给出公式、默认参数和调参方法，并说明每个参数改动的代价。

4.1 打分公式：三路特征加权相加，先统一量纲

公式本身只有三行，难点在权值。text_score 里标题命中乘 3、摘要命中乘 1，是因为标题里的关键词比摘要里的更接近文章主题；time_decay 用半衰期函数折算到 0～1 区间，让老论文不至于因为年份被完全挤出首页；tag_heat 用对数压缩，避免某个超大标签把所有结果顶上来。三个特征先统一到相近量纲，再按业务优先级配权重，这是参数设计的关键：

# app/services/rank.py import math def text_score(title_hits: int, abstract_hits: int) -> float: return title_hits * 3.0 + abstract_hits * 1.0 # 标题权重 3，摘要权重 1 def time_decay(year: int, current_year: int, half_life: int = 5) -> float: if year <= 0: return 0.0 return math.pow(0.5, (current_year - year) / half_life) # 半衰期默认 5 年 def tag_heat(tag_count: int, avg_tag_count: float) -> float: if avg_tag_count <= 0: return 0.0 return math.log1p(tag_count) / math.log1p(avg_tag_count) # 对数压缩热度 def final_score(title_hits, abstract_hits, year, current_year, tag_count, avg_tag_count): return (2.0 * text_score(title_hits, abstract_hits) + 1.2 * time_decay(year, current_year) + 0.8 * tag_heat(tag_count, avg_tag_count))

说明：math.pow(0.5, age / half_life) 是指数时间衰减，half_life=5 表示论文发表满 5 年时间权重降一半，这个口径对文献比新闻类内容更合理；log1p 对 0 安全，标签数为 0 时不会抛数学错误。三个总权重 2.0/1.2/0.8 的顺序也即优先级：主题相关大于时效大于热度。调权重不是拍脑袋，而是拿一组标注好的查询，看前十条结果的变化。

4.2 参数表：默认值、调整方向和答辩说辞

表格不是让背的，是让“改一个参数、跑一批查询、看排序变化”这个流程在答辩前真的走一遍。例如把 half_life 从 5 改成 2，同一关键词下 2018 年以前的论文会整体后退；把标签权重提到 1.5，热门标签下的长尾文献会明显前移。能在演示时现场改参数并解释排序变化，比背公式有说服力得多。

4.3 检索接口落地：LIKE 粗筛候选集，Python 精排

数据量在几千条时不需要上 Elasticsearch，常见做法是先用 LIKE 把含关键词的文献圈成候选集，设 500 条上限，再逐条算分排序。这个“粗筛 + 精排”的两段式结构，本身就是答辩时能讲清楚的架构回答：

# app/api/search.py from flask import Blueprint, request, jsonify from ..extensions import db from ..models.literature import Literature from ..services.rank import final_score bp = Blueprint("search", __name__) @bp.get("") def search(): q = request.args.get("q", "").strip() if not q: return jsonify({"items": [], "total": 0}) like = f"%{q}%" candidates = (Literature.query .filter(db.or_(Literature.title.ilike(like), Literature.abstract.ilike(like))) .limit(500).all()) # 候选集里的平均标签数，作为 tag_heat 的分母 avg_tags = (sum(len(lit.tags) for lit in candidates) / len(candidates)) if candidates else 1.0 scored = [] for lit in candidates: title_hits = lit.title.lower().count(q.lower()) abstract_hits = lit.abstract.lower().count(q.lower()) score = final_score( title_hits, abstract_hits, lit.year, current_year=2025, tag_count=len(lit.tags), avg_tag_count=avg_tags ) scored.append((score, lit)) scored.sort(key=lambda x: x[0], reverse=True) items = [{ "id": lit.id, "title": lit.title, "year": lit.year, "authors": lit.authors, "score": round(score, 4), "tags": [t.name for t in lit.tags] } for score, lit in scored[:20]] return jsonify({"items": items, "total": len(scored)})

说明：avg_tags 由候选集算平均，避免每次都聚合全库；scored[:20] 限制回传条数，前端展示更快。current_year 这里写 2025 是为了演示直观，正式代码建议用 datetime 动态取年份，防止过了一年结果全部衰减为 0，这是答辩容易踩的细节。total 返回的是候选集长度而不是全库命中数，前端文案要按“排序后的总数”来展示。

4.4 检索缓存与热度闭环：给详情页加 read_count

同一个词反复搜，响应没必要重算。Flask-Caching 的 SimpleCache 在演示规模下够用，把热门查询结果缓存 300 秒，生产再换 Redis 后端。缓存键里要带查询词和分页，避免第二页拿到第一页的缓存。热度侧，给 Literature 加一个 read_count 字段，详情页打开时加一，tag_heat 的输入就可以换成标签下文献的平均阅读量，形成“越看越相关”的闭环，这是答辩里能体现智能迭代的点：

# app/extensions.py 追加 cache 实例 from flask_caching import Cache cache = Cache() # create_app 里追加一行配置 # 演示态用 SimpleCache，生产换 RedisCache cache.init_app(app, config={ "CACHE_TYPE": "SimpleCache", "CACHE_DEFAULT_TIMEOUT": 300 })

# app/api/search.py 追加热点标签接口 from sqlalchemy import func from ..models.literature import literature_tag from ..models.tag import Tag @bp.get("/hot") @cache.cached(timeout=300, key_prefix="hot_tags") def hot_tags(): rows = (db.session.query( Tag.name, func.count(literature_tag.c.literature_id).label("cnt")) .join(literature_tag, literature_tag.c.tag_id == Tag.id) .group_by(Tag.id) .order_by(func.count(literature_tag.c.literature_id).desc()) .limit(10).all()) return jsonify([{"name": name, "count": cnt} for name, cnt in rows])

说明：key_prefix 固定为 hot_tags，热点接口无分页参数，300 秒内不会重复查库；SimpleCache 是进程内缓存，多进程或多机部署时要换 RedisCache，这个边界要主动写在技术选型页里。func.count 聚合出的 cnt 直接给前端做标签云；如果 read_count 接进来，把 order_by 改成按阅读量累计值排序即可。

提示：缓存只适合演示口径。临时改了检索参数后记得重启后端进程，SimpleCache 不像 Redis 那样方便按前缀清理。

5. 答辩现场的验证脚本与高频追问应答

5.1 一条命令验证导入、去重与检索

演示最稳的顺序是：启动后端、启动前端、登录、导入样本、展示检索排序、重复导入证明去重。后端和前端分别起在 5000 和 5173，先跑一段 curl 确认接口链路没问题：

cd literature-backend python run.py & sleep 2 curl -s "http://127.0.0.1:5000/api/literature?page=1&page_size=3" | python -m json.tool

说明：run.py 放后台运行，sleep 2 等端口起来；curl 接 python -m json.tool 把 JSON 格式化，屏幕上直接能看到 items 和 total，比开浏览器 F12 更快。带登录态的检索验证用一段拼接命令：

TOKEN=$(curl -s -X POST http://127.0.0.1:5000/api/auth/login \ -H "Content-Type: application/json" \ -d '{"username":"admin","password":"admin123"}' \ | python -c "import sys,json;print(json.load(sys.stdin)['access_token'])") curl -s "http://127.0.0.1:5000/api/search?q=深度学习" \ -H "Authorization: Bearer $TOKEN" | python -m json.tool

说明：登录接口由 auth 蓝图提供，返回体里带 Flask-JWT-Extended 默认的 access_token 字段，取出来塞进环境变量，第二段 curl 用 Bearer 方式传 token。JWT 过期时间别设太长，答辩半小时足够，30 分钟是个合理值；过期后前端自动跳登录，正好演示 401 拦截逻辑。

5.2 答辩前的自检清单

这张清单建议做成演示前 10 分钟的热身流程，而不是当场才跑。每项的预期结果都是可观察的：日志、页面、数量、状态码、排序、响应时间，六个维度正好覆盖架构、功能、安全、算法四个答辩方向。

5.3 被追问时拿得出手的三个边界口径

“SimHash 阈值为什么是 3”：0～3 表示两篇文本在绝大多数分词维度上一致，对应标题或摘要被轻微改写的场景；4 以上通常是局部段落重叠，合并会误杀。准备 50 条真实样本两两计算距离画一张分布图，哪个阈值分界最清晰就用哪个，这句答法比“网上说 3”扎实。

“几千条数据为什么不上 Elasticsearch”：当前查询延迟来自 500 条候选集的 Python 打分，秒级内能返回；ES 的倒排索引优势在百万级数据才明显。重点是接口层把 search 封装成独立蓝图，将来把 LIKE 粗筛换成 ES 查询，前端零改动，这个可替换性就是设计的价值。

JWT 的 SECRET_KEY 别写死在代码里，从环境变量读；演示时故意把过期时间设短，展示一次 401 跳登录，反而证明鉴权链路是通的。演示前把三组默认参数——汉明距离 3、半衰期 5、总权重 2.0/1.2/0.8——抄在便签上贴到屏幕边缘，被追问时直接念数值，比临场翻代码稳得多。

本文还有配套的精品资源，点击获取