Python+B站用户行为分析系统：从爬虫到运营决策的全链路实践

简介：本资源是一份面向数据分析初学者与Python开发者的B站用户行为分析系统设计文档，聚焦UP主运营优化与用户内容偏好挖掘场景。文档完整呈现了基于Python的大数据处理流程，涵盖数据采集、清洗、关联规则与聚类分析、matplotlib/seaborn可视化实现等关键技术环节，并详细说明视频类型分布、粉丝/获赞趋势、一键三连行为偏好及播放榜/粉丝榜的总量与均值图表展示逻辑。资源为单个1.05MB的Word文档（.docx），结构规范，含中英文摘要、绪论、技术选型（Python/Django）、系统设计与实现章节及参考文献，目录层级清晰，便于快速定位核心方法与图表案例。目前已有433人学习下载，适合高校课程设计参考、毕业设计选题借鉴或短视频平台运营人员理解用户行为建模路径。

1. 基于 Python 的 B 站用户行为分析系统：不是爬虫玩具，而是可落地的 UP 主运营决策支持工具

你有没有试过——花三天写完一个 B 站视频数据爬虫，跑出 5000 条播放量、弹幕、三连数据，结果打开 Excel 一通筛选排序，最后只得出一句“搞笑类视频好像挺火”？这不是数据分析，这是数据搬运。而这篇笔记要拆解的，是一个真实存在于毕业设计文档里的完整系统：它不依赖第三方 API 密钥，不调用神策或 GrowingIO，不用部署 Hadoop 集群，纯 Python + Django + MySQL 构建，从数据采集、清洗、建模到多维可视化全链路闭环。它解决的不是“能不能拿到数据”，而是“UP 主今天该发什么类型视频”“哪类粉丝最愿意投币”“为什么上周播放量涨了但互动率跌了”这类具体业务问题。系统里没有“大数据”空话，只有柱状图上标着“美食类视频平均三连率 23.7%（高于均值 8.2pct）”的真实刻度；没有“智能推荐”玄学，只有多维分析页中“粉丝量 >50w 且投稿频次 <3/周”的 UP 主在“收藏/播放比”维度明显偏低的交叉结论。它面向的不是算法工程师，而是刚入行的运营助理、想优化内容策略的中小 UP 主、需要快速验证选题的 MCN 策划，以及——正在为毕设卡在“系统怎么才算做完”而焦虑的你。这份资源的价值，不在代码有多炫技，而在它把“用户行为分析”从论文术语，变成了浏览器里点几下就能看懂的决策依据。

---

2. 数据采集与清洗：B 站公开接口的稳定抓取策略与反限流实战

2.1 为什么放弃 Selenium，坚持 Requests + 异步协程？

很多初学者一上来就用 Selenium 模拟浏览器，理由很朴素：“B 站有反爬”。但实测发现，对 B 站公开的 UP 主主页、视频列表页、弹幕 XML 接口，Selenium 是性能黑洞。我们对比过：单个 UP 主 200 条视频页，Selenium 平均耗时 42 秒（含渲染、等待），而 Requests + aiohttp 异步并发 20 个连接，仅需 6.3 秒。更关键的是稳定性——Selenium 在服务器无头环境下极易因字体缺失、GPU 驱动异常崩溃；而 Requests 只要 header 合理，几乎零失败。本系统采用aiohttp+asyncio构建采集器，核心逻辑如下：

import aiohttp import asyncio import time # 全局 session 复用，避免重复握手开销 session = None async def fetch_video_list(session, mid: str, pn: int = 1) -> dict: url = f"https://api.bilibili.com/x/space/arc/search?mid={mid}&ps=30&pn={pn}" headers = { "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36", "Referer": f"https://space.bilibili.com/{mid}/video" } try: async with session.get(url, headers=headers, timeout=10) as resp: if resp.status == 200: return await resp.json() elif resp.status == 412: # B站经典反爬码，需加 Cookie raise Exception("412 Precondition Failed: need valid cookie") else: raise Exception(f"HTTP {resp.status}") except asyncio.TimeoutError: raise Exception("Request timeout") except Exception as e: raise Exception(f"Fetch failed: {str(e)}") async def main(): global session connector = aiohttp.TCPConnector(limit=20, limit_per_host=20) timeout = aiohttp.ClientTimeout(total=15) session = aiohttp.ClientSession(connector=connector, timeout=timeout) tasks = [ fetch_video_list(session, "20234567", pn=1), fetch_video_list(session, "20234567", pn=2), fetch_video_list(session, "89012345", pn=1) ] results = await asyncio.gather(*tasks, return_exceptions=True) await session.close() return results # 运行采集 if __name__ == "__main__": start = time.time() data = asyncio.run(main()) print(f"3 requests done in {time.time() - start:.2f}s")

参数说明：

• limit=20：控制并发连接总数，过高易触发风控（B 站对单 IP 短时请求数敏感）；
• limit_per_host=20：限制对同一域名（如 api.bilibili.com）的并发数，避免被识别为扫描；
• timeout=15：总超时设为 15 秒，防止个别请求阻塞整个队列；
• Referer必填：B 站校验 Referer，缺失直接 403；
• User-Agent需模拟主流浏览器，避免使用默认 aiohttp UA。

2.2 Cookie 注入与动态 Referer 生成：绕过 412 和 403 的关键两步

B 站对高频请求会返回412 Precondition Failed，本质是要求携带有效登录态 Cookie。但系统无需用户登录，解决方案是：复用浏览器已登录的 Cookie，并动态更新。操作流程如下：

1. 手动登录 B 站网页版 → F12 打开开发者工具 → Network 标签 → 刷新任意视频页；
2. 找到https://api.bilibili.com/x/web-interface/archive/stat?bvid=请求 → Copy Request Headers；
3. 提取Cookie字段（含SESSDATA,bili_jct,DedeUserID等）→ 存入配置文件config.py；
4. 在采集脚本中，每次请求前动态拼接 Referer（根据目标 UP 主 mid 生成）：

   # 动态 Referer 示例 referer_base = "https://space.bilibili.com/" referer = f"{referer_base}{mid}/video"

   为什么 Referer 要动态？
   B 站后端会校验 Referer 与 Cookie 中的DedeUserID是否匹配。若固定 Referer（如https://www.bilibili.com），而 Cookie 属于某 UP 主账号，则校验失败返回 403。动态 Referer 确保上下文一致。

2.3 视频数据清洗：从原始 JSON 到结构化字段的映射逻辑

B 站 API 返回的 JSON 结构嵌套深、字段名不统一（如播放量字段为stat.view，弹幕数为stat.danmaku），且存在大量空值和异常值。清洗不是简单pd.dropna()，而是基于业务规则的强校验：

原始字段（API）	清洗后字段	清洗逻辑	业务意义
stat.view	play_count	转为整型；若<0或>1e9则置为None（防刷量）	真实播放量，用于计算播放榜
stat.like	like_count	同上；同时计算like_rate = like_count / play_count（需 play_count > 0）	互动健康度指标
stat.coin	coin_count	同上；重点校验coin_count <= play_count * 0.3（单视频投币率超 30% 极可能异常）	三连质量信号
tname	video_tag	取第一级标签（如"知识->科普"→"科普"）；若为空则用title关键词提取（jieba 分词 + TF-IDF）	统一标签体系，支撑视频类型分析
pubdate	publish_time	时间戳转datetime；按小时聚合生成publish_hour字段（如 14 → 14）	分析发布时间规律

清洗脚本核心逻辑（cleaner.py）：

import pandas as pd from datetime import datetime import jieba def clean_bilibili_data(raw_df: pd.DataFrame) -> pd.DataFrame: df = raw_df.copy() # 1. 播放量清洗 df['play_count'] = pd.to_numeric(df['stat.view'], errors='coerce') df.loc[(df['play_count'] < 0) | (df['play_count'] > 1e9), 'play_count'] = None # 2. 三连清洗（点赞/投币/收藏） for field, prefix in [('like', 'like'), ('coin', 'coin'), ('favorite', 'fav')]: col = f'stat.{field}' df[f'{prefix}_count'] = pd.to_numeric(df[col], errors='coerce') # 投币率合理性校验 if prefix == 'coin': rate = df[f'{prefix}_count'] / df['play_count'] df.loc[rate > 0.3, f'{prefix}_count'] = None # 3. 标签标准化 def extract_tag(tname): if pd.isna(tname) or not tname.strip(): # 用标题关键词补全 title = str(df.loc[df.index[0], 'title']) words = jieba.lcut(title) # 过滤停用词，取 TF-IDF 最高词（简化版） return words[0] if words else '未知' return tname.split('->')[0].strip() df['video_tag'] = df['tname'].apply(extract_tag) # 4. 时间处理 df['publish_time'] = pd.to_datetime(df['pubdate'], unit='s') df['publish_hour'] = df['publish_time'].dt.hour return df[['bvid', 'title', 'video_tag', 'play_count', 'like_count', 'coin_count', 'publish_hour']]

2.4 避坑：B 站接口限流、数据漂移与字段失效的 4 类真实翻车现场

• 现象：采集任务运行 2 小时后突然全部 412，日志显示 Cookie 过期
  原因：B 站SESSDATACookie 有效期通常为 30 天，但登录态可能因异地登录、密码修改等提前失效。
  解决：在fetch_video_list异常捕获中增加if "412" in str(e): self.refresh_cookie()，并实现refresh_cookie()函数——自动打开 Chrome 浏览器，执行登录后提取新 Cookie（用selenium仅用于此场景，非主采集逻辑）。

• 现象：UP 主 A 的视频列表返回正常，但 UP 主 B 的stat字段全为 0
  原因：该 UP 主设置了“隐私保护”，隐藏播放、点赞等数据（B 站后台可设置）。API 返回stat对象但所有数值为 0。
  解决：清洗时增加判断if df['play_count'].sum() == 0 and len(df) > 10: log.warning(f"UP {mid} has privacy enabled, skip stat analysis")，跳过统计分析，仅保留基础信息（标题、发布时间）。

• 现象：tname字段突然从"知识->科普"变成"知识·科普"，导致标签分类错乱
  原因：B 站前端改版，API 字段分隔符由->改为·，但文档未同步更新。
  解决：清洗函数extract_tag中兼容多种分隔符：tname.split('->')[0].split('·')[0].strip()，并记录日志告警if '->' not in tname and '·' not in tname: log.error(f"Unexpected tname format: {tname}")。

• 现象：凌晨 2 点采集的视频数据，publish_time显示为当天 14:00（UTC+8 错误）
  原因：B 站 API 返回的pubdate是 Unix 时间戳（秒级），但部分旧视频时间戳为毫秒级（需/1000），而新视频为秒级。混合处理导致时间偏移。
  解决：在清洗前先做探测：取前 5 条数据，若pubdate值 > 1e12（毫秒级阈值），则全局除以 1000；否则保持原样。df['pubdate'] = df['pubdate'].apply(lambda x: x//1000 if x > 1e12 else x)。

---

3. 数据库设计与 Django 模型：如何让 MySQL 承载百万级视频数据而不卡顿

3.1 表结构设计：从 E-R 图到生产级索引的 3 个关键决策

原文档中的表 3.1 用户数据库表过于简略（仅 3 字段），实际系统需支撑 UP 主、视频、用户行为三类核心实体。我们按生产环境标准重构：

表名	字段（关键）	类型	索引	说明
up_master	mid(PK),name,fans_count,archive_count	BIGINT, VARCHAR, INT	PRIMARY KEY(mid),INDEX idx_fans(fans_count)	UP 主主表，mid为 B 站用户 ID（非自增）
video_info	bvid(PK),mid,title,video_tag,publish_time	VARCHAR, BIGINT, TEXT, VARCHAR, DATETIME	PRIMARY KEY(bvid),INDEX idx_mid(mid),INDEX idx_tag_time(video_tag, publish_time)	视频主表，bvid为唯一标识
video_stat	bvid(PK),play_count,like_count,coin_count,fav_count	VARCHAR, INT, INT, INT, INT	PRIMARY KEY(bvid),INDEX idx_play(play_count)	统计宽表，分离高频更新字段
user_behavior	id(PK),uid,bvid,action_type,action_time	BIGINT, BIGINT, VARCHAR, TINYINT, DATETIME	PRIMARY KEY(id),INDEX idx_uid_action(uid, action_type),INDEX idx_bvid(bvid)	用户行为日志表（模拟数据，实际需埋点）

为什么video_info和video_stat拆成两张表？
video_info（标题、标签、发布时间）极少更新，而video_stat（播放、点赞）每小时可能变化。拆分后，更新统计时只需UPDATE video_stat，不影响SELECT标题等基础信息，减少锁表时间。

3.2 Django 模型定义：用db_table和db_index精确控制底层 SQL

Django ORM 默认生成的表名和索引不够高效，需手动干预。模型代码（models.py）：

from django.db import models class UpMaster(models.Model): mid = models.BigIntegerField(primary_key=True, verbose_name="UP主ID") name = models.CharField(max_length=100, verbose_name="UP主昵称") fans_count = models.IntegerField(default=0, verbose_name="粉丝数") archive_count = models.IntegerField(default=0, verbose_name="投稿数") class Meta: db_table = 'up_master' # 强制表名，不加 app_ 前缀 indexes = [ models.Index(fields=['fans_count'], name='idx_fans'), # 自定义索引名 ] verbose_name = "UP主" verbose_name_plural = "UP主" class VideoInfo(models.Model): bvid = models.CharField(max_length=20, primary_key=True, verbose_name="视频BV号") mid = models.ForeignKey(UpMaster, on_delete=models.CASCADE, db_column='mid', verbose_name="UP主ID") title = models.TextField(verbose_name="视频标题") video_tag = models.CharField(max_length=50, default='未知', verbose_name="视频标签") publish_time = models.DateTimeField(verbose_name="发布时间") class Meta: db_table = 'video_info' indexes = [ models.Index(fields=['mid'], name='idx_mid'), models.Index(fields=['video_tag', 'publish_time'], name='idx_tag_time'), ] verbose_name = "视频信息" verbose_name_plural = "视频信息" class VideoStat(models.Model): bvid = models.OneToOneField(VideoInfo, on_delete=models.CASCADE, primary_key=True, db_column='bvid', verbose_name="视频BV号") play_count = models.IntegerField(default=0, verbose_name="播放量") like_count = models.IntegerField(default=0, verbose_name="点赞数") coin_count = models.IntegerField(default=0, verbose_name="投币数") fav_count = models.IntegerField(default=0, verbose_name="收藏数") class Meta: db_table = 'video_stat' indexes = [ models.Index(fields=['play_count'], name='idx_play'), ] verbose_name = "视频统计" verbose_name_plural = "视频统计"

关键点说明：

• db_column='mid'：确保外键字段名与数据库物理列名一致，避免 Django 自动生成mid_id；
• OneToOneField：VideoStat与VideoInfo一对一，保证bvid主键复用，查询时JOIN效率最高；
• indexes显式声明：Djangomakemigrations会生成CREATE INDEX语句，而非依赖db_index=True（后者仅对单字段有效）。

3.3 百万数据导入优化：用bulk_create替代循环save()的 10 倍提速

当导入 50 万条视频数据时，若用for v in videos: v.save()，耗时约 47 分钟（MySQL 默认每条 INSERT 单独事务）。优化方案：分批bulk_create+ 禁用外键检查。

from django.db import transaction def bulk_import_videos(video_dicts: list): # 1. 分批，每批 10000 条 batch_size = 10000 for i in range(0, len(video_dicts), batch_size): batch = video_dicts[i:i+batch_size] # 2. 转为模型实例 video_objs = [ VideoInfo( bvid=item['bvid'], mid=item['mid'], title=item['title'], video_tag=item['video_tag'], publish_time=item['publish_time'] ) for item in batch ] # 3. 批量创建（关键：指定 ignore_conflicts=True 防重复） with transaction.atomic(): VideoInfo.objects.bulk_create( video_objs, batch_size=batch_size, ignore_conflicts=True # MySQL 5.7+ 支持，冲突时跳过 ) # 4. 导入统计表（同理） stat_objs = [VideoStat(bvid=v['bvid'], **v['stat']) for v in video_dicts] VideoStat.objects.bulk_create(stat_objs, batch_size=batch_size)

为什么ignore_conflicts=True必须加？
采集可能重跑，bvid重复时若不忽略，bulk_create会整个批次报错回滚。加此参数后，重复bvid自动跳过，其余数据正常插入。

3.4 避坑：Django 连接池、字符集与长文本截断的 3 个血泪经验

• 现象：系统运行 2 小时后，Django 报错django.db.utils.OperationalError: (2013, 'Lost connection to MySQL server during query')
  原因：MySQL 默认wait_timeout=28800（8 小时），但 Django 连接池未配置CONN_MAX_AGE，连接空闲超时后被 MySQL 主动断开。
  解决：settings.py中设置CONN_MAX_AGE = 60（单位秒），让连接复用 60 秒后自动关闭，避免长连接僵死。

• 现象：中文标签video_tag存入数据库后变成????
  原因：MySQL 表字符集为latin1，未设为utf8mb4。B 站标签含 emoji（如知识✨），需utf8mb4支持。
  解决：建表时强制指定CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci，并在settings.py的DATABASES中添加'OPTIONS': {'charset': 'utf8mb4'}。

• 现象：title字段超过 255 字符被截断，导致标题不全
  原因：DjangoCharField(max_length=255)对应 MySQLVARCHAR(255)，但 B 站标题最长可达 80 字符（UTF8MB4 下占 320 字节）。
  解决：title = models.TextField(verbose_name="视频标题")，TextField对应 MySQLTEXT，无长度限制；若必须CharField，则设max_length=500并确保 MySQL 表字段为VARCHAR(500) CHARSET utf8mb4。

---

4. 多维可视化分析：从 Matplotlib 静态图到 Plotly 交互式仪表盘的升级路径

4.1 UP 主分析页：柱状图 + 折线图组合的业务语义表达

原文档图 4.2 展示“UP 主最喜爱发布的视频类型统计”和“发布数量时间规律”，但未说明如何从数据生成。实际实现需将业务逻辑注入图表：

• 视频类型分布（柱状图）：不是简单value_counts()，而是按video_tag分组后，过滤掉低频标签（出现<5次）并归入“其他”，避免长尾干扰：

  # views.py from django.db.models import Count from .models import VideoInfo def up_main_analysis(request, mid): # 获取该 UP 主所有视频 videos = VideoInfo.objects.filter(mid=mid).select_related('videostat') # 统计标签分布（带低频过滤） tag_stats = videos.values('video_tag').annotate(count=Count('bvid')) total = sum(item['count'] for item in tag_stats) # 过滤低频（<3% 总量）并合并为“其他” threshold = total * 0.03 filtered_tags = [ {'tag': item['video_tag'], 'count': item['count']} for item in tag_stats if item['count'] >= threshold ] others_count = total - sum(item['count'] for item in filtered_tags) if others_count > 0: filtered_tags.append({'tag': '其他', 'count': others_count}) # 生成图表数据 labels = [item['tag'] for item in filtered_tags] values = [item['count'] for item in filtered_tags] return render(request, 'up_analysis.html', { 'labels': labels, 'values': values, })

• 发布时间规律（折线图）：按publish_hour分组，但需补全 0-23 点，缺失小时填 0，否则折线图断开：

  # 按小时聚合 hour_stats = videos.values('publish_hour').annotate(count=Count('bvid')) # 补全 0-23 小时 hour_dict = {i: 0 for i in range(24)} for item in hour_stats: hour_dict[item['publish_hour']] = item['count'] hours = list(hour_dict.keys()) counts = list(hour_dict.values())

4.2 综合分析页：三维图与动态时间切片的实现难点

原文档图 4.3 提到“按小时、按周、按月切换”，这并非前端 JS 切换，而是后端根据参数动态聚合 SQL。核心是GROUP BY的灵活构造：

# views.py def comprehensive_analysis(request): time_unit = request.GET.get('unit', 'hour') # hour/week/month if time_unit == 'hour': group_field = "HOUR(publish_time)" label_format = "%H:00" elif time_unit == 'week': group_field = "WEEKDAY(publish_time)" # 0=Monday label_format = "%W" else: # month group_field = "MONTH(publish_time)" label_format = "%m" # 原生 SQL 聚合（Django ORM 对复杂 GROUP BY 支持弱） from django.db import connection with connection.cursor() as cursor: cursor.execute(f""" SELECT {group_field} as g, COUNT(*) as cnt, AVG(v.play_count) as avg_play, SUM(v.play_count) as sum_play FROM video_info i JOIN video_stat v ON i.bvid = v.bvid GROUP BY g ORDER BY g """) rows = cursor.fetchall() # 构造图表数据 labels = [f"{r[0]}{label_format}" for r in rows] counts = [r[1] for r in rows] avg_plays = [float(r[2]) for r in rows] sum_plays = [r[3] for r in rows] return render(request, 'comprehensive.html', { 'labels': labels, 'counts': counts, 'avg_plays': avg_plays, 'sum_plays': sum_plays, 'unit': time_unit, })

为什么用原生 SQL？
Django 的extra()或annotate()对WEEKDAY()等 MySQL 函数支持不友好，且GROUP BY字段需与SELECT严格对应。原生 SQL 更可控，性能无差异（Django 底层也是 SQL）。

4.3 多维分析页：散点图坐标轴的业务指标选择逻辑

原文档图 4.4 的“视频量、播放量、粉丝量”三维分析，实际是双坐标散点图（X=视频量，Y=播放量，点大小=粉丝量）。关键在指标归一化，否则量纲差异导致图形失真：

指标	原始范围	归一化方式	业务意义
视频量（投稿数）	1 ~ 5000	(x - min) / (max - min)	衡量内容产出强度
播放量（均值）	100 ~ 5e6	log10(x + 1)	压缩长尾，突出中腰部UP主
粉丝量	1000 ~ 1e7	sqrt(x)	缓解头部效应，使点大小可区分

import numpy as np def get_multidim_data(): # 查询 UP 主级聚合数据 from django.db import connection with connection.cursor() as cursor: cursor.execute(""" SELECT u.mid, u.name, u.fans_count, COUNT(v.bvid) as video_count, AVG(s.play_count) as avg_play FROM up_master u LEFT JOIN video_info v ON u.mid = v.mid LEFT JOIN video_stat s ON v.bvid = s.bvid GROUP BY u.mid, u.name, u.fans_count """) rows = cursor.fetchall() # 归一化 video_counts = np.array([r[3] for r in rows]) avg_plays = np.array([r[4] for r in rows]) fans_counts = np.array([r[2] for r in rows]) # X: 视频量（线性归一） x = (video_counts - video_counts.min()) / (video_counts.max() - video_counts.min() + 1e-8) # Y: 播放量（对数压缩） y = np.log10(avg_plays + 1) # Size: 粉丝量（平方根缩放） sizes = np.sqrt(fans_counts) * 10 # *10 控制点大小 return { 'x': x.tolist(), 'y': y.tolist(), 'sizes': sizes.tolist(), 'names': [r[1] for r in rows], 'mids': [r[0] for r in rows], }

4.4 避坑：Matplotlib 中文乱码、Plotly 渲染卡顿与移动端适配的 3 个硬核解法

• 现象：柱状图 X 轴标签中文显示为方块
  原因：Matplotlib 默认字体不支持中文。
  解决：在views.py顶部添加：

  import matplotlib matplotlib.use('Agg') # 非GUI后端 import matplotlib.pyplot as plt plt.rcParams['font.sans-serif'] = ['SimHei', 'Arial Unicode MS', 'DejaVu Sans'] # 中文字体列表 plt.rcParams['axes.unicode_minus'] = False # 正常显示负号

• 现象：Plotly 图表在 Django 模板中加载缓慢，首屏白屏 3 秒
  原因：Plotly.js 体积大（~5MB），且默认同步加载。
  解决：

  1. 使用plotly.offline.plot()生成静态 HTML 片段，而非plotly.express的在线模式；
  2. 在模板中用<div id="chart">占位，JS 异步加载：

  <!-- base.html --> <script src="https://cdn.plot.ly/plotly-2.24.1.min.js" defer></script> <script> document.addEventListener('DOMContentLoaded', function() { // 动态插入 Plotly 图 const chartData = {{ plotly_json|safe }}; Plotly.newPlot('chart', chartData.data, chartData.layout); }); </script>

• 现象：散点图在手机上点选区域无效，触摸事件不响应
  原因：Plotly 默认responsive: false，且移动端hover事件需特殊配置。
  解决：生成图表时强制启用响应式，并配置移动端交互：

  fig.update_layout( responsive=True, hovermode='closest', dragmode='zoom', # 允许缩放 xaxis=dict(fixedrange=False), # 允许拖拽 yaxis=dict(fixedrange=False), margin=dict(l=20, r=20, t=20, b=20) )

---

5. 系统部署与性能压测：Nginx + Gunicorn + MySQL 的最小可行架构

5.1 生产环境部署拓扑：为什么不用 Apache，而选 Nginx + Gunicorn？

Apache 适合传统 PHP，但 Python Web 应用（尤其 Django）的并发模型与 Apache 的 prefork MPM 不匹配，易内存溢出。Nginx + Gunicorn 是业界标准：

• Nginx：作为反向代理和静态文件服务器，处理 HTTPS、负载均衡、缓存；
• Gunicorn：Python WSGI HTTP Server，用 pre-fork worker 模型，稳定高效；
• MySQL：独立数据库服务器，与应用分离。

部署结构：

用户浏览器 ↓ HTTPS Nginx（监听 443） ↓ 反向代理到 127.0.0.1:8000 Gunicorn（4 workers, 1000 max requests） ↓ Django 应用 MySQL（监听 3306）

5.2 Gunicorn 配置：worker 数量与内存占用的黄金比例

Gunicorn 的--workers参数不是越多越好。经实测（4 核 8G 云服务器）：

workers	内存占用	QPS（100 并发）	CPU 利用率	说明
2	320MB	85	45%	过少，无法压满 CPU
4	580MB	142	78%	最优，QPS 最高且稳定
6	890MB	138	92%	内存吃紧，偶发 OOM
8	1.2GB	125	98%	CPU 饱和，响应延迟上升

gunicorn.conf.py关键配置：

import multiprocessing # 基础 bind = "127.0.0.1:8000" bind_ssl_certificate = "/etc/letsencrypt/live/yourdomain.com/fullchain.pem" bind_ssl_private_key = "/etc/letsencrypt/live/yourdomain.com/privkey.pem" workers = 4 worker_class = "sync" # 同步模式，稳定优先 worker_connections = 1000 max_requests = 1000 max_requests_jitter = 100 # 资源 timeout = 30 keepalive = 5 preload = True # 预加载应用，避免 fork 后重复加载

5.3 Nginx 配置：静态文件托管与反向代理的 5 行核心指令

Nginx 不仅是代理，更是静态文件 CDN。Django 的collectstatic输出到staticfiles/，Nginx 直接服务

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