企业官网建设流程全解析

先说说我为什么推荐这个选题。程序员薪资分析系统，是这几年计算机/大数据方向毕设里少见的“性价比”很高的题目——它同时踩中了几个关键点：有明确的数据采集场景（爬虫）、有完整的数据处理链路（清洗—存储—分析）、有直观的成果展示（可视化大屏）、还能结合不同岗位/城市/学历等维度做多样化分析。对做毕设的同学来说，好处是每个环节都有现成工具可以落地，不容易卡死在某一个技术点上；对答辩老师来说，这个题目能问的角度特别多——从爬虫合规性到特征选择再到可视化交互，层层都能挖，说明它具备足够的“可延展性”。

这篇博客我就从“这套系统到底怎么设计和实现”这个角度，把整个项目的完整链路拆开讲清楚。无论你是还没定题的大四学生，还是想把代码改成自己风格的初学者，都可以把这套思路当底稿，按需裁剪。

1. 项目定位与核心需求拆解

1.1 这个系统到底是做什么的

一句话概括：采集主流招聘平台上计算机相关岗位的公开招聘信息，经过数据清洗和结构化处理后，从城市、学历、工作经验、技能要求、薪资范围等多个维度做统计分析，最终用一个可视化看板把结果展示出来。

听起来不复杂，但把它拆成需求清单，大概有这么几块：

• 数据采集模块：从招聘网站抓取岗位名称、公司、城市、学历要求、经验要求、薪资区间、技能标签等字段。
• 数据存储模块：把半结构化的爬取结果清洗后存入数据库，一般用MySQL。
• 数据分析模块：基于存储的数据做聚合统计，比如“北京Java岗的平均薪资范围”“3-5年经验的Python开发薪资分布”。
• 可视化模块：用图表呈现分析结果，常见方案是Flask/ECharts组合，或者直接写成前后端分离的页面。
• 非功能需求：数据去重、异常值处理、爬虫异常恢复、页面加载性能，这些看起来不起眼，但在毕设答辩里反而是区分度很高的加分项。

1.2 为什么要选Python作为核心技术栈

Python在这个项目里的优势主要在于“全链路覆盖”。爬虫阶段有requests、Scrapy、BeautifulSoup；数据处理阶段有pandas、numpy；后端服务可以直接用Flask或Django；可视化部分有pyecharts、Flask结合ECharts；机器学习如果后续扩展，还有scikit-learn。一个语言从头写到尾，不需要像Java方案那样在多套技术栈之间来回切换，对毕业设计阶段的时间管理非常友好。

另外，Python的生态里很多库的学习曲线比较平缓。比如pandas处理Excel和CSV那套操作，基本就是几行代码搞定数据透视表的事情。这对之前没有太多项目经验的同学来说，能减少很多挫败感。

1.3 核心功能模块的划分逻辑

我把系统按“数据流向”切成了五层，每层之间只通过接口通信：

1. 数据采集层：只负责抓取和解析，不关心数据怎么用。
2. 数据清洗层：接收原始数据，处理缺失值、重复值、薪资字段的区间拆分等。
3. 持久化层：定义数据库表结构，提供增删改查接口。
4. 分析计算层：从数据库读出数据，做统计分析，返回结构化结果。
5. 展示层：接收分析结果，渲染图表和页面。

这个划分的好处有两个：一是每一层都可以单独测试，比如你可以先写死一段CSV数据来做可视化，不用等爬虫完善；二是答辩时被问“如果数据量变大怎么办”，你可以说“采集层可以换分布式爬虫，分析层可以接Spark”，扩展思路非常清晰。

2. 技术选型和系统架构设计

2.1 工具选型与版本选择思路

核心组件我建议这么选：

这里我不是说选型越新越好，而是强调“稳定优先”。有一个常见误区是同学一上来就选最新版的Python 3.13或者最新框架，结果第三方库还没适配，各种报错层出不穷，非常打击积极性。毕设项目不比生产环境，不用追逐前沿版本，稳定可复现才是第一位的。

2.2 系统整体架构与数据流设计

系统整体架构可以从“横纵”两个方向来看。

横向是功能分层，也就是前面说的采集层、清洗层、存储层、分析层、展示层。纵向是数据流动，从招聘平台页面开始，爬虫解析出原始记录，存入临时表，清洗后写入正式表，分析模块从正式表抽取数据做聚合，最后通过JSON接口输出到前端渲染。整个链路清晰以后，代码写起来就很少出现“东写一块西写一块”的情况。

关于数据流，我特别想强调一点：清洗和存储之间一定要有一层“缓冲区”。很多同学爬完数据直接入库，后面发现某个字段解析错了或者需要去重，又得写脚本去数据库里改，很痛苦。如果中间加了临时表或者CSV缓冲，数据回滚和重新清洗就方便得多。

2.3 为什么用Flask而不是Django

Django功能全，自带Admin后台和ORM，适合大型项目；Flask则更像一个“积木框架”，你想要什么功能自己加。针对毕设这个场景，我建议用Flask。原因有三个：

• Flask路由简单，对前后端分离的支持非常直接。
• 项目规模不大时，Django的“全家桶”特性反而显得臃肿，答辩时解释起中间件、CSRF、ORM映射那一套可能会把自己绕进去。
• Flask写接口返回JSON特别方便，ECharts可以直接消费，减少了模板渲染的复杂度。

如果你之前已经学了Django，那用Django也不是不行，核心逻辑完全一致。我只是建议：不要在选型上花太多时间，两个都能做，关键是赶紧把数据跑起来。

3. 数据集构建与爬虫采集实现

3.1 数据采集的整体策略

招聘类网站的反爬手段这几年升级明显，早期那种直接写个循环请求几百页的做法基本行不通。我建议的策略是“多维度、限频、重试、断点续爬”四管齐下。

• 多维度：除了岗位关键词，还可以按城市、薪资范围、学历要求分别搜索，再从搜索结果页提取详情页链接。这样采集到的数据覆盖度更高。
• 限频：每次请求间隔随机延时3到5秒，尽量模拟人的操作节奏。
• 重试：针对请求失败或返回异常码的情况，设置最多3次重试，重试间隔递增。
• 断点续爬：已经爬过的URL存一份记录，下次启动时跳过，避免重复请求。

3.2 数据字段设计与去重规则

目标字段我设计成了这样：

去重规则我用的组合是“公司名+岗位名+城市+薪资区间”四字段联合去重。原因很简单：同一个公司可能多次发布同一个岗位，但薪资和地点一般不会频繁变动。如果只用岗位名去重，会把真实的不同岗位误删；如果字段太多，又会因为细微差别导致重复数据漏网。

3.3 爬虫代码的骨架示例

这里我用requests + BeautifulSoup写一个简化的采集流程，方便你把整体思路落地。

import requests import time import random from bs4 import BeautifulSoup HEADERS = { "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 Chrome/120.0 Safari/537.36" } def fetch_page(keyword: str, city: str, page: int): url = "https://example.com/jobs/search" params = {"keyword": keyword, "city": city, "page": page} for attempt in range(3): try: resp = requests.get(url, headers=HEADERS, params=params, timeout=10) if resp.status_code == 200: return resp.text elif resp.status_code == 403: print("触发反爬，等待后重试") time.sleep(10) else: print("非预期状态码:", resp.status_code) except requests.RequestException as e: print("请求异常:", e) time.sleep(2 * (attempt + 1)) return None def parse_jobs(html: str): soup = BeautifulSoup(html, "html.parser") job_items = soup.select(".job-item") result = [] for item in job_items: title = item.select_one(".job-title").text.strip() company = item.select_one(".company-name").text.strip() salary_text = item.select_one(".salary").text.strip() salary_min, salary_max = parse_salary(salary_text) result.append({ "job_title": title, "company_name": company, "salary_min": salary_min, "salary_max": salary_max, }) return result def parse_salary(salary_text: str): # 示例输入 "15-25K·14薪" import re pattern = r"(\d+)-(\d+)K" match = re.search(pattern, salary_text) if match: return int(match.group(1)), int(match.group(2)) return None, None

实际项目中，你还需要把city、education等参数传进请求，同时注意处理动态加载的页面。如果目标网站的数据是AJAX加载的，可以用Selenium或者直接分析接口地址来获取JSON数据，后者效率更高，但需要花费时间分析请求参数。

3.4 爬虫合规性的几条实操建议

关于爬虫，我多说几句，这也是答辩容易被问到的点。

在毕设场景下，你采集的公开信息主要用于学习研究，原则上没有问题，但还是要做几点防护：控制请求频率，不搞并发轰炸；只采集公开可见信息，不碰用户隐私数据；如果网站有robots协议，最好尊重一下。诚信声明这块，在论文里也要写清楚“数据来源为公开信息，仅用于学术分析”。

实操上有一个容易被忽略的细节：User-Agent一定要随机化，不能所有请求都用同一个浏览器标识。可以用fake-useragent这个库，每次请求随机生成一个UA，能显著降低被识别为爬虫的概率。

4. 薪资数据清洗与预处理详解

4.1 薪资字段的拆分与标准化

很多平台的招聘信息里，薪资是写成“15-25K·14薪”、“30-60K·16薪”或者“3-5万·12薪”这种混合文本的。如果不清洗，直接拿来做均值比较毫无意义。

我一般这样处理：

1. 先把统一单位换算成K。比如出现“万”，就乘以10。
2. 用正则把数字区间提取出来，拆成salary_min和salary_max。
3. 对于“薪资面议”这种无具体数值的记录，可以单独打标签，不参与数值统计。
4. 对于“15-20K·14薪”中的“14薪”信息，可以单独存放，作为年终薪制分析的一维。

import re import pandas as pd def salary_to_k(salary_text: str): if not salary_text or "面议" in salary_text: return None, None # 统一单位 text = salary_text.replace("万", "K") text = re.sub(r"·.*", "", text) # 去掉 14薪等 nums = re.findall(r"\d+", text) if len(nums) < 2: return None, None return int(nums[0]), int(nums[1]) df["salary_min"], df["salary_max"] = zip(*df["salary_text"].apply(salary_to_k)) df = df.dropna(subset=["salary_min", "salary_max"])

清洗之后，建议做一个异常值筛查，比如salary_max > 200或者salary_min > salary_max的记录，往往是解析错误，要直接剔除或人工确认。这个环节如果在答辩时被问到，说明你的数据预处理已经做到了“知其所以然”的层面。

4.2 技能标签的分词与标准化

技能标签的清洗比薪资更头疼，因为同一项技能有多种写法。比如“Python”“python”“PYTHON”，还有“NodeJS”“node.js”“Node.js”这种同义词。

我常用的做法是：构建一个小型的“同义词映射表”，把常见写法统一到标准名称。

skill_mapping = { "python": "Python", "py": "Python", "nodejs": "Node.js", "node.js": "Node.js", "node": "Node.js", "vue": "Vue.js", "vue.js": "Vue.js", "reactjs": "React", }

然后做两步：先对标签做小写归一化，再查映射表替换为正式名称。做完之后，再用pandas的value_counts看一下排序，基本能了解当前市场上最热门的技能要求Top20，这也可以作为后续“技能-薪资”分析的主要输入。

4.3 字段缺失时的处理策略

在真实爬取数据中，总会有少量记录存在字段缺失。处理方式不能一概而论：

• 如果城市缺失：可以通过公司信息或搜索关键词补全。
• 如果学历缺失：往往出现在一些中小型公司，可以归为“不限”。
• 如果经验缺失：同理归为“不限”。
• 如果薪资缺失：直接剔除或单独分析，不影响整体统计口径。

这里有一个原则：宁可剔除一小部分脏数据，也不要硬造数据。答辩老师如果听到你说“我用均值填充了缺失薪资”，大概率会追问“这样会不会引入偏差”，到时候就比较难自圆其说。

5. 数据库设计与持久化实现

5.1 表结构设计：三层分离，避免冗余

我把数据库表分成了三层：原始表、清洗表、分析结果缓存表。原始表存爬虫刚解析完的数据，字段类型比较宽松，甚至可以直接用JSON；清洗表是结构化的正式数据，包含所有分析字段，按固定规则去重和校验；分析结果缓存表用于存放耗时的统计结果。

以核心的job_info表为例，DDL是这样的：

CREATE TABLE job_info ( id INT PRIMARY KEY AUTO_INCREMENT, job_title VARCHAR(100), company_name VARCHAR(100), city VARCHAR(20), salary_min INT, salary_max INT, experience_min INT, experience_max INT, education VARCHAR(20), skills VARCHAR(500), publish_date DATE, source VARCHAR(50), create_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP, KEY idx_city (city), KEY idx_salary_min (salary_min) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

设计索引的时候，我只给city和salary_min加了索引。因为在真实查询中，最常见的就是按城市分组求平均薪资，或者按薪资范围过滤岗位。索引不是越多越好，每个索引都会占用空间并拖慢写入速度，这个取舍要明白。

5.2 数据库连接与ORM选择

如果项目规模不大，直接用pymysql写SQL就可以了，直观且不容易出问题。如果希望代码可读性更好，可以用SQLAlchemy作ORM。我用的是后者，因为分析代码里经常要用pandas读取数据库，而pd.read_sql直接传入SQL字符串最方便。

from sqlalchemy import create_engine import pandas as pd engine = create_engine("mysql+pymysql://root:password@localhost:3306/salary_db?charset=utf8mb4") df = pd.read_sql("SELECT city, salary_min, salary_max FROM job_info", engine)

这里要提醒一下：连接字符串里的密码千万不要写进Git仓库。建议用配置文件或环境变量管理数据库连接信息，这个习惯在校招面试时也是加分项。

5.3 入库性能优化：批量插入

爬虫采集到的数据量通常不大，几百条到几千条，直接循环插入也没大问题。但如果你代码写得比较高效，批量插入的效率优势会很明显。

data = [ ("Python开发", "某公司", "北京", 15, 25, 3, 5, "本科", "['Python', 'Django']", "2025-05-10"), ("Java开发", "某公司", "上海", 20, 30, 3, 5, "本科", "['Java', 'Spring']", "2025-05-11"), ] insert_sql = """ INSERT INTO job_info (job_title, company_name, city, salary_min, salary_max, experience_min, experience_max, education, skills, publish_date) VALUES (%s, %s, %s, %s, %s, %s, %s, %s, %s, %s) """ cursor.executemany(insert_sql, data) connection.commit()

用executemany批量插入，比for循环单条插入快了一个量级。另一个细节是：先删除再插入还是直接追加，要看场景。如果是重新跑清洗流程，建议先按批次删除再批量插入，保证表里不会有残留旧数据。

6. 薪资分析模型与核心指标设计

6.1 分析维度的选取思路

分析维度不能为了多而多，每个维度都要能回答一个问题。我在系统里设了六个主要分析维度：

• 城市维度：哪个城市程序员薪资最高，不同城市的中位数差异有多大。
• 岗位维度：Java、Python、前端等岗位的薪资对比。
• 学历维度：本科和硕士的起薪差距，学历对薪资上限的影响。
• 经验维度：0-1年、1-3年、3-5年、5-10年的薪资增长趋势。
• 技能维度：掌握哪些技能平均薪资更高。
• 公司类型维度：大厂和创业公司、外包公司的薪资分布差异。

每个维度下再细分出均值、中位数、分位数（25%和75%）、薪资区间分布图。中位数比均值更能反映真实水平，因为少数的“高薪神话”会把平均薪资拉得很高。

6.2 薪资分析的关键计算方法

这里以“城市平均薪资”为例，说明计算过程。由于每个岗位给出的薪资是区间，我采用中位值法，即先计算每条记录的薪资中位值，再按城市做加权平均。

df["salary_mid"] = (df["salary_min"] + df["salary_max"]) / 2 city_stats = df.groupby("city")["salary_mid"].agg(["mean", "median", "count"]) city_stats = city_stats.sort_values("median", ascending=False)

如果你有“14薪”的数据，还可以把年薪换算成年包，做更精细的比较：

df["annual_salary"] = df["salary_mid"] * df["salary_months"]

这里salary_months如果字段没有，可以用默认12代替。配上年终月数以后，可以分析“名义月薪”和“实际年包”之间的差异，很多公司月薪不高但年终丰厚，这个维度会让分析报告更有深度。

6.3 技能与薪资的关联分析

技能与薪资的关联分析是这套系统里比较出彩的部分。做法很简单：先对技能标签做One-Hot编码，然后计算“掌握该技能的岗位平均薪资”减去“所有岗位平均薪资”，得到一个差值排序。

from sklearn.preprocessing import MultiLabelBinarizer mlb = MultiLabelBinarizer() skill_matrix = mlb.fit_transform(df["skills_list"]) skill_df = pd.DataFrame(skill_matrix, columns=mlb.classes_) average_salary = df["salary_mid"].mean() skill_salary_diff = {} for col in skill_df.columns: skill_jobs = df[skill_df[col] == 1] if len(skill_jobs) >= 10: # 样本量太少的技能不考虑 skill_salary_diff[col] = skill_jobs["salary_mid"].mean() - average_salary skill_salary_rank = pd.Series(skill_salary_diff).sort_values(ascending=False)

注意筛选原则：技能出现频次低于10的岗位记录不参与统计，否则个别样本会得出离谱结论。这个思想叫“支持度”，算是简单版关联规则挖掘的雏形，可以在论文里写一笔。

6.4 可视化图表的选择原则

图表不是越多越好，关键是信息传递清楚。我最终选定的图表类型是：

ECharts的boxplot组件对箱线图的适配很不错，pyecharts也封装了对应接口。如果你用原生ECharts，可以从后端直接生成JSON格式的统计结果，前端动态渲染。

7. 可视化大屏与后端接口实现

7.1 大屏页面的布局设计

可视化大屏的布局直接影响第一印象。常规做法是：顶部为标题和全局筛选器，中间主体分为左、中、右三列，左边放城市薪资排行和学历分析，中间放地图或核心KPI卡片，右边放技能热度和经验趋势。这样一屏可以容纳两个核心图表，视觉上不拥挤。

KPI卡片不要只写一个数字，尽量加上环比或同比信息，比如“平均薪资20.5K，较上月增长3%”。这个细节会让大屏的“分析感”强很多，而不是简单的数据罗列。

7.2 Flask后端接口设计示例

后端接口我采用了RESTful风格，返回JSON给前端渲染。典型接口如下：

from flask import Flask, jsonify import pandas as pd app = Flask(__name__) @app.route("/api/salary/city") def city_salary(): df = pd.read_sql("SELECT city, salary_min, salary_max FROM job_info", engine) df["salary_mid"] = (df["salary_min"] + df["salary_max"]) / 2 result = df.groupby("city")["salary_mid"].median().sort_values(ascending=False) return jsonify({"cities": result.index.tolist(), "salaries": result.values.tolist()}) if __name__ == "__main__": app.run(debug=True, port=5000)

一个小的性能优化建议：如果图表不需要实时刷新，可以把统计结果进行缓存，比如将聚合结果存成JSON文件，前端直接读取；或者用Flask的cached装饰器缓存响应。这样系统演示时页面加载会明显更快，也能避免重复查询数据库。

7.3 前后端联调的常见问题

联调阶段最容易出问题的不是后端逻辑，而是跨域和字段名不匹配。

跨域问题：前端页面如果在不同端口打开，后端需要配置CORS。

from flask_cors import CORS CORS(app)

字段名不匹配：后端返回的字段名和前端data里定义的字段名必须严格一致，否则图表展示为空白。建议在联调前，先手动在浏览器地址栏访问接口URL，确认返回的JSON结构是预期格式，再写前端代码。

还有一个细节：日期格式。数据库里的datetime类型经过JSON序列化会变成"Fri, 10 May 2025 08:00:00 GMT"这种格式，前端渲染时要用dayjs或者new Date()做格式化，提前处理能避免线下测试时好多“时间显示为NaN”的问题。

8. 常见问题与排查技巧实录

8.1 爬虫被反爬策略拦截时的对策

爬虫最大的坑就是爬着爬着突然没数据了。我遇到的典型情况是：

• 请求频率太高，触发验证码。
• 同一个Session长时间不变，被识别为机器人。
• 目标网站改版，CSS选择器失效。

对策分别是：拉大请求间隔（随机5-8秒）；每次请求新建Session并随机UA；写爬虫时不要把选择器写死在代码里，而是提取成配置字典，改版时只改配置。

另外，建议在采集时记录日志。哪怕只是简单地把每次请求的URL、状态码、时间戳写入文件，都能在排查问题时省下大量时间。

8.2 数据处理常见的坑：薪资字段解析出错

薪资解析翻车主要发生在两种场景：一种是“15-20K·14薪”这种带年终薪制的，另一种是“3-5万”这种跨单位的。如果正则没写全，很容易解析出None。

我的建议是：写一个单独的parse_salary函数，在里面放几条测试用例，确保每个用例的输出符合预期后再集成到主流程。

assert parse_salary("15-20K·14薪") == (15, 20) assert parse_salary("3-5万") == (30, 50) assert parse_salary("薪资面议") == (None, None)

用断言写单元测试，能让你在改代码的时候及时发现回归问题。

8.3 可视化图表不显示时的排查思路

图表不显示，90%的情况是数据没读出来或者格式不对。我的排查顺序固定为：

1. 打开浏览器开发者工具，看Network面板里接口是否正常返回。
2. 检查接口返回的JSON，确认数据是否有值。
3. 检查前端ECharts配置里的xAxis.data和series.data是否和返回字段对应。
4. 如果以上都没问题，看控制台是否有JS报错。

这个顺序按照“后端—数据—前端”的链路排查，基本十几分钟就能定位问题。千万别一上来就翻前端代码，容易越翻越乱。

8.4 答辩高频问题与回答思路

答辩环节评委的提问通常集中在以下几个方面：

• “数据是怎么来的？”：说明爬虫的采集对象、频率控制和合规性处理。
• “数据质量如何保证？”：讲清洗流程、去重规则、异常值处理。
• “为什么选这些分析维度？”：强调每个维度都对应一个业务问题。
• “系统还有什么可以改进的地方？”：可以说引入机器学习做薪资预测、部署到云服务器、增加实时爬取能力。

回答时记住一个原则：别只讲“做了什么”，要多讲“为什么这么做”和“遇到了什么困难、怎么解决的”。评委最想看到的不是完美的系统，而是你解决问题的过程。

9. 论文写作与项目包装建议

9.1 论文结构怎么安排

标准的毕设论文框架可以这样写：

• 第一章 绪论：选题背景、国内外研究现状、本文主要工作。
• 第二章 相关技术介绍：Python、爬虫技术、Flask框架、ECharts。
• 第三章 系统需求分析：功能性需求、非功能性需求、可行性分析。
• 第四章 系统设计：总体架构、功能模块设计、数据库设计。
• 第五章 系统实现：每个模块的核心代码和实现效果截图。
• 第六章 系统测试：功能测试、性能测试，给出测试用例表。
• 第七章 总结与展望：总结工作内容，指出不足和后续方向。

每一章不需要大而全，但要保证逻辑链条完整。特别是第二章切忌变成“百科词条”，比如不要用上千字介绍“Python是一种面向对象的解释型语言”这种废话，而是应该写“本系统选择Python是因为……”，要结合项目说选型原因。

9.2 项目演示Demo的准备技巧

答辩现场演示系统时，有几个容易翻车的细节：

• 提前把数据库服务启动好，不要到现场再敲命令。
• 演示用的数据集提前固定好，保证有足够的数据量让图表“饱满”。
• 如果网络环境不稳定，爬虫模块可以不在现场演示，只展示已经采集好的数据成果。
• 准备一份本地的离线可视化页面作为备用方案，即使数据库挂了也能展示截图。

这个备用策略我吃过亏，有次答辩现场MySQL莫名连不上，好在提前准备过一份存好的HTML快照，照样把分析结果讲清楚了。

9.3 项目后续扩展的三个方向

毕设做完以后，如果你想继续优化或者在简历上写得更好看，可以在以下三个方向做扩展：

第一个方向是加入预测算法。用线性回归或随机森林，根据城市、学历、经验、技能预测薪资区间，把系统从事后统计升级为事前预估，技术含量会明显提升。

第二个方向是数据时效性优化。当前系统是离线采集，可以改造成定时任务（如APScheduler）自动采集，配上一套增量更新机制，让数据每天自动更新。

第三个方向是部署上线。用Docker封装整个项目，部署到云服务器，再配一个简单的域名，让系统可以从外网访问。这在求职时可以当作品集直接展示，胜过口头描述。

写在最后的几点心里话

这个项目我从头到尾做下来，最深的一个感受是：毕设选题真的不用追求“高大上”，能把一个清晰、完整的链路踏踏实实跑通，比堆砌一堆高级名词有用得多。程序员薪资分析这个题目看起来普通，但它的巧妙之处在于——你只要愿意往深处做，它就能往深处延伸，数据采集、清洗建模、可视化交互、甚至机器学习预测，每一层都有东西可挖。

希望这篇分享能给你一些参考。记住，拿到代码和文档只是开始，真正把每一行逻辑理解透、能讲明白，这才是你在毕设里获得的最大收获。