本篇文章将会手把手教你如何部署DjangoBlog项目，首先介绍下我这里的基本环境，请大家仔细阅读此部分，下面的教程都会使用这些约定来介绍：

• 系统是ubuntu 18.04 LTS
• 假设你的域名是www.djangoblog.com。
• python虚拟环境目录在 ~/python/env
• djangoblog源码位置在 ~/python/djangoblog
• 登入用户server
• 编辑器使用vim，你可以使用你喜欢的编辑器。

另外请注意，尽量不要使用root用户来部署，如果要使用root用户的话，需要使collectedstatic目录所有用户都有读权限。

准备工作

升级系统

首先需要升级系统到最新版，终端下执行：

sudo apt update
sudo apt upgrade -y

待完成更新之后，建议重新启动下系统，再进行后面的操作。终端下执行:

sudo reboot

待系统启动后，可以开始安装依赖的mysql以及python环境了。

安装依赖

终端下执行：

sudo apt install mysql-server -y #安装mysql
sudo apt install python3-dev python3-pip python-pip memcached virtualenv -y #安装pip和memcached
sudo apt ins...

做 DjangoBlog 这种内容型站点，搜索是绕不开的功能。但 Django 自带的 __icontains 之流根本上不了台面：不分词、不打分、无法高亮、数据量稍大就拖死数据库。社区的标准答案是 django-haystack，一个搜索抽象层，可以挂 Whoosh、Elasticsearch、Solr、Xapian 多种后端。

但 haystack 默认配置在中文场景下几乎不可用：

• Whoosh 默认的 StemmingAnalyzer 是为英文词干提取设计的，遇到「Django 信号机制」这种短语，要么按空格切分，要么干脆当成单个 token，召回率极差。
• Elasticsearch 默认的 standard 分词器对中文是按单字切，「博客」会被切成 "博" 和 "客"，搜索时几乎匹配不到有意义的结果。
• 单字搜索还会被 stopwords 过滤掉，返回空结果。
• 高亮模块对 CJK 字符不友好，经常出现 <mark> 标签插在词中间的 BUG。

DjangoBlog 的解法是「一套 haystack 接口 + 两套自定义后端」：开发环境用 Whoosh + Jieba（零依赖、跑测试快），生产环境用 Elasticsearch + IK 分词（性能、扩展性、推荐词全有了），通过环境变量自动切换。下面拆开讲。

整体架构

            ┌────────────...

在大语言模型（LLM）席卷各行各业的今天，如何让 AI "读懂"你自己的私有文档、知识库，成为开发者最迫切的需求之一。RAG（Retrieval-Augmented Generation，检索增强生成） 正是解决这个问题的核心技术。

本文将手把手带你用 LlamaIndex 和 LangChain 搭建一套完全本地运行的 RAG 系统，结合 Ollama 跑本地模型，无需花一分钱 API 费用。

什么是 RAG？

RAG 的核心思路很简单：

1. 索引阶段：把你的文档切成小块，用 Embedding 模型转成向量，存入向量数据库
2. 查询阶段：用户提问时，先把问题也转成向量，从数据库里找最相关的文档块
3. 生成阶段：把检索到的文档块 + 用户问题一起塞给 LLM，让它基于真实资料回答

用户问题 → Embedding → 向量检索 → 相关文档块
                                      ↓
                              LLM 生成答案 ← 提示词模板

相比直接问 LLM，RAG 的优势在于： - 不幻觉：答案有据可查，来自你的文档 - 可更新：文档更新后重建索引即可，无需重新训练模型 - 成本低：不需要微调，普通机器即可运行

技术栈选择：LangChain vs LlamaIndex

Django 的信号机制（Signals）是一套内置的发布-订阅系统，允许某些发送者在特定事件发生时通知一组接收者，而发送者和接收者之间完全解耦，互不知晓对方的存在。

合理使用信号可以让代码更整洁——把"某件事发生后需要做的副作用"从核心逻辑中剥离出去，而不是把所有逻辑堆在 save() 或视图函数里。

信号的基本概念

Django 信号的三个核心角色：

• Signal：信号对象本身，定义了事件类型
• Sender：触发信号的发送者（通常是某个 Model 或 View）
• Receiver：接收信号并执行逻辑的函数

基本工作流程：

某个事件发生
    ↓
Signal.send(sender, **kwargs)
    ↓
所有已注册的 receiver 函数依次被调用

Django 内置信号

Django 自带了一批常用信号，覆盖 Model 生命周期、请求处理、数据库操作等场景。

Model 信号

from django.db.models.signals import (
    pre_save,    # save() 调用前
    post_save,   # save() 调用后
    pre_delete,  # delete() 调用前
    post_delete, # delete() 调用后
    m2m_changed, # Many...

本文详细介绍如何使用 Kubernetes 部署 DjangoBlog，包括存储配置、服务编排、Nginx 反向代理、HTTPS 证书自动签发，以及 Whoosh 和 Elasticsearch 两种搜索引擎的配置方法。

项目 Docker 镜像已发布到 Docker Hub：liangliangyy/djangoblog

整体架构

部署完成后，整个系统由以下组件构成：

Internet
    │
    ▼
Ingress (ingress-nginx + cert-manager)
    │  HTTPS TLS 1.2/1.3
    ▼
Nginx Pod              ← 静态文件服务 + 反向代理
    │
    ▼
DjangoBlog Pod         ← Gunicorn，端口 8000
    ├── MySQL Pod      ← 数据库，端口 3306
    ├── Redis Pod      ← 缓存，端口 6379
    └── Elasticsearch  ← 搜索（可选），端口 9200

各组件通过 Kubernetes ClusterIP Service 互联，外部流量只通过 Ingress 进入，内部服务不对外暴露。

前置条件

K8s 集群中需要提前安装：

• ingress-nginx：处理外部 HTT...

本文是对 DjangoBlog 前端架构从零重构的完整记录。目标是在不破坏 Django 服务端渲染优势的前提下，把一个积累了多年技术债的老旧前端，改造成具备现代开发体验和用户体验的新架构。

背景：旧架构的问题在哪里

DjangoBlog 的旧前端是典型的 Django 传统方案：Bootstrap 提供基础样式，jQuery 负责交互，样式和逻辑散落在各模板文件中。随着功能迭代，积累了一系列问题。

样式管理混乱：颜色值硬编码在十几个模板文件里，想换一套主题色需要全局搜索替换。内联 style 属性与 CSS 类混用，hover 效果靠 JavaScript onmouseenter/onmouseleave 实现，维护成本极高。

没有构建流程：CSS 和 JS 直接引用 CDN 或放在 static/ 目录，无法做 Tree-shaking、代码压缩和资产指纹。每次上线需要手动处理缓存失效问题。

暗黑模式体验差：切换主题时有明显的颜色闪烁（FOUC，Flash of Unstyled Content），原因是主题 class 在 JavaScript 执行后才被添加，此时页面已经以亮色渲染过一帧。

页面体验割裂：每次翻页都是完整的 HTTP 请求和页面刷新，没有过渡动画，没有进度反馈，在慢网络下体验很差。

组件化程度低：评论、回到顶部、图片灯箱、代码复制等功能各自为政，代码...