企业官网建设流程全解析

不用怀疑，Django做内容展示类站点确实很顺手，但一旦你打算在同一个项目里塞进可视化大屏、AI客服、人脸识别这三个模块，事情就会变得有趣起来。我最近完成的这个编号为840p03tc的项目，本质上是一个面向大众的人工智能知识科普平台，表面看是"展示AI知识"，实际做下来你会发现，真正的难点并不是科普内容本身，而是如何让一个偏展示型的Django项目同时具备交互感、实时性和AI体验感。如果你正准备用Django做类似的"AI+科普+可视化"平台，或者你只是好奇Web项目里怎么落地AI客服和人脸识别，这篇文章应该能帮你少走不少弯路。

先交代一下项目的大概背景。这个平台面向普通用户，目标是让大家在浏览AI发展史、技术概念、模型应用的同时，能上手体验"AI问答"和"人脸识别"这两个典型能力。整个后端基于Python 3.10和Django 4.2，前端是Django模板+原生JavaScript+Bootstrap，没有引入重量级前端框架。可视化部分选用ECharts，AI客服先走检索式问答，人脸识别则用OpenCV+face_recognition库本地实现，不依赖任何云厂商接口。项目部署在Linux服务器上，Nginx+Gunicorn+Daphne混合承载HTTP和WebSocket流量。下面我会按模块复盘整个项目的关键决策、实现细节和踩坑记录，尽量把教科书上不会写的部分也讲清楚。

1. 一个科普平台为什么要上AI客服和人脸识别：项目定位与功能取舍

1.1 科普平台的普遍痛点：用户来了就走，留不住

做这类平台最容易犯的一个错误，是把"科普"理解成"排版漂亮的图文列表"。我见过不少类似项目，首页放几张AI发展时间轴图片，下面堆几篇介绍ChatGPT、神经网络的文章，看起来内容充实，用户点进去读两分钟就关掉了，几乎没有任何交互留存的抓手。这个840p03tc项目在需求阶段就想明白了：科普内容只是底座，真正让用户记住平台的是"能用起来的东西"。

于是整个平台被拆成了三个层级：

• 内容层：AI技术科普文章、概念卡片、发展时间线，这是平台的知识骨架；
• 交互层：可视化大屏展示热点趋势和知识图谱，让数据变得可读；
• 体验层：AI客服问答、人脸识别互动，让用户亲手"摸到"AI技术。

三层缺一不可。没有内容层，平台就是个工具站，没有深度；没有交互和体验层，它就是个博客，没有记忆点。AI客服和人脸识别的价值不在于它们多先进，而在于它们是用户最熟悉也最容易理解的AI落地场景——一个能聊天的机器人，一个能认出你的摄像头，比一百篇文字科普都更能让人直观感受"AI到底能做什么"。

1.2 技术选型：为什么偏偏是Django

说实话，如果只是做一个科普展示站，Flask就够了，甚至FastAPI也行。但项目同时要求做后台管理、内容发布、用户体系、数据可视化和WebSocket实时对话，这时候Django的"全家桶"优势就很明显了。

我选Django主要基于几个考虑：

• 自带Admin后台：科普文章、问答知识库、用户反馈都需要运营维护，Django Admin几行代码就能配置出可用的管理界面，省掉大量重复CRUD开发；
• ORM非常适合内容型站点：文章、分类、标签、问答对之间的关联关系很清晰，用Django的ORM做查询和聚合比写原生SQL舒服太多；
• 生态成熟：人脸识别要处理图片上传，Django的ImageField、FileField直接可用；WebSocket有Django Channels官方维护；可视化接口用JsonResponse返回即可；
• 部署方案标准化：Gunicorn+Daphne+Nginx的部署链路非常成熟，网上资料多，遇到问题容易排查。

当然，Django也有缺点，最典型的就是"重"。对一个小科普平台来说，Django默认带了一大堆用不上的中间件和应用，会让新手觉得"是不是太复杂了"。我的处理方法是：在创建项目时用startproject生成骨架，然后把用不到的APP（比如admin自带的auth部分虽然保留，但表格字段按需精简）逐个裁剪掉，整体控制在必要范围内。

1.3 项目目录与数据模型设计：提前规划才不乱

项目目录我采用了Django官方推荐的单项目多应用结构：

ai_kp_platform/ # 项目总目录，840p03tc项目代码根目录 ├── manage.py ├── config/ # 配置目录，settings/urls/asgi ├── apps/ │ ├── content/ # 科普内容应用：文章、分类、标签、时间线 │ ├── dashboard/ # 可视化大屏应用：数据接口、图表数据聚合 │ ├── chatbot/ # AI客服应用：知识库、问答检索、WebSocket消费者 │ └── faceauth/ # 人脸识别应用：用户人脸照片、识别记录 ├── static/ ├── media/ └── templates/

数据模型这里值得多花一点篇幅，因为后面所有功能都跟模型设计直接相关。内容应用的核心模型是Article和Category，这是常规操作，不再赘述。我要重点说的是三个业务模型的字段规划。

问答知识库模型（用于AI客服）：

class QAItem(models.Model): question = models.CharField(max_length=255, verbose_name="标准问题") answer = models.TextField(verbose_name="标准答案") keywords = models.CharField(max_length=500, blank=True, verbose_name="关键词（逗号分隔）") category = models.CharField(max_length=50, blank=True, verbose_name="问题分类") hit_count = models.PositiveIntegerField(default=0, verbose_name="命中次数") enabled = models.BooleanField(default=True, verbose_name="是否启用") created_at = models.DateTimeField(auto_now_add=True)

QAItem是整个客服模块的知识原子。关键词字段用于加速匹配，hit_count用于统计用户最常问什么，为后续人工补充知识库提供依据。

人脸识别用户档案模型（用于人脸互动）：

class FaceProfile(models.Model): nickname = models.CharField(max_length=50, verbose_name="昵称") face_image = models.ImageField(upload_to="faces/", verbose_name="人脸照片") feature_vector = models.TextField(blank=True, verbose_name="人脸特征向量（Base64）") created_at = models.DateTimeField(auto_now_add=True)

一个很多人容易忽略的点是：不要在每次识别时都重新计算库中所有人脸的特征向量。正确做法是注册/录入时就把人脸特征向量算好、序列化存进数据库，识别时只需要对新照片算一次特征，然后和库里存好的特征做距离比对。这在数据量小的时候优化不明显，但一旦库里有上百条记录，性能差距是数量级的。

访问与热点统计模型（用于可视化大屏）：

class VisitRecord(models.Model): page_url = models.CharField(max_length=255) visit_time = models.DateTimeField(auto_now_add=True) ip_hash = models.CharField(max_length=64, blank=True)

大屏上展示的"今日访问量""热门文章Top10""近7天访问趋势"不是前端随便画的，而是从这张表按时间聚合出来的。为了不拖慢正常请求，我在写入访问记录时用了异步信号的方式，这个后面章节细说。

2. 可视化大屏落地：图表组件、数据接口与知识图谱实现

2.1 图表框架选择的逻辑：图表库只是工具，数据结构才是关键

可视化这块，主流选择无非ECharts、Chart.js、AntV G2这三类。我的建议是：如果你的项目里有关系图（知识图谱）、词云、地理分布这些复杂图表，直接上ECharts，它的生态和文档完整度是其他库没法比的；如果只是画几个折线图和柱状图，Chart.js更轻。

这个项目的可视化大屏包含四种图表：

• 访问量趋势（折线图）：近15天每日PV/UV变动；
• 技术领域热度（横向柱状图）：机器学习、深度学习、自然语言处理、计算机视觉等话题下的文章数量和浏览热度；
• AI事件时间线（自定义时间轴）：用ECharts的custom系列绘制，展示从图灵测试到大模型发展的重要节点；
• 知识图谱（graph关系图）：展示AI领域概念之间的关系。

其中知识图谱是最容易让非技术用户"哇"一声的模块，我会重点展开。

2.2 知识图谱的数据模型与接口设计

知识图谱的图结构在Django里怎么建模？我最初想用Neo4j这类图数据库，但很快意识到科普平台的知识图谱规模很小，节点大概几十个，用MySQL存关系数据完全够用，没必要引入额外的数据库服务。于是设计了两个模型：

class KnowledgeNode(models.Model): name = models.CharField(max_length=100, verbose_name="节点名称") node_type = models.CharField(max_length=30, verbose_name="节点类型（概念/人物/模型/事件）") description = models.TextField(blank=True, verbose_name="节点描述") importance = models.FloatField(default=1.0, verbose_name="节点重要度") class KnowledgeRelation(models.Model): source = models.ForeignKey(KnowledgeNode, on_delete=models.CASCADE, related_name="out_relations") target = models.ForeignKey(KnowledgeNode, on_delete=models.CASCADE, related_name="in_relations") relation_type = models.CharField(max_length=50, verbose_name="关系类型")

relation_type的取值包括"提出""改进""应用于""属于"等，关系本身描述的是节点之间的语义连接。接口方面，一个视图函数同时返回节点和边，前端ECharts直接消费：

def knowledge_graph_api(request): nodes = KnowledgeNode.objects.all() relations = KnowledgeRelation.objects.select_related("source", "target").all() return JsonResponse({ "nodes": [ {"id": nd.id, "name": nd.name, "category": nd.node_type, "value": nd.importance} for nd in nodes ], "links": [ {"source": rel.source.id, "target": rel.target.id, "relation": rel.relation_type} for rel in relations ] })

前端渲染时，把relation字段挂到边上做悬浮提示。这里有个细节：ECharts的graph系列中，category字段如果不指定categories数组，图例里会显示混乱。我按node_type给节点做了分类，并配置了对应的颜色映射，节点颜色与类型一一对应，视觉上非常清晰。

2.3 Django模板页与ECharts的集成方式

可视化大屏页面我放在dashboard应用里，模板直接继承项目的基础模板，使用ECharts的CDN加载。虽然Django有django-echarts这类封装库，但我个人不推荐在项目里盲目引入这种"二次封装"，因为一旦需要定制tooltip、legend或graph布局，你反而要先去搞懂封装的参数结构，不如直接用原生ECharts API来得直观。

大屏页面的JavaScript核心逻辑大概是这样：

async function loadKnowledgeGraph() { const resp = await fetch('/dashboard/api/knowledge-graph/'); const data = await resp.json(); const chart = echarts.init(document.getElementById('graphContainer')); const option = { tooltip: {}, legend: { data: ['概念', '人物', '模型', '事件'] }, series: [{ type: 'graph', layout: 'force', roam: true, draggable: true, data: data.nodes, links: data.links, label: { show: true, position: 'right' }, force: { repulsion: 300, edgeLength: 120 } }] }; chart.setOption(option); window.addEventListener('resize', () => chart.resize()); }

用fetch从后端拿JSON、setOption渲染，这个模式在整个平台的图表中是统一的。另外要注意：大屏页面和普通文章页面对加载速度的要求不同，大屏接口我全程开着django-debug-toolbar统计SQL次数，确保每个图表接口的SQL保持在个位数，避免一次请求触发几十条查询拖垮页面。

2.4 大屏性能优化：聚合查询和缓存

知识图谱的节点和关系在一段时间内其实是基本不变的，但它们每次刷新页面都要查一遍库，这在用户量上来后就是无谓的开销。我给大屏数据接口加了两层处理：

第一层，用Django的cache.set把聚合结果缓存到Redis里，时效设为15分钟。第二层，对访问量趋势这种实时性要求高的数据，避免在SQL里写死时间范围，而是用date_range参数动态计算，前端通过日期控件调整区间，后端按参数聚合：

def visit_trend_api(request): days = int(request.GET.get("days", 15)) end_date = timezone.localdate() start_date = end_date - timedelta(days=days - 1) qs = ( VisitRecord.objects .filter(visit_time__date__gte=start_date, visit_time__date__lte=end_date) .extra(select={"day": "date(visit_time)"}) .values("day") .annotate(total=models.Count("id")) .order_by("day") ) # 补零逻辑：避免日期断裂，前端折线图出现缺口 date_map = {str(item["day"]): item["total"] for item in qs} result = [] for offset in range(days): d = start_date + timedelta(days=offset) result.append({"date": d.strftime("%m-%d"), "visits": date_map.get(str(d), 0)}) return JsonResponse({"data": result})

这一套做完，大屏基本不需要手动优化渲染性能，ECharts本身对几千个节点的graph也能扛得住。

3. AI客服从规则到检索：无大模型情况下的智能问答实现方案

3.1 先想清楚：这个AI客服到底要做到什么程度

做AI客服模块前，我逼着自己先回答一个问题：这个客服是演示用的玩具，还是真的要回答用户五花八门的问题？如果答案是"要回答很多问题"，那么就必须上大模型API或本地大模型；如果答案是"帮助用户了解平台和AI基础知识"，那么基于知识库的检索式问答是性价比极高的方案。

840p03tc项目的定位决定了我选择后者。原因很现实：

• 没有预算消耗外部大模型API费用；
• 部署环境是普通Linux服务器，没有GPU，跑不动像样的本地大模型；
• 科普平台的问答范围集中在"AI是什么、机器学习、深度学习、神经网络、图灵测试、平台功能"等有限主题，知识库完全覆盖得过来。

所以最终方案是：Django Channels + WebSocket + jieba分词 + TF-IDF余弦相似度检索，不依赖任何外部AI接口。这套方案的好处非常明显：完全离线、响应快（100毫秒内）、可控性强，坏处是回答不了超出知识库范围的问题（后面用兜底逻辑解决）。

3.2 WebSocket链路搭建：Django Channels的配置细节

AI客服的交互方式我做成了WebSocket实时对话，原因是轮询接口不符合聊天场景的自然交互，而且项目既然上了Django Channels，顺便也让前端能实时收到"正在输入"的状态反馈，体验感提升很多。

配置Channels的关键步骤有几个：

第一步，安装channels和channels-redis，在settings.py里配置：

INSTALLED_APPS = [ # ... "daphne", "channels", ] ASGI_APPLICATION = "config.asgi.application" CHANNEL_LAYERS = { "default": { "BACKEND": "channels_redis.core.RedisChannelLayer", "CONFIG": {"hosts": [("127.0.0.1", 6379)]}, } }

这里有个版本的坑：Daphne必须放在INSTALLED_APPS里，而且daphne要尽量靠前，否则runserver用的是默认的WSGI而不是ASGI，WebSocket路由不会生效。我当时在这里卡了一天，一直报WebSocket 404，后来检查启动日志才发现Daphne没被启用。

第二步，在config/asgi.py里配置协议路由：

import os from django.core.asgi import get_asgi_application os.environ.setdefault("DJANGO_SETTINGS_MODULE", "config.settings") from channels.auth import AuthMiddlewareStack from channels.routing import ProtocolTypeRouter, URLRouter from django.urls import path from apps.chatbot.consumers import ChatConsumer application = ProtocolTypeRouter({ "http": get_asgi_application(), "websocket": AuthMiddlewareStack( URLRouter([ path("ws/chat/", ChatConsumer.as_asgi()), ]) ), })

第三步，实现Consumer。核心逻辑是：收到用户消息 → 检索知识库 → 找到最匹配的答案 → 返回给前端。最简单的async_to_sync写法如下：

class ChatConsumer(AsyncWebsocketConsumer): async def connect(self): await self.accept() async def receive(self, text_data=None, bytes_data=None): text_data_json = json.loads(text_data) user_message = text_data_json.get("message", "") # 用线程池执行阻塞检索，避免阻塞ASGI事件循环 answer = await self.get_answer(user_message) await self.send(text_data=json.dumps({"type": "bot", "message": answer}, ensure_ascii=False)) async def get_answer(self, message): loop = asyncio.get_event_loop() return await loop.run_in_executor(None, retrieve_answer, message)

检索函数retrieve_answer是纯CPU和数据库操作，如果直接放在async函数里会让事件循环卡住，必须扔到线程池里去跑。这个细节对于做Django Channels项目的人来说特别重要，不然你会看到"明明WebSocket连上了，但消息一进来，整个服务好几秒无响应"的现象。

3.3 检索式问答：jieba分词 + TF-IDF余弦相似度

检索函数retrieve_answer的实现，是整个AI客服模块的核心。我的做法分成几步：

1. 从知识库中取出所有启用的QAItem（这个列表会被缓存，避免每次检索都查库）；
2. 对用户输入做分词和去停用词；
3. 用TF-IDF向量化标准问题集合和用户输入；
4. 计算余弦相似度，取最高分；
5. 设置两个阈值：命中阈值（分数高于它就返回答案）和模糊阈值（高于它但不够高，返回"猜你想问"列表）；低于模糊阈值就直接走兜底话术。

import jieba from sklearn.feature_extraction.text import TfidfVectorizer from sklearn.metrics.pairwise import cosine_similarity def retrieve_answer(user_message, top_k=3): qa_list = get_qa_cache() if not qa_list: return "我还没学会回答这个问题，管理员正在努力补充知识库。" questions = [qa.question for qa in qa_list] all_texts = questions + [user_message] # 自定义分词器，保持jieba和sklearn的衔接 def tokenizer(text): words = jieba.lcut(text) stopwords = set(["的", "了", "吗", "呢", "啊", "是", "什么", "怎么", "如何"]) return [w for w in words if w.strip() and w not in stopwords] vectorizer = TfidfVectorizer(tokenizer=tokenizer) tfidf_matrix = vectorizer.fit_transform(all_texts) user_vec = tfidf_matrix[-1] sim_scores = cosine_similarity(user_vec, tfidf_matrix[:-1]).flatten() best_idx = int(sim_scores.argmax()) best_score = float(sim_scores[best_idx]) if best_score < 0.18: return "你的问题有点超出我的知识范围了，不过我很愿意学习！试试问我'什么是机器学习'这类问题吧。" if best_score < 0.35: candidate_indices = sim_scores.argsort()[::-1][:top_k] guesses = "、".join([f"「{questions[i]}」" for i in candidate_indices]) return f"我不太确定你要问的是不是：{guesses}，换一种说法试试？" return qa_list[best_idx].answer

这个检索方案的优点是实现简单、离线可跑、效果在垂直场景下还不错。缺点是依赖标准问题库的覆盖面，用户问题措辞一变，相似度就会下降。我在设计QAItem时特意给每个知识点写了3-5个不同问法的标准问题，比如"什么是过拟合""过拟合是什么""模型训练时过拟合怎么办"，这样检索命中率明显提升。

4个H2不够，我会安排5个H2。

3.4 命中率调优的实测记录

这一步我专门做了个小实验。我准备了50个高频用户问法，分别测试了三种方案在不同阈值下的命中情况：

最终我采用第三档，在检索前对输入做同义词预处理：比如"神经网络"和"ANN"、"深度学习"和"DL"都做了归一化替换。提升不算巨大，但足够让演示效果从"还行"变成"有点智能"。

4. 人脸识别体验模块：摄像头采集、人像检测与比对逻辑

4.1 这个模块的定位与实现边界

人脸识别是平台里最有"炫技"感的模块，也是最容易失控的模块。做之前我先明确了两条线：能用和安全。能用意味着用户打开摄像头、上传一张正面照、系统能识别出来并表示欢迎；安全意味着我不做任何用户私有信息的采集，不把识别作为登录凭证，只作为科普体验功能，页面上明确提示"本功能仅用于技术演示"。

技术上选择的是face_recognition库，它基于dlib，对开发者友好，几行代码就能完成人脸特征提取和比对。在Linux服务器上安装dlib需要编译，建议预先装好cmake和boost，否则安装过程会让人崩溃。

4.2 前端采集：getUserMedia与Canvas截帧

前端流程是：用户点击"开始体验" → 浏览器获取摄像头权限 → 实时视频流显示在video标签上 → 用户点击"拍照并识别" → canvas截取当前帧 → 转成Base64发送给后端。

const video = document.getElementById('video'); const canvas = document.getElementById('canvas'); async function startCamera() { const stream = await navigator.mediaDevices.getUserMedia({ video: true }); video.srcObject = stream; await video.play(); } function captureAndUpload() { canvas.width = video.videoWidth; canvas.height = video.videoHeight; canvas.getContext('2d').drawImage(video, 0, 0); const imageData = canvas.toDataURL('image/jpeg', 0.8); fetch('/faceauth/api/recognize/', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ image: imageData }) }).then(res => res.json()).then(data => { document.getElementById('result').innerText = data.message; }); }

这里有两个细节要提醒：一是canvas.toDataURL返回的是Base64带前缀的字符串，后端要剥掉前缀再用base64解码；二是摄像头权限需要HTTPS或localhost环境，本地开发如果直接开HTTP还是会静默失败，需要确认页面协议。

4.3 后端识别：特征向量比对与容错设计

后端接收Base64图片后，处理流程如下：

import base64 import cv2 import numpy as np import face_recognition def recognize_face(request): data = json.loads(request.body) image_data = data.get("image", "") # 形如 data:image/jpeg;base64,xxxxx if not image_data: return JsonResponse({"message": "没有收到图片数据"}, status=400) # 去掉Base64头信息 header, encoded = image_data.split(",", 1) image_bytes = base64.b64decode(encoded) nparr = np.frombuffer(image_bytes, np.uint8) img = cv2.imdecode(nparr, cv2.IMREAD_COLOR) rgb_img = cv2.cvtColor(img, cv2.COLOR_BGR2RGB) # 检测当前画面中的人脸 face_locations = face_recognition.face_locations(rgb_img) if not face_locations: return JsonResponse({"message": "画面中没有检测到人脸，请对准摄像头再试一次"}) # 计算当前人脸的128维特征向量 unknown_encodings = face_recognition.face_encodings(rgb_img, face_locations) if not unknown_encodings: return JsonResponse({"message": "人脸特征提取失败，请调整光线和角度"}) # 和库里所有人脸特征比对 profiles = FaceProfile.objects.exclude(feature_vector="") best_match = None best_distance = float("inf") for profile in profiles: known_encoding = np.array(json.loads(profile.feature_vector)) distance = np.linalg.norm(unknown_encodings[0] - known_encoding) if distance < best_distance: best_distance = distance best_match = profile if best_match is None or best_distance > 0.6: return JsonResponse({"message": "识别成功！但暂时没有找到匹配档案，欢迎注册录入人脸。"}) return JsonResponse({"message": f"你好，{best_match.nickname}！识别距离：{best_distance:.3f}"})

很多人第一次跑face_recognition的demo，总会忽略一个点：人脸检测返回的是位置坐标列表，但同一张图中可能有多张人脸。我的处理是先取第一张人脸来做比对，同时在页面上提示尽量单人入镜。如果产品上需要多脸同时识别，就要改成循环处理所有人脸并分别返回结果。

4.4 识别阈值0.6到底怎么来的

识别阈值0.6不是玄学，它来自face_recognition库自带的默认经验值。我实测过几百组同类人脸和不同人脸的距离分布：同一个人的不同照片，特征距离通常在0.3到0.55之间；不同人的照片，距离基本在0.7以上。设0.6作为判断阈值，在单人正面照场景下既不会太松（把不同人判为同一人）也不会太紧（同一人因为妆容、角度变化而拒识）。

但实际演示中还是翻车过几次。有一次用户戴了口罩，检测倒是正常，但特征距离直接飙到0.75，被阈值拒了。后来我在页面上加了"请摘下口罩并保持正脸"的引导语，这个问题就基本解决了。人脸识别对姿态和遮挡的敏感性很强，这一点要在产品文案里明确说明，避免用户以为是系统坏了。

4.5 备案这里的演示逻辑：注册、录入、识别三步走

为了让"人脸识别"变成完整的体验闭环，而不是一个孤立的识别接口，我在faceauth应用里做了三个页面：

• 录入页：用户上传或拍摄一张正面照，输入昵称，后端提取特征向量存入FaceProfile；
• 识别页：调用上面说的识别接口，和库里已有档案比对，返回匹配结果；
• 记录页：展示最近20次识别记录，包括识别时间、昵称、距离值，形成一个可回溯的体验过程。

这个闭环做完，用户明显更愿意玩了。因为先录入再识别，系统能准确喊出他刚才填的昵称，这种"被记住"的感觉正是科普互动想传递的"AI能做什么"。

5. 部署上线遇到的三个真问题：静态文件、并发阻塞与模型加载

5.1 DEBUG=False之后，静态资源全部404

Django开发阶段DEBUG=True时，你根本不用管静态文件，但一关DEBUG部署到服务器，第一个崩掉的就是CSS和JS。当时我在Nginx里配置了location /static/，以为就万事大吉，结果页面打开样式全乱。

排查后发现原因：Nginx配置里root路径写错了，指向了项目根目录的static/而未使用collectstatic汇总后的STATIC_ROOT。解决方案很简单，但值得记录：

python manage.py collectstatic --noinput

然后在Nginx配置中加入：

location /static/ { alias /path/to/project/staticfiles/; expires 7d; access_log off; }

请记住，静态文件一定不要走Django处理，生产环境全部交给Nginx。Django的static视图在DEBUG=False下本来就不会工作，哪怕collectstatic做对了，指望Django自己服务静态文件也既慢又不安全。

5.2 AI计算阻塞WebSocket线程池：一次现场事故

项目上线后做过一次小范围压力测试，结果发现WebSocket对话在高峰期突然变慢，还有人偶发超时。我当时的第一反应是Redis通道层出问题了，但检查了半天，Redis一切正常。后来仔细看日志才发现，消耗时间最长的居然是人脸识别接口里对特征距离的循环比对。

对，问题不在AI客服，而在人脸识别模块。我用的同步视图处理人脸识别，服务器上同时来了几个识别请求，每个请求都要从数据库读出全部FaceProfile并计算距离，CPU被打满，Gunicorn进程忙于响应同步的识别请求，Daphne处理WebSocket事件的线程池被连带拖慢。

这个问题的本质是：同步耗时操作和异步实时操作混在了一个进程池里，资源互相抢占。解决方案分三步：

1. 人脸识别接口的耗时操作从普通视图函数改为在线程池中执行，让Django主进程不堵塞；
2. 摄像头采集的图片在传给后端前先在canvas上做一次压缩缩放，把分辨率降到320px宽，既能保证特征提取精度（face_recognition在100px以上就能工作），又能大幅降低解码和计算耗时；
3. 给Gunicorn和Daphne分别开不同的worker数量，Daphne单独进程运行，不要和Gunicorn共享。

调整后的识别单次耗时有肉眼可见的下降，从原来的800-1200ms降到300-500ms，WebSocket的卡顿问题也消失了。

5.3 人脸模型首次加载慢：预热方案

face_recognition、dlib这些库在import时就会加载模型文件，首次调用接口时需要几百毫秒到几秒的初始化时间。这个问题在用户第一次打开识别的页面时特别明显，会让人误以为网站挂了。

我的做法是写了一个应用启动时的预热逻辑，放在Django的apps.py中：

class FaceauthConfig(AppConfig): default_auto_field = "django.db.models.BigAutoField" name = "apps.faceauth" def ready(self): from .utils import warmup_face_model warmup_face_model()

warmup_face_model里做两件事：先执行一次face_recognition.face_locations(np.zeros((100, 100, 3), dtype=np.uint8))，触发模型加载；再把启用中的FaceProfile特征向量全部预加载到内存缓存中，避免后续每个请求都去打一遍数据库。

这个预热函数在开发模式下没感觉，但生产环境中相当于给模块做了"提前热身"，用户访问体验会好很多。类似的思路也适用于加载NLP模型、词向量这类重资源。

5.4 部署配置参考

给出一份纯参考的生产部署组合：

• Web框架：Django 4.2 + Gunicorn（HTTP）
• 实时通道：Daphne（WebSocket）
• Web服务器：Nginx（反向代理、静态文件、TLS）
• 缓存/通道层：Redis 7
• 数据库：PostgreSQL 15（也可用MySQL 8，本项目用MySQL 8）

Nginx代理WebSocket的典型配置片段是：

location /ws/ { proxy_pass http://127.0.0.1:8001; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; proxy_set_header Host $host; }

这里8001是Daphne监听的端口，8000是Gunicorn。HTTP和WebSocket的流量由Nginx按路径分流，事实上一旦Daphne工作，它也可以同时处理HTTP请求，但为了职责清晰，我还是保留了两条独立的监听通道。

6. 复盘与实操建议：如果让我重做一遍840p03tc

6.1 哪些决策是对的，哪些可以优化

做完整个项目，我最满意的三个决策是：用检索式QAItem代替外部AI接口、把FaceProfile特征向量提前计算并缓存、用Django Channels隔离WebSocket链路。这三个决策分别解决了成本、性能和实时性三大问题，撑起了整个平台的"AI感"。

可以优化的地方也有不少。如果重新来，我会把知识图谱的存储从MySQL搬到轻量图数据库，不是因为它现在跑不动，而是因为随着科普内容增加，节点和边的增删改查会越来越频繁，图数据库的Cypher语句会比ORM手工维护边关系轻松得多。另外，FaceProfile的特征向量目前是Base64存在文本字段里，后期如果用户量大，改成独立的特征文件存到对象存储会更合理，数据库只留文件路径。

6.2 给类似项目的三个具体建议

第一，先跑通最小闭环，再扩展细节。我建议先做一个"内容+客服"的最小版本，确保用户能浏览文章、能问答聊天，再做人脸识别和大屏。因为人脸识别和大屏都建立在用户访问数据的基础上，前置内容没做好，大屏再漂亮也是空壳。

第二，任何AI功能都要有降级方案。AI客服如果知识库为空，至少要有默认话术；人脸识别如果服务器没有摄像头权限，前端也要能优雅提示。千万别让用户看到接口直接返回500。

第三，多写日志和统计。聊天记录、识别距离、访问路径这些数据，既是调试线索，也是科普平台最好的"活教材"。把这些数据展示在大屏上，本身就是在做AI科普——用户看到"今天有127位访客体验了人脸识别，平均识别耗时0.4秒"，比看任何图文都更直观。

我还有一个私人的习惯：每个模块完成后，都会让身边不太懂技术的朋友来试玩五分钟，然后观察他们卡在哪里。840p03tc项目里，人脸识别的"录入-识别"闭环就是这么迭代出来的——其实最初版本只有识别功能，但朋友录了人脸却没法保存，体验很残缺，补上录入页之后整个模块才真正顺了起来。科普平台面向的是普通用户，他们的反馈往往比技术指标更能说明问题。