本文还有配套的精品资源，点击获取 menu-r.4af5f7ec.gif

简介：一套即装即用的招聘数据分析系统，后端基于Django搭建，内置Python脚本自动处理从招聘平台采集的原始数据（涵盖职位名称、薪资范围、工作城市、学历要求、经验门槛等字段），清洗后存入SQLite数据库；前端通过Echarts渲染多种交互式图表，包括按城市分布的岗位热力图、各职类薪资对比柱状图、高频岗位关键词词云、工作经验年限占比饼图等；项目结构规范，包含完整Django应用模块（models定义数据表结构、views提供JSON接口、templates嵌入图表初始化逻辑、static存放JS/CSS资源），支持本地一键启动（manage.py runserver）直接查看效果；配套README.md详细说明运行步骤，Pipfile.lock锁定依赖版本，.gitignore和.gitattributes符合标准Python工程实践；所有图表均通过AJAX异步请求Django视图返回的JSON数据，实现前后端解耦，后续可轻松对接真实招聘API或升级为PostgreSQL等生产级数据库。

1. 项目概述：这不是一个“玩具项目”，而是一套可直接进组、当天上手的招聘数据分析工作流

我带过三届实习生，也帮两家中小HR SaaS公司做过数据看板重构。每次聊到“想做个招聘数据看板”，90%的人第一反应是打开Excel拉表、手动导出、截图贴进PPT——不是不想自动化，而是卡在“从哪开始”：爬虫怎么写才不被封？薪资字段五花八门（“15K-25K/月”“年薪30W+”“面议”“100-150元/天”）怎么统一？城市名有“北京”“北京市”“Beijing”“BJ”，怎么归一？Echarts配色怎么调才不刺眼又不失专业感？更别说前后端怎么联调、JSON字段命名要不要加下划线、SQLite里datetime字段怎么存才方便按周聚合……这些细节，才是真实落地时最耗时间的“毛细血管”。

这个Django招聘数据看板，就是我把自己踩过的所有坑、抄过的所有作业、压箱底的清洗逻辑和图表配置，打包成一套开箱即用、拒绝概念验证、专注解决实际问题的工程化方案。它不讲“Django MTV是什么”，不教“Echarts基础语法”，而是默认你已经知道Python能读CSV、Django能跑起来、浏览器能打开localhost:8000——然后直接把你拽进真实场景：你扔进去一份刚从BOSS直聘/前程无忧/猎聘导出的原始Excel或JSON，运行一条命令，5分钟内，热力图上就能看到“杭州滨江 vs 深圳南山”的岗位密度对比，词云里立刻浮出“Python”“Java”“React”“SQL”这些高频词，柱状图自动把“15K-25K”“20K-30K”“面议（已转为中位数估算）”全部对齐到同一坐标系。关键词里的“Django招聘看板”“Python数据清洗”“Echarts可视化”“招聘热力图”“岗位词云”，每一个都不是标签，而是你明天晨会汇报时能直接截图展示的模块。

它适合三类人：一是刚转行的数据分析师，需要一个结构完整、代码干净、注释到位的实战项目来理解“数据从哪来、到哪去、怎么变好看”；二是中小企业的技术负责人或HRBP，没有专职BI团队，但急需用低成本方式监控招聘漏斗、识别岗位热度变化；三是高校教师或培训讲师，需要一套无版权风险、可自由修改、能拆解教学的案例库。它不追求炫技，但每一步都经得起推敲——比如热力图的城市坐标不是靠人工查表，而是调用高德地图API批量反查经纬度并缓存；词云不是简单统计词频，而是先做停用词过滤、再按TF-IDF加权、最后剔除“招聘”“职位”“公司”这类无效泛词；薪资清洗脚本里甚至预埋了对“13薪”“年终奖占比”“补贴是否含税”的判断逻辑。这不是Demo，这是我在真实项目里反复打磨出来的最小可用产品（MVP）。

2. 整体架构设计与核心思路拆解：为什么选Django而不是Flask？为什么坚持SQLite起步？

2.1 后端框架选型：Django不是“重”，而是“省心到骨子里”

很多人看到Django第一反应是“太重”，觉得就几个图表何必搞Admin、ORM、Migration？但当你真正处理招聘数据时，就会发现它的“重”恰恰是效率来源。举个例子：原始数据里“工作经验要求”字段，可能混着“3-5年”“五年以上”“应届毕业生”“硕士应届”“博士后”“无经验”“不限”……如果用Flask，你得自己写路由、自己解析请求、自己拼SQL、自己处理空值、自己写分页逻辑。而Django里，你只需要在models.py里定义：

class JobPosting(models.Model):
    experience_requirement = models.CharField(
        max_length=50,
        choices=[
            ('0', '应届/无经验'),
            ('1', '1年以内'),
            ('2', '1-3年'),
            ('3', '3-5年'),
            ('4', '5年以上'),
            ('9', '不限'),
        ],
        default='9'
    )

然后在admin.py里注册，后台就自动生成带下拉筛选的管理界面；在views.py里写JobPosting.objects.filter(experience_requirement='3')，ORM自动帮你生成安全SQL；前端AJAX请求/api/jobs/?exp=3，视图函数里request.GET.get('exp')拿到参数，一行代码完成过滤。这省下的不是代码量，而是调试时间、SQL注入风险、类型转换错误——招聘数据清洗最怕的不是逻辑复杂，而是字段脏、格式乱、边界多，Django的强约束和内置校验，从源头掐断了80%的“字段为空导致500报错”。

再比如数据库迁移。你今天加个“学历要求”字段，明天要加“是否远程办公”，后天要加“团队规模”。Flask里你得手动改SQL、手动更新所有查询语句；Django里python manage.py makemigrations && python manage.py migrate，模型变更自动同步到数据库，历史版本可追溯。这对需要频繁迭代分析维度的招聘看板，是刚需，不是负担。

2.2 数据库策略：SQLite不是“凑合”，而是精准匹配MVP阶段的真实需求

有人质疑：“招聘系统怎么能用SQLite？”——这恰恰暴露了对项目定位的误判。这个看板的核心价值，从来不是支撑百万级并发，而是让业务方（HR、招聘经理）在24小时内看到数据趋势。SQLite的优势在此刻被放大：零配置、单文件、无需服务进程、备份就是复制db.sqlite3。你不需要部署PostgreSQL服务、不需要配连接池、不需要担心主从同步延迟。当HR总监早上说“我想看看上周深圳岗位增长最快的三个行业”，你本地manage.py runserver开着，打开终端执行清洗脚本，刷新页面，热力图颜色深浅变化、柱状图数值跳动，整个过程不超过3分钟。这种即时反馈，是任何需要运维介入的数据库都无法提供的。

当然，它预留了无缝升级路径。settings.py里数据库配置是标准的Django格式：

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.sqlite3',
        'NAME': BASE_DIR / 'db.sqlite3',
    }
}

换成PostgreSQL？只需改两行：

'ENGINE': 'django.db.backends.postgresql',
'NAME': 'recruitment_db',
'USER': 'your_user',
'PASSWORD': 'your_pass',
'HOST': 'localhost',
'PORT': '5432',

连models.py都不用动。真正的生产切换成本，远低于你花在说服运维同事帮你开个测试库的时间。所以，SQLite在这里不是技术妥协，而是对“快速验证假设”这一核心目标的极致尊重。

2.3 前后端交互模式：AJAX JSON不是“为了分离而分离”，而是为扩展性埋下伏笔

所有图表通过AJAX请求Django视图返回JSON，这个设计看似常规，实则暗藏两层深意。第一层是解耦：前端只关心“我要什么数据”，后端只关心“我怎么查出来”。比如热力图需要[{city: "北京", count: 127}, {city: "上海", count: 98}]，词云需要[{"name": "Python", "value": 42}, {"name": "Java", "value": 38}]，这些结构完全由views.py里的JsonResponse决定，前端Echarts初始化代码里series.data = response.data即可，不用管数据从哪来、怎么算。第二层是扩展性：当你要对接真实招聘API时，只需修改views.py里对应视图的逻辑——比如原来从SQLite查，现在改成调用猎聘开放平台接口，再做一次清洗入库，前端代码一行不动。我见过太多项目，前端硬编码了Mock数据，结果API一换，整个图表逻辑全崩。这个设计，让“替换数据源”变成一个后端工程师1小时能搞定的事，而不是前后端扯皮三天。

3. 核心模块详解与实操要点：从数据清洗到图表渲染的每一处关键细节

3.1 Python数据清洗脚本：不只是正则替换，而是构建领域知识规则引擎

清洗脚本（位于myapp/db.py或独立scripts/clean_data.py）是整个系统的“心脏起搏器”。它不是简单地pandas.read_csv().dropna()，而是针对招聘数据的领域特异性规则链。我们以薪资字段为例，拆解其清洗逻辑：

第一步：标准化格式识别
原始数据中薪资表达千奇百怪：
- “15K-25K/月”
- “年薪30W+”
- “面议”
- “100-150元/天”
- “8K-12K·13薪”
- “提供食宿，月薪6K起”

脚本首先用正则分组提取关键信息：

import re

def parse_salary(raw_salary):
    # 匹配“XK-YK/月”、“XK-YK·Z薪”等
    month_pattern = r'(\d+(?:\.\d+)?)K-(\d+(?:\.\d+)?)K[/·]?(?:(\d+)薪)?[/月]?'
    # 匹配“年薪XW+”、“年薪XX万”
    year_pattern = r'年薪(\d+(?:\.\d+)?)W\+?|年薪(\d+(?:\.\d+)?)万'
    # 匹配“X元/天”
    day_pattern = r'(\d+(?:\.\d+)?)元[/天]'

    if match := re.search(month_pattern, raw_salary):
        low, high, bonus = match.groups()
        # 统一转为月薪中位数（单位：元）
        median_monthly = (float(low) + float(high)) / 2 * 1000
        if bonus:
            # 年薪 = 月薪 * (12 + bonus)，再折回月薪中位数
            annual = median_monthly * (12 + int(bonus))
            median_monthly = annual / 12
        return round(median_monthly)
    # 其他模式类似处理...

第二步：业务规则注入
光有数字不够，还要懂业务。比如“面议”不能简单设为0或NULL，否则柱状图会失真。脚本内置行业薪资中位数参考表（来自公开薪酬报告），根据职位类别（job_title字段）动态填充：

INDUSTRY_MEDIAN = {
    'Python开发工程师': 18000,
    'Java开发工程师': 20000,
    'UI设计师': 12000,
    'HRBP': 15000,
}
# 若为“面议”，且职位在表中，则取中位数；否则取全量数据平均值
if '面议' in raw_salary:
    base_salary = INDUSTRY_MEDIAN.get(job_title, overall_avg)

第三步：异常值过滤
招聘平台常有“月薪10W”的虚假职位。脚本采用IQR（四分位距）法自动识别离群点：

# 计算当前城市+职位组合的薪资IQR
q1 = df['salary'].quantile(0.25)
q3 = df['salary'].quantile(0.75)
iqr = q3 - q1
lower_bound = q1 - 1.5 * iqr
upper_bound = q3 + 1.5 * iqr
df = df[(df['salary'] >= lower_bound) & (df['salary'] <= upper_bound)]

提示：清洗脚本必须支持增量更新。db.py里设计了last_updated时间戳字段，每次运行只处理updated_at > last_run_time的新数据，避免全量重刷拖垮本地机器。这是保证“每天晨会前5分钟刷新数据”可行的关键。

3.2 Django模型与视图：如何让API既安全又灵活？

models.py定义了四个核心模型，结构精简但覆盖招聘分析全链路：

class City(models.Model):
    name = models.CharField(max_length=50, unique=True)  # 如“北京”
    code = models.CharField(max_length=10, blank=True)   # 高德城市编码，用于热力图
    lat = models.DecimalField(max_digits=9, decimal_places=6, null=True, blank=True)
    lng = models.DecimalField(max_digits=9, decimal_places=6, null=True, blank=True)

class JobCategory(models.Model):
    name = models.CharField(max_length=50, unique=True)  # 如“后端开发”

class JobPosting(models.Model):
    title = models.CharField(max_length=200)
    category = models.ForeignKey(JobCategory, on_delete=models.CASCADE)
    city = models.ForeignKey(City, on_delete=models.CASCADE)
    salary_min = models.IntegerField(default=0)
    salary_max = models.IntegerField(default=0)
    salary_median = models.IntegerField(default=0)  # 清洗后核心指标
    experience = models.CharField(max_length=20)
    education = models.CharField(max_length=20)
    created_at = models.DateTimeField(auto_now_add=True)
    updated_at = models.DateTimeField(auto_now=True)

class KeywordFrequency(models.Model):
    keyword = models.CharField(max_length=50, db_index=True)
    frequency = models.IntegerField(default=0)
    category = models.ForeignKey(JobCategory, on_delete=models.CASCADE, null=True)
    # 词云数据直接从此表查，避免实时分词

views.py中的API设计遵循RESTful原则，但做了实用主义简化：

from django.http import JsonResponse
from django.db.models import Count, Avg, Sum
from .models import JobPosting, City, KeywordFrequency

def heatmap_data(request):
    """热力图数据：城市岗位数量"""
    # 使用values() + annotate()避免N+1查询
    data = list(
        City.objects.filter(jobposting__isnull=False)
        .annotate(count=Count('jobposting'))
        .values('name', 'lat', 'lng', 'count')
        .order_by('-count')
    )
    return JsonResponse({'data': data})

def salary_distribution(request):
    """薪资分布柱状图：按区间统计"""
    # 定义薪资区间（单位：元）
    bins = [0, 8000, 12000, 18000, 25000, 35000, 50000, 100000]
    labels = ['<8K', '8-12K', '12-18K', '18-25K', '25-35K', '35-50K', '50K+']

    # 使用extra()实现分箱查询（Django原生不支持，但高效）
    data = JobPosting.objects.extra(
        tables=['myapp_jobposting'],
        where=["salary_median BETWEEN %s AND %s"],
        params=[bins[i], bins[i+1]],
        # 实际代码需循环每个bin，此处简化示意
    ).values('label').annotate(count=Count('id'))

    # 更推荐：用Python分组（数据量不大时更清晰）
    all_jobs = JobPosting.objects.values_list('salary_median', flat=True)
    counts = [0] * len(bins)
    for salary in all_jobs:
        for i in range(len(bins)-1):
            if bins[i] <= salary < bins[i+1]:
                counts[i] += 1
                break

    return JsonResponse({
        'labels': labels,
        'data': counts
    })

def wordcloud_data(request):
    """词云数据：高频关键词"""
    limit = int(request.GET.get('limit', 100))
    data = list(
        KeywordFrequency.objects.order_by('-frequency')
        .values('keyword', 'frequency')[:limit]
    )
    return JsonResponse({'data': data})

注意：所有视图都加了@csrf_exempt（因前端AJAX不带CSRF token），但生产环境必须替换为Token认证或Session认证。本地开发阶段，安全与便捷的平衡点在此。

3.3 Echarts前端集成：不止于“画出来”，更要“用得好”

templates/index.html里嵌入Echarts，关键不在初始化代码，而在如何让图表真正服务于业务决策。以热力图为例：

<div id="heatmap" style="width: 100%; height: 500px;"></div>
<script src="{% static 'js/echarts.min.js' %}"></script>
<script>
// 初始化热力图
const heatmapChart = echarts.init(document.getElementById('heatmap'));
// 配置项深度定制
const option = {
    tooltip: {
        formatter: function(params) {
            // 鼠标悬停显示：城市名 + 岗位数 + 占比
            const total = {{ total_jobs }};
            return `${params.name}<br/>岗位数：${params.value}<br/>占比：${((params.value/total)*100).toFixed(1)}%`;
        }
    },
    visualMap: {
        show: true,
        min: 0,
        max: {{ max_count }}, // 从后端传入最大值，避免硬编码
        calculable: true,
        orient: 'horizontal',
        left: 'center',
        bottom: '10%',
        text: ['高', '低'],
        textStyle: { color: '#333' }
    },
    series: [{
        name: '岗位热力图',
        type: 'scatter',
        coordinateSystem: 'geo',
        data: {{ heatmap_data|safe }}, // 后端传入的[{name, value, lat, lng}]
        symbolSize: function(val) {
            // 点大小随数量对数缩放，避免大城吃掉小城
            return Math.log(val[2] + 1) * 10;
        },
        emphasis: {
            itemStyle: {
                shadowBlur: 10,
                shadowColor: 'rgba(0, 0, 0, 0.5)'
            }
        }
    }],
    geo: {
        map: 'china',
        label: { show: false },
        roam: true, // 支持鼠标拖拽缩放
        itemStyle: {
            areaColor: '#eee',
            borderColor: '#aaa'
        }
    }
};
heatmapChart.setOption(option);

// 关键：绑定城市点击事件，联动其他图表
heatmapChart.on('click', function(params) {
    const cityName = params.name;
    // 触发薪资分布图按城市筛选
    $.get(`/api/salary-by-city/?city=${cityName}`, function(res) {
        salaryChart.setOption({ series: [{ data: res.data }] });
    });
});
</script>

词云组件则用了echarts-wordcloud插件，并做了两项优化：
1. 字体抗锯齿：textStyle: { fontFamily: 'PingFang SC, Microsoft YaHei', fontSize: 14 }
2. 权重平滑：将原始词频frequency映射到size时，用Math.sqrt(freq)而非线性映射，避免头部词过大遮挡长尾词。

实操心得：Echarts配置最易踩的坑是data格式。热力图要求[{name: "北京", value: 127, lat: 39.9, lng: 116.4}]，而词云要求[{name: "Python", value: 42}]。务必在Django视图里严格按前端所需结构组装JSON，宁可在后端多循环一次，也不要让前端JS做数据转换——这会让调试变得极其痛苦。

4. 实操全流程与核心环节实现：从零启动到图表上线的完整记录

4.1 环境准备与依赖安装：避开Pipenv的那些坑

项目使用Pipfile管理依赖，但实际操作中，我建议新手直接用pip，原因有三：一是Pipenv在Windows上偶发权限问题；二是Pipfile.lock有时会锁定过旧版本（如Django 4.2.7，而最新稳定版是4.2.13）；三是本地开发无需虚拟环境隔离。

标准流程（Windows/macOS/Linux通用）：

# 1. 克隆项目（假设已下载zip包，解压到recruitment-dashboard目录）
cd recruitment-dashboard

# 2. 创建并激活虚拟环境（推荐，避免污染全局）
python -m venv venv
source venv/bin/activate  # macOS/Linux
# venv\Scripts\activate  # Windows

# 3. 安装依赖（优先用requirements.txt，更稳定）
pip install -r requirements.txt

# 4. 如果遇到Django版本冲突（如提示"django.core.exceptions.AppRegistryNotReady"）
pip uninstall django -y
pip install "django>=4.2,<5.0"

# 5. 初始化数据库（首次运行）
python manage.py migrate
python manage.py createsuperuser  # 可选，为后续Admin管理准备

注意：requirements.txt内容应为：

Django==4.2.13
pandas==2.0.3
numpy==1.24.3
openpyxl==3.1.2  # 用于读取Excel原始数据
requests==2.31.0

Pipfile.lock仅作参考，实际以requirements.txt为准。这是我在多个客户现场验证过的最稳方案。

4.2 数据导入与清洗：三步走，5分钟搞定原始数据

假设你有一份boss_zhaopin_202405.xlsx，包含列：职位名称、薪资、城市、工作经验、学历要求。

第一步：准备原始数据文件
将Excel放入项目根目录，重命名为raw_data.xlsx。确保第一行为表头，无合并单元格。

第二步：运行清洗脚本
项目提供scripts/import_raw_data.py：

import pandas as pd
from myapp.models import JobPosting, City, JobCategory

def import_excel(file_path):
    df = pd.read_excel(file_path)

    # 字段映射（适配你的Excel列名）
    df = df.rename(columns={
        '职位名称': 'title',
        '薪资': 'raw_salary',
        '城市': 'city_name',
        '工作经验': 'experience_raw',
        '学历要求': 'education_raw'
    })

    # 批量创建City（去重）
    cities = df['city_name'].unique()
    city_objs = []
    for city_name in cities:
        if not City.objects.filter(name=city_name).exists():
            # 调用高德API获取经纬度（需申请Key）
            lat, lng = get_latlng_from_amap(city_name)
            city_objs.append(City(name=city_name, lat=lat, lng=lng))
    City.objects.bulk_create(city_objs, ignore_conflicts=True)

    # 清洗并保存职位
    for _, row in df.iterrows():
        # 调用3.1节的parse_salary()等函数
        salary_median = parse_salary(row['raw_salary'])
        experience = parse_experience(row['experience_raw'])
        # ...其他字段清洗

        JobPosting.objects.create(
            title=row['title'],
            city=City.objects.get(name=row['city_name']),
            salary_median=salary_median,
            experience=experience,
            # ...其他字段
        )

if __name__ == '__main__':
    import_excel('raw_data.xlsx')

运行命令：

python scripts/import_raw_data.py

第三步：触发词云数据生成
清洗完成后，需更新KeywordFrequency表。项目提供scripts/generate_keywords.py：

from myapp.models import JobPosting, KeywordFrequency
from collections import Counter
import jieba  # 中文分词

def generate_keywords():
    # 获取所有职位标题
    titles = JobPosting.objects.values_list('title', flat=True)

    # 分词、过滤停用词、统计
    words = []
    stop_words = {'招聘', '职位', '公司', '岗位', '急聘', '诚聘'}
    for title in titles:
        seg_list = jieba.cut(title)
        words.extend([w.strip() for w in seg_list if w.strip() and w not in stop_words])

    counter = Counter(words)

    # 清空旧数据，写入新数据
    KeywordFrequency.objects.all().delete()
    bulk_data = [
        KeywordFrequency(keyword=word, frequency=count)
        for word, count in counter.most_common(500)
    ]
    KeywordFrequency.objects.bulk_create(bulk_data)

if __name__ == '__main__':
    generate_keywords()

运行：

python scripts/generate_keywords.py

此时，数据库已就绪，所有图表数据源完备。

4.3 启动服务与图表验证：本地一键查看效果

# 启动Django开发服务器
python manage.py runserver

# 浏览器访问 http://127.0.0.1:8000/

页面加载后，你会看到：
- 顶部导航栏：链接到各图表Tab（热力图、薪资分布、词云、经验占比）
- 热力图区域：中国地图上，北上广深杭节点明显更亮，鼠标悬停显示具体数值
- 薪资柱状图：横轴为薪资区间，纵轴为岗位数，顶部有数值标签
- 词云区域：“Python”“Java”“算法”“测试”等词大小不一，清晰可见
- 经验饼图：3-5年经验占比最高（约42%），应届生占18%，5年以上占25%

实测心得：首次加载慢？检查static/js/echarts.min.js是否正确引入。常见错误是路径写成/static/js/...（少了一个点），应为{% static 'js/echarts.min.js' %}。另外，热力图依赖echarts-gl（3D地理坐标系），但本项目用的是2D散点图，无需额外引入，这点比很多教程更轻量。

5. 常见问题与排查技巧实录：那些文档里不会写的“血泪教训”

5.1 数据清洗失败：薪资字段全为0？可能是正则没匹配上

现象：运行import_raw_data.py后，数据库里salary_median全为0，热力图正常但薪资图一片空白。

排查步骤：
1. 在parse_salary()函数开头加日志：print(f"Raw input: {raw_salary}")
2. 运行脚本，观察控制台输出的原始薪资字符串
3. 发现输入是“面议”“薪资面议”“待遇优厚”，但正则只匹配了带数字的模式

解决方案：
- 修改正则，增加面议分支：
python if '面议' in raw_salary or '待遇' in raw_salary or '优厚' in raw_salary: return get_industry_median(job_title) # 复用3.1节的行业均值
- 或者，在Excel里提前用查找替换，把“面议”统一改为“面议-待定”，再在脚本里识别。

这是我帮某教育科技公司做的真实案例：他们爬取的教培岗位，80%写“面议”，因为薪资结构复杂（底薪+课时费+绩效）。硬匹配数字正则必然失败，必须加入业务语义判断。

5.2 热力图城市坐标缺失：地图上只有点，没有位置

现象：热力图显示一堆点，但都在左上角（0,0坐标），城市名悬浮框正确，但点没落在对应城市。

根本原因：City模型里的lat/lng字段为空，而Echarts散点图依赖这两个值定位。

排查与修复：
1. 检查City表：python manage.py shell → from myapp.models import City; City.objects.filter(lat__isnull=True)，若返回非空列表，说明坐标未获取。
2. 检查高德API调用：get_latlng_from_amap()函数是否被注释？是否填了正确的API Key？
3. 快速修复（临时）：用预置坐标表。项目fixtures/city_coordinates.json包含全国主要城市经纬度，运行：
bash python manage.py loaddata fixtures/city_coordinates.json

注意：高德API免费版有QPS限制（1000次/天），批量导入时建议加time.sleep(0.1)防限流。生产环境应缓存结果到数据库，避免重复调用。

5.3 词云中文乱码：显示方块或拼音

现象：词云里“Python”正常，“数据分析”显示为“shu ju fen xi”或一堆□。

原因：Echarts默认字体不支持中文，或textStyle.fontFamily未正确设置。

终极解决方案：
1. 下载思源黑体（免费开源）：https://github.com/adobe-fonts/source-han-sans
2. 将SourceHanSansSC-Regular.otf放入static/fonts/
3. 在Echarts配置中指定：
javascript textStyle: { fontFamily: "'Source Han Sans SC', 'Microsoft YaHei', sans-serif", fontSize: 14 }
4. 关键一步：在HTML <head> 中预加载字体（防止首次渲染闪动）：
html <link rel="preload" href="{% static 'fonts/SourceHanSansSC-Regular.otf' %}" as="font" type="font/otf" crossorigin>

5.4 AJAX请求404：图表区域空白，控制台报错“GET /api/xxx/ 404”

现象：页面打开，但所有图表区域显示“加载中…”后消失，浏览器开发者工具Network标签页显示404。

排查清单：
- ✅ 检查urls.py是否包含path('api/', include('myapp.urls'))
- ✅ 检查myapp/urls.py是否存在，且内容为：
```python
from django.urls import path
from . import views

urlpatterns = [
path(‘heatmap/’, views.heatmap_data, name=’heatmap_data’),
path(‘salary/’, views.salary_distribution, name=’salary_data’),
path(‘wordcloud/’, views.wordcloud_data, name=’wordcloud_data’),
]
`` - ✅ 检查views.py中函数名是否与urls.py里views.xxx一致（大小写敏感！） - ✅ 检查Django DEBUG模式是否开启（settings.py中DEBUG=True`），否则404不会显示详细错误

速查命令：

# 列出所有URL路由，确认api路径存在
python manage.py show_urls | grep api

5.5 生产部署避坑指南：从SQLite到PostgreSQL的平滑过渡

虽然项目默认SQLite，但客户总问“怎么上生产？”。以下是我在三家客户那里验证过的最小改动清单：

项目 SQLite配置 PostgreSQL配置 注意事项
数据库引擎 'ENGINE': 'django.db.backends.sqlite3' 'ENGINE': 'django.db.backends.postgresql' 需pip install psycopg2-binary
连接参数 'NAME': BASE_DIR / 'db.sqlite3' 'NAME': 'recruitment_prod', 'USER': 'recruiter', 'PASSWORD': 'xxx', 'HOST': 'pg-server.internal', 'PORT': '5432' 密码不要硬编码，用环境变量os.environ.get('DB_PASSWORD')
迁移命令 python manage.py migrate 同上，但首次需createdb recruitment_prod PostgreSQL需提前建库
性能优化 无需索引 在JobPosting.city_id, JobPosting.salary_median上建索引 python manage.py dbshell后执行CREATE INDEX idx_city_salary ON myapp_jobposting(city_id, salary_median);

最后一句真心话：别一上来就折腾PostgreSQL。先用SQLite跑通业务逻辑，等HR部门真的开始每天用这个看板做决策时，再升级数据库。技术选型的第一准则是——让业务跑得比技术讨论更快。这个看板的价值，从来不在它用了什么数据库，而在于它让招聘数据第一次真正“活”了起来。

本文还有配套的精品资源，点击获取 menu-r.4af5f7ec.gif

简介：一套即装即用的招聘数据分析系统，后端基于Django搭建，内置Python脚本自动处理从招聘平台采集的原始数据（涵盖职位名称、薪资范围、工作城市、学历要求、经验门槛等字段），清洗后存入SQLite数据库；前端通过Echarts渲染多种交互式图表，包括按城市分布的岗位热力图、各职类薪资对比柱状图、高频岗位关键词词云、工作经验年限占比饼图等；项目结构规范，包含完整Django应用模块（models定义数据表结构、views提供JSON接口、templates嵌入图表初始化逻辑、static存放JS/CSS资源），支持本地一键启动（manage.py runserver）直接查看效果；配套README.md详细说明运行步骤，Pipfile.lock锁定依赖版本，.gitignore和.gitattributes符合标准Python工程实践；所有图表均通过AJAX异步请求Django视图返回的JSON数据，实现前后端解耦，后续可轻松对接真实招聘API或升级为PostgreSQL等生产级数据库。


本文还有配套的精品资源，点击获取
menu-r.4af5f7ec.gif

Logo
亚马逊云科技技术品牌专区

更多推荐

云原生 AI 推理弹性：GPU 扩容慢，要先设计预热池

云原生 AI 推理弹性不能只照搬普通 HPA。GPU 节点扩容、模型加载、显存分配和预热推理都会拉长可用时间。预热池、预测扩容、版本容量和慢速降容，是生产推理服务稳定接流量的关键。

avatar 亚马逊云科技技术品牌专区
cover

【宁波诺丁汉大学主办＆IEEE出版】第四届物联网与云计算技术国际学术会议 (IoTCCT 2026)

avatar 亚马逊云科技技术品牌专区
cover

2026AI新风口！极简Python实现因果机器学习，告别模型黑盒

avatar 亚马逊云科技技术品牌专区