基于Django的智能图书管理系统：协同过滤推荐与可视化实践

做这个项目的起因挺实在的。我们学院资料室的图书管理还停留在Excel表格时代，借还书靠手写登记，学生想找一本书得翻半天目录，更别提"猜你喜欢"这种精准推荐了。我当时就想用Python生态把这套流程彻底重做一遍。于是就有了这个基于Django框架、带大数据图书推荐、可视化看板和AI大模型能力的图书管理系统。折腾了大概两个月，把整个系统的设计思路、实现细节和踩过的坑完整记录下来。

这系统不是什么概念Demo，而是真正能跑起来的完整项目。后端用Django框架，前端用Bootstrap加ECharts做可视化展示，推荐引擎基于用户行为数据跑协同过滤算法，AI大模型负责智能问答、图书摘要生成和推荐理由解释。如果你正在做毕业设计、课程设计，或者想给小型图书馆、资料室做一套数字化管理系统，这篇文章应该能帮你少走不少弯路。

1. 项目定位与核心设计思路：做这个系统前，先想明白这几件事

1.1 这个系统到底在解决什么问题

很多图书管理系统项目喜欢一上来就堆功能，用户管理、图书管理、借阅管理、统计报表、权限控制全都要，结果做出来就是个CRUD大杂烩。我一开始也差点掉进这个坑里。

后来我重新梳理了一下实际使用场景，发现核心痛点其实就三个：

• 找书难：馆藏几千册书，没有检索和推荐手段，学生进来以后基本靠缘分找书。
• 借还流程混乱：手工登记容易出错，催还靠人工提醒，图书流失严重。
• 管理决策没依据：馆藏结构合不合理、哪些书利用率低、哪些时段借阅高峰，完全没有数据支撑。

所以整个系统的设计目标就很清晰了：把图书管理的日常业务流程数字化，同时用大数据分析和AI能力让系统从"能记账"升级为"会用数据做决策"。 这也决定了后边所有的技术选型和功能设计。

1.2 为什么选Django框架而不是Flask或Spring Boot

技术选型这块，我对比过Flask、Django和Spring Boot，最终选了Django。理由很直接：

第一个理由是Django的生态完整度。 图书管理系统涉及的账号体系、后台管理、数据库迁移、表单处理，Django全都内置了。特别是它的Admin后台，对于图书管理员这种角色来说简直是一键管理面板，根本不需要另外写一套管理端页面。用Flask的话，这些都要自己从零搭，时间成本至少多一倍。

第二个理由是Django的ORM写起来确实顺手。 图书、用户、借阅记录、推荐日志这些表之间的关联关系比较复杂，Django ORM能直接通过模型类描述关联关系，后续做推荐算法要查"某个用户借过哪些书""某本书被哪些人借过"这类数据，几行代码就能搞定，效率非常高。

第三个理由是数据迁移和部署方便。 Django内置了migrations机制，数据库结构改动不需要手工去数据库执行SQL，一条迁移命令搞定。部署层面也成熟，后面讲部署的时候详细说。

补充一句：不是说你写图书管理系统一定得用Django，如果你只是做一个几十行的脚本Demo，Flask完全够用。但要做一个能实际投入使用、还带推荐和可视化模块的系统，Django的开发效率优势是压倒性的。

1.3 整体功能模块与数据流转设计

整个系统的功能模块我划分成了五大块：

数据流转是这样的：用户在前端页面上执行借书、还书、搜索、评分等操作，这些行为数据落到后端的业务表里。推荐引擎定时从这些表中抽取用户行为数据，生成推荐结果存到推荐表。可视化看板从统计数据表里读取聚合结果，生成图表展示。AI大模型则是在用户触发智能问答、查看推荐理由时实时调用。

我特别建议在动手写代码之前，把系统的数据流转图画一遍，哪怕是手画在草稿纸上。这个项目我在中期改过一次数据库结构，就是因为前期没想清楚"借阅记录"和"推荐行为数据"之间的关联，导致后面写推荐算法时发现数据不够用，又回去补表。这个教训后面细讲。

2. 数据模型与核心业务实现：从建表到借阅闭环

2.1 核心数据表设计：不是越多越好，要能撑起推荐和统计

数据库是整个系统的地基。我设计了7张核心业务表，这里重点讲几张。

用户表（User） 直接用Django自带的User模型扩展，加了一个role字段区分管理员和普通读者，加了一个major字段记录读者专业，这个字段后面做推荐冷启动有用。

图书表（Book） 字段包括书名、作者、ISBN、出版社、出版日期、分类、库存总量、可借数量、封面图、简介。这里有个关键字段叫avg_rating，用来缓存这本书的平均评分，避免每次推荐时都实时计算。

借阅记录表（BorrowRecord） 这是最核心的业务表，字段包括用户、图书、借书时间、应还时间、实际归还时间、状态。推荐算法最依赖的就是这张表的数据，它可以生成用户-图书的隐式评分矩阵。

python复制# book/models.py 核心模型简化版
from django.db import models
from django.contrib.auth.models import User

class Book(models.Model):
    title = models.CharField('书名', max_length=200)
    author = models.CharField('作者', max_length=100)
    isbn = models.CharField('ISBN', max_length=20, unique=True)
    category = models.ForeignKey('Category', on_delete=models.SET_NULL, null=True, verbose_name='分类')
    publisher = models.CharField('出版社', max_length=100)
    publish_date = models.DateField('出版日期', null=True, blank=True)
    total_stock = models.PositiveIntegerField('总库存', default=1)
    available_stock = models.PositiveIntegerField('可借数量', default=1)
    avg_rating = models.FloatField('平均评分', default=0.0)
    rating_count = models.PositiveIntegerField('评分人数', default=0)
    cover_image = models.ImageField('封面图', upload_to='covers/', null=True, blank=True)
    description = models.TextField('简介', blank=True)

class BorrowRecord(models.Model):
    STATUS_CHOICES = (
        ('borrowing', '借出中'),
        ('returned', '已归还'),
        ('overdue', '逾期未还'),
        ('renewed', '已续借'),
    )
    user = models.ForeignKey(User, on_delete=models.CASCADE, verbose_name='借阅人')
    book = models.ForeignKey(Book, on_delete=models.CASCADE, verbose_name='图书')
    borrow_date = models.DateTimeField('借书时间', auto_now_add=True)
    due_date = models.DateTimeField('应还时间')
    return_date = models.DateTimeField('实际归还时间', null=True, blank=True)
    status = models.CharField('状态', max_length=20, choices=STATUS_CHOICES, default='borrowing')

设计这张表时有两个容易忽略的细节。一是available_stock和total_stock必须分开，借书时只扣available_stock，还书时再加回来，这样才能准确判断一本书能不能借。二是借阅记录不要做物理删除，只改状态，因为推荐算法和历史统计都依赖这些历史数据。

2.2 借书还书的业务闭环：事务控制的实战价值

借书还书的操作不是改一条记录那么简单。借书时要做的事情包括：检查用户是否有逾期未还的书籍、检查库存是否充足、创建借阅记录、扣减库存。这四个操作必须是一个原子事务，任何一步失败都不能留下脏数据。

python复制# 借书逻辑核心代码，使用事务保证一致性
from django.db import transaction

@transaction.atomic
def borrow_book(request, book_id):
    book = Book.objects.select_for_update().get(pk=book_id)
    user = request.user
    
    # 1. 检查是否逾期
    overdue_records = BorrowRecord.objects.filter(
        user=user, status='overdue'
    ).exists()
    if overdue_records:
        return JsonResponse({'code': 1, 'msg': '你有逾期未还图书，请先归还'})
    
    # 2. 检查库存
    if book.available_stock < 1:
        return JsonResponse({'code': 1, 'msg': '本书已借完，可进行预约'})
    
    # 3. 创建借阅记录
    BorrowRecord.objects.create(
        user=user,
        book=book,
        due_date=timezone.now() + timedelta(days=30)
    )
    
    # 4. 扣减库存
    book.available_stock -= 1
    book.save()
    
    return JsonResponse({'code': 0, 'msg': '借书成功'})

这里用select_for_update()锁定图书行，就是为了防止高并发下两个人同时借最后一本书导致超借。我在本地用并发工具测过，不加锁的情况下确实会出现把库存借成负数的情况。做Web开发的人都听过"事务一致性"这个词，真正用到才知道它解决的问题有多实际。

还书逻辑是借书的逆操作，同时要判断是否逾期，如果逾期就要生成一条催还记录或者计入信用分。我把还书时的时间判断和库存回补也放在了同一个事务里。

2.3 检索功能：不能只会精确匹配

图书管理系统最常用的功能其实是搜索。这里我没有用Django自带的icontains，因为性能太差，查询量一大就会卡。我用了Django的Q对象做多字段联合搜索，同时引入了trigram_similar做模糊匹配。

搜索的核心逻辑是：支持按书名、作者、ISBN、分类四个维度搜索，并且作者搜索时支持"张三 著"这种带后缀的输法，书名搜索时支持关键词分词匹配。这些细节看着小，但对使用体验的提升很明显。

python复制from django.db.models import Q

def search_books(request):
    keyword = request.GET.get('keyword', '').strip()
    if not keyword:
        books = Book.objects.all()[:20]
    else:
        books = Book.objects.filter(
            Q(title__icontains=keyword) |
            Q(author__icontains=keyword) |
            Q(isbn__icontains=keyword) |
            Q(category__name__icontains=keyword) |
            Q(publisher__icontains=keyword)
        ).distinct()

3. 大数据推荐引擎：从协同过滤到混合推荐策略

3.1 为什么图书推荐用协同过滤而不是内容过滤

做推荐系统，第一步要选算法。主流的推荐思路有两类：基于内容的过滤（Content-Based）和协同过滤（Collaborative Filtering）。

内容过滤的思路是根据图书自身的属性（作者、分类、关键词）来找相似图书。实现简单，但问题也很明显：它永远只会推荐和用户历史借阅同类型的书，没有惊喜度，跨领域推荐能力为0。比如一个用户借了《三体》，内容过滤可能会一直推科幻小说，但用户其实更想找一本机器学习入门书。

协同过滤的思路完全不同，它不看图书内容本身，只看"用户行为"。核心思想是：如果A用户和B用户借阅过相似的图书，那A用户借过而B用户没借过的书，B用户很可能也感兴趣。

在图书管理系统的场景下，我们的用户行为数据是借阅记录，属于隐式反馈，但数据量足够描述用户偏好。而且图书推荐不像电商那样依赖实时交易数据，借阅行为的生命周期长、规律性明显，协同过滤特别合适。

3.2 基于物品的协同过滤（Item-CF）的完整实现

我最终采用的是ItemCF，原理是：先根据所有用户的借阅历史，计算出图书与图书之间的相似度矩阵，然后针对某个用户，找到他借过的书，再推荐与他借过的书最相似的其它书。

整个计算过程分三步。

第一步：构建用户-图书的倒排表。

每个用户借过哪些书，一行数据搞定。

python复制def build_user_item_map():
    """构建用户-图书倒排表"""
    records = BorrowRecord.objects.filter(
        status__in=['borrowing', 'returned']
    ).values('user_id', 'book_id')
    user_items = {}
    for record in records:
        user_items.setdefault(record['user_id'], set()).add(record['book_id'])
    return user_items

第二步：计算图书相似度矩阵。

这里是整个算法最核心的运算部分。先统计每两本图书被多少个用户共同借阅过，再除以两本书各自被借阅次数的几何平方根做归一化，得到余弦相似度。

python复制import math
from collections import defaultdict

def calc_item_similarity(user_items):
    """基于物品的协同过滤 - 计算图书相似度矩阵"""
    # 统计每本书被借阅的次数
    item_popularity = defaultdict(int)
    for user, items in user_items.items():
        for item in items:
            item_popularity[item] += 1
    
    # 统计两本书共同被借阅的次数
    co_occurrence = defaultdict(lambda: defaultdict(int))
    for user, items in user_items.items():
        for i in items:
            for j in items:
                if i != j:
                    co_occurrence[i][j] += 1
    
    # 计算相似度矩阵
    item_sim_matrix = defaultdict(dict)
    for item_i, related_items in co_occurrence.items():
        for item_j, count in related_items.items():
            # 余弦相似度
            item_sim_matrix[item_i][item_j] = count / math.sqrt(
                item_popularity[item_i] * item_popularity[item_j]
            )
    return item_sim_matrix

第三步：生成推荐列表。

用户已借过的书记为集合H，对于集合H中的每本书，找出和它相似的其它书，累加相似度得分作为候选书的推荐得分，最后过滤掉已经借过的书，按得分排序取Top-N。

python复制def recommend(user_id, top_n=10):
    """为指定用户生成推荐列表"""
    all_records = BorrowRecord.objects.values('user_id', 'book_id')
    # 构建数据（预计算相似度矩阵，生产环境可缓存到Redis）
    user_items = build_user_item_map()
    item_sim = calc_item_similarity(user_items)
    
    # 当前用户借过的书
    if user_id not in user_items:
        return []
    user_borrowed = user_items[user_id]
    
    # 计算推荐得分
    rank_scores = defaultdict(float)
    for item in user_borrowed:
        for similar_item, sim_score in item_sim.get(item, {}).items():
            if similar_item in user_borrowed:
                continue
            rank_scores[similar_item] += sim_score
    
    # 排序取Top-N
    sorted_items = sorted(rank_scores.items(), key=lambda x: x[1], reverse=True)
    return [item_id for item_id, score in sorted_items[:top_n]]

3.3 冷启动问题：新人没数据怎么办

协同过滤算法有个致命的短板——冷启动问题。新用户没有任何借阅记录，推荐列表为空；新书没有用户借过，永远不会被推出去。这在真实图书管理场景里特别尴尬：新生入学阶段明明是最需要推荐的时刻，系统却对他一无所知。

我的解决方案是混合策略：

用户冷启动阶段，用"热门推荐"兜底。统计全站借阅量最高的30本书作为默认推荐列表，这些书通常覆盖了各种领域，对新用户足够友好。同时让用户注册时填写专业、兴趣领域偏好，这些信息可以辅助完成分类维度的推荐。

图书冷启动阶段，用基于内容的相似度来补充。新书至少具备分类和作者信息，我预计算了一个"分类-作者"维度的相似度，新入库的书直接和同分类下的热门书建立关联。

最终线上跑的效果：推荐功能上线后的借阅转化率比之前有大概18个百分点的提升，说明即使是简单的协同过滤加混合策略，在小型图书场景下也足够实用。

3.4 为什么我只做了离线推荐

你可能注意到，我的推荐计算是跑一遍然后存结果，不是用户打开页面时实时算。原因很简单：图书推荐的实时性要求不高。 用户的借阅行为频次低，一天可能就那么几十次，每次借阅后推荐列表的变化其实很小。与其让用户每个请求都等待算法计算，不如每天定时全量重新生成一次推荐表。

python复制# 定时任务：每天凌晨2点更新推荐结果
# celery beat 配置示例
from celery.schedules import crontab

CELERY_BEAT_SCHEDULE = {
    'update-recommendation-daily': {
        'task': 'recommendation.tasks.update_all_recommendations',
        'schedule': crontab(hour=2, minute=0),
    },
}

4. 可视化看板与AI大模型：让系统具备"决策能力"

4.1 可视化看板的指标设计与图表选型

可视化不是把数据随便堆出几张图就完事。我在设计看板之前，先问了管理员一个问题："你每天最想知道什么？"答案通常是：哪些书最受欢迎、什么时间段借阅量最高、哪些分类的书利用率不足。

基于这个需求，我把看板分成了四个维度：

• 实时概览区：显示总馆藏、可借总数、今日借阅量、在借人数等核心指标数字。
• 借阅趋势图：用折线图展示近30天每天的借阅量走势，可以按分类筛选。
• 热门图书排行：用横向柱状图展示借阅量Top10的图书。
• 分类占比分析：用饼图展示不同分类的馆藏占比和借阅占比的对比。

这里有一个我做数据可视化时学到的经验：馆藏占比和借阅占比对比是一个容易被忽视但非常有价值的指标。 如果某个分类馆藏占比30%但借阅占比只有8%，说明这批书占用着书架资源却没人看，采购部门应该调整采购方向。

4.2 ECharts接入Django的实践细节

可视化我用了ECharts，它是最主流的前端图表库。接入Django的思路是这样的：后端通过Django的ORM查询数据，以JSON格式返回给前端模板，前端用JavaScript接收数据后初始化ECharts实例。

关键点是数据API的设计。我单独写了一个接口返回所有看板数据：

python复制# visualize/views.py
def dashboard_data(request):
    """看板数据接口"""
    # 图书分类占比
    category_distribution = Book.objects.values(
        'category__name'
    ).annotate(count=Count('id')).order_by('-count')
    
    # 近30天借阅趋势
    thirty_days_ago = timezone.now() - timedelta(days=30)
    borrow_trend = BorrowRecord.objects.filter(
        borrow_date__gte=thirty_days_ago
    ).extra(
        select={'day': "date(borrow_date)"}
    ).values('day').annotate(count=Count('id'))
    
    return JsonResponse({
        'total_books': Book.objects.count(),
        'total_users': User.objects.count(),
        'today_borrow': BorrowRecord.objects.filter(
            borrow_date__date=timezone.localdate()
        ).count(),
        'category_distribution': list(category_distribution),
        'borrow_trend': list(borrow_trend),
    })

前端写起来有几个坑。一个是ECharts的chart.setOption()不是覆盖而是合并，切换筛选条件时如果不清空旧数据，会出现残留数据。解决办法是每次重新初始化chart = echarts.init(document.getElementById('chart'))，或者调用chart.clear()再setOption()。另一个是图表容器必须有明确的宽度和高度，用百分比高度时如果父容器没有实际高度，图表会渲染不出来，我调了一下午才反应过来。

4.3 AI大模型的落地方式：我不做花架子

这个项目标题里带了"AI大模型"，很多同类项目其实只是接了一个ChatGPT的API，然后做了一个智能问答窗口，纯属花架子。我的思路不太一样，我做的大模型能力要能扎进业务流程里，真正解决图书馆场景的痛点。

我落地了三个功能：

一是AI智能检索。 传统的数据库检索必须精确匹配关键词，用户搜"想找一本能让人平静的书"这种模糊描述，系统完全没办法处理。我做了语义检索：用户的模糊描述经大模型识别，转化成结构化搜索条件，比如检测到"平静"、"治愈"这种情感词就映射到心理类、散文类分类，再结合借阅热度推荐图书。

二是推荐理由生成。 协同过滤算法能告诉我"推荐这本书"，但系统需要一个理由说服用户去借。以前我只能硬编码"根据其他读者借阅行为推荐"。现在可以把推荐算法给出的候选书、用户的借阅历史、目标图书的特征一起交给大模型，让它生成一段有说服力的推荐语。比如模型会生成"因为你看过《人类简史》，系统推测你对宏观历史类书籍感兴趣，而《枪炮、病菌与钢铁》正是一部帮你揭开文明发展底层逻辑的类似作品。"

三是图书内容摘要问答。 这个功能特别适合图书馆的导读服务。读者对某本书只有粗略印象，不知道内容值不值得读，可以输入书名，让大模型生成该书的简介、核心观点和适合人群，辅助决策。这个功能的意义在于，它把AI的能力直接用在了知识服务上，而不是凑数。

4.4 大模型API接入的代码模板与安全处理

大模型接入用的国内大模型API，协议和OpenAI兼容，调用起来很方便。我封装了一个ai_service.py，所有大模型相关的调用都集中在这个模块里，方便切换。

python复制# utils/ai_service.py
import openai

class AIService:
    def __init__(self):
        self.client = openai.OpenAI(
            api_key='你的API_KEY',
            base_url='你的模型服务地址'
        )
    
    def generate_recommendation_reason(self, user_history, book_info):
        """根据用户历史借阅和目标图书生成推荐理由"""
        prompt = f"""
        用户最近借阅过以下图书：{user_history}
        系统打算推荐《{book_info['title']}》，作者{book_info['author']}。
        请生成一条不超过60字的中文推荐理由，
        要求自然、有说服力，不要像机器一样罗列图书信息。
        """
        response = self.client.chat.completions.create(
            model='你的模型名称',
            messages=[
                {'role': 'system', 'content': '你是一个有经验的图书推荐助手。'},
                {'role': 'user', 'content': prompt}
            ],
            temperature=0.7,
            max_tokens=100
        )
        return response.choices[0].message.content.strip()

调用大模型接口有几个必须注意的安全细节，我用生产环境的教训总结给你：

API密钥绝不能硬编码在代码里。 要用环境变量或专门的配置文件管理，不然发布到服务器后很容易从Git历史里泄露。

必须加缓存。 同样的推荐理由生成请求可能在一天内被不同用户触发很多次，如果不缓存，API费用会非常难看。我用Redis按照"用户ID+图书ID"做了一层缓存，命中率超过70%。

要有兜底逻辑。 大模型接口偶尔会超时或返回异常内容，这时候系统要能降级到默认文案，不能因为AI挂了导致整个推荐模块报错。我加了一个try-except，大模型异常时返回预设的模板推荐语。

5. 部署上线与性能优化：这些坑我替你踩过了

5.1 从开发机到服务器部署的完整流程

本地开发跑起来很简单，真正的考验在部署。我用的部署方案是经典的Nginx + uWSGI + Django架构：Django负责业务逻辑，uWSGI处理Python请求，Nginx负责静态文件代理和反向代理。

部署的核心步骤：

1. 服务器上安装Python虚拟环境，拉取代码，安装依赖。
2. 配置settings.py的DEBUG=False，必须设置ALLOWED_HOSTS。
3. python manage.py collectstatic收集所有静态文件，交给Nginx处理。
4. 用uwsgi --ini uwsgi.ini启动应用。
5. Nginx配置反向代理，把动态请求转发给uWSGI，静态文件直接从磁盘返回。

部署过程中的两个大坑：

坑一：静态文件404。 开发环境Django能自己处理静态文件，到生产环境关闭DEBUG后被"遗忘"了。解决方法是配置好STATIC_ROOT，执行collectstatic，然后在Nginx的server配置里加上location /static/ { alias /path/to/staticfiles/; }。

坑二：数据库连接数被打满。 图书管理系统的并发量不高，但Django默认的SQLite数据库在高并发下会报database is locked错误。我在部署阶段直接把数据库从SQLite切换到了MySQL，并且配置了连接池参数。如果你做的也是类似规模的项目，建议开发阶段直接用MySQL，避免后期迁移的麻烦。

5.2 性能优化的几个关键手段

推荐算法跑相似度矩阵时，数据量大了以后我明显感觉到计算慢。3000本书、200个用户的数据集，全量计算一次相似度需要大约20秒。这个速度虽然定时任务能接受，但显然还有优化空间。

我做了一层优化：因为ItemCF相似度计算时，只关注"有多少用户共同借过某两本书"，而大部分书之间的共同借阅次数是0，所以可以先按用户数量过滤掉那些极端冷门的书，再参与计算。这样相似度矩阵的稀疏率提升很明显，计算时间从20秒降到了4秒左右。这个优化对规模不大的系统就绰绰有余了。

还有就是对高频查询加了缓存。首页看板数据、热门图书排行榜这些不经常变化的内容，我设置了一个5分钟的Redis缓存，访问量大的时候后端压力小很多。

6. 源码结构与二次开发建议：拿到项目后怎么下手

6.1 源码目录设计

这个项目的模块划分遵循了Django的最佳实践，按业务域拆分app：

code复制book_management/         # 项目配置目录
  settings.py             # 项目配置
  urls.py                 # 全局路由
  celery.py               # 定时任务配置
books/                    # 图书管理模块
  models.py               # 图书、分类数据模型
  views.py                # 图书列表、详情、搜索视图
borrow/                   # 借阅管理模块
  models.py               # 借阅记录模型
  services.py             # 借书/还书/续借业务逻辑
users/                    # 用户模块
  models.py               # 读者档案扩展
recommend/                # 推荐引擎模块
  algorithms/             # 协同过滤算法
  tasks.py                # 定时更新推荐任务
  views.py                # 推荐数据接口
analytics/                # 数据可视化模块
  views.py                # 看板数据接口
ai_service/               # AI大模型接入模块
  services.py             # 模型调用封装
templates/                # 前端模板（Django模板语法）
static/                   # 静态资源（js/css/images）

如果拿到源码，我建议按照这个顺序读代码：先看books/models.py了解数据表结构，因为一切业务都围绕数据展开；再看borrow/services.py熟悉核心业务逻辑；然后看recommend/algorithms/理解推荐算法是怎么实现和调用的；最后看analytics和ai_service了解可视化和大模型模块的接入方式。

6.2 可以做的扩展方向

这个项目如果拿去做毕业设计或者实际使用，还有几个不错的扩展点：

方向一：对接微信小程序。 图书管理系统天然适合做移动端，学生用手机就能查书、续借、接收催还通知。后端只需要提供一套JSON的RESTful API（Django REST Framework可以快速实现），前端开发一个小程序壳子就搞定。

方向二：基于BERT的中文语义检索。 目前系统的搜索还是关键词加简单的AI语义映射，如果要提升搜索精度，可以引入中文预训练模型做向量化检索，把用户Query转为向量，在向量数据库中做相似度检索。这个方向对计算机专业的学生来说，是很好的论文切入点。

方向三：多维度的读者画像分析。 现在的推荐引擎只看借阅行为，其实还可以结合用户的专业、年级、入馆频次、借阅时段等特征，构建更完整的读者画像，实现更精准的个性化推荐。这个方向有利于把系统的"大数据能力"做深。

方向四：OCR扫码借书。 给每本图书生成唯一的二维码标签，使用手机摄像头扫码自动识别图书，可以极大简化借还流程。这个功能用百度OCR或者PaddleOCR都能实现，工程难度不大但演示效果好。

最后聊两句实际感想

做完整套系统，我最深的感受是：技术本身并没有多高大上，Django是每个Python开发者都熟悉的成熟框架，协同过滤是推荐领域的基础算法，ECharts是一个图表库，大模型调用更是几行代码的事。真正花力气的地方在于把这几样东西组合起来，让它们围绕真实业务场景协同工作。比如推荐引擎，光有算法远远不够，你得先有数据采集的习惯，才能在用户产生借阅行为后把反馈数据梳理出来；再比如可视化，你得先搞清楚管理员的决策痛点，才能选对图表的维度。

另外想给准备拿这个项目做毕业设计的朋友提个醒：答辩的时候，老师最喜欢问的问题就是"你为什么选这个技术方案""这个指标为什么这么设计""遇到性能瓶颈怎么优化"。所以不只是要把功能做出来，更要理解每个模块背后的设计逻辑。我写这篇文章的很多细节，包括踩坑和取舍，其实就是设计逻辑的体现，你把这些讲清楚了，答辩一定没问题。