Django电动汽车数据分析与可视化大屏实战指南

拿到这套“02721+django中国电动汽车市场分析与可视化”全套资料的时候，我的第一反应其实是半信半疑的。市面上叫“毕业设计资料包”的东西太多了，打包了一堆代码和PPT，真正能跑通、能讲清逻辑、能让演示现场不翻车的少。但这个项目标题里有几个词很关键：学得会、做得出、能展示。它不是在讲单点技术，而是把“数据采集 → 入库 → 后端接口 → 可视化大屏 → 部署展示”一整条链路串起来了。技术栈正好是我平时用得最多的Django和前端图表库，所以我花了一整周时间把整套内容拆开、复现、改造了一遍。这篇文章就是我基于这套资料包的完整复盘，包含项目结构拆解、数据建模过程、Django后端接口设计、可视化大屏实现，以及部署环节我踩过的坑。不吹不黑，这套东西做毕业设计、做个人作品集、甚至是小团队做内部数据看板，都能直接用。

先说结论：如果你是一个已经学完Python基础、刚接触Django不久的人，这套资料能帮你少走至少两周弯路。它的设计思路不是让你背代码，而是给一套你完全可以按自己数据改写的骨架。文章后面我会把每个环节展开讲，并给出我在实际操作中修正过的一些细节。

1. 项目定位与学习路径设计

1.1 拿到这套资料先看什么

资料刚解压出来，文件不少，有代码目录、SQL脚本、说明文档、答辩PPT模板。我的建议是不要急着去点运行，先把目录结构理一遍。这套资料本身就是一个完整项目的复刻模板，所有文件都是为了让你在最短时间内理解“一个数据展示类Web项目是怎么诞生的”。

核心代码目录大体分成几个部分：Django项目配置、accounts用户模块（这部分我猜是为了满足登录注册需求）、核心业务App、静态资源目录、以及模板目录。SQL脚本是已经导好的MySQL备份文件，里面包含中国电动汽车销量相关的表结构。前端部分有ECharts或类似图表库的引用，还有大屏页面的HTML模板。

这个结构其实是很多企业里真实数据项目的缩小版。你在学校可能做过纯静态页面展示，或者单独写过几个Python脚本做数据分析图表，但把它们串成一个能看、能点、能交互的网站，才是这套资料真正的价值所在。所以第一步，先搞清楚每一层文件夹在整条链路里的位置，后面跟着做就会顺很多。

1.2 项目模块拆解：从数据到展示的四层结构

不管项目外在形式怎么变，数据展示类项目跑不出这个四层链路：数据层、服务层、展示层、部署层。数据层负责把Excel、CSV或者爬下来的数据清洗好，写入MySQL这类关系型数据库；服务层用Django把数据通过ORM查询出来，组装成JSON接口返回给前端；展示层用图表库把JSON渲染成地图、柱状图、饼图、折线图等可视化内容；最后部署层把整个网站发布到服务器上，让别人能通过浏览器访问。

这套电动汽车市场分析项目，就是这四层结构的标准实践。数据层用的是中国电动汽车销量历史数据，按省份、车型、品牌、价格区间等维度做了统计；服务层用Django提供若干接口，比如销量趋势接口、省份分布接口、品牌排行接口；展示层则是典型的数据可视化大屏风格，地图加图表铺满一个页面，还做了大屏适配。部署层提供了Web服务器配置说明，当然，你本地习惯用开发服务器跑演示也完全没问题。

看懂这四层，你就等于看懂了市面上80%的数据可视化大屏项目。所以与其说这是一套毕业设计资料，不如说是一套“数据项目通用模板”，这也是我推荐你先学框架而不是死记代码的原因。

1.3 学得会、做得出、能展示三者怎么兼顾

这个标题里最有意思的是最后三个词：学得会，指的是内容要有梯度，代码要能看得懂；做得出，指的是你拿到之后改一改数据、换个业务主题，能做成自己的项目；能展示，指的是演示现场不能崩，视觉效果要撑得住场子。这三个词其实对应用人单位最看重的三种能力：理解能力、二次开发能力和交付能力。

我在复现过程中刻意做了一些“破坏性测试”。比如把数据库里的表名改掉，把字段注释拿掉，看看能不能根据前后端代码反推出数据结构；再比如把图表库版本换掉，看看渲染逻辑会不会崩。这套资料的容错性比我想象中好，核心逻辑都写在Django视图和前端脚本里，没有依赖某个特定的数据库名、表名写死。换句话说，只要你把MySQL连接配置改对，把数据导入成功，整套系统就能跑，这已经是资料包里很良心的水准。

2. 数据集处理与MySQL建模实战

2.1 原始数据长什么样，怎么清洗入库

资料包里的SQL脚本是已经处理好的数据，但你不能只会导入，得知道这些数据是从哪来的、怎么变成表结构的。中国电动汽车市场相关的数据源其实很多，常见的有乘联会月度销量数据、地方上牌的车辆登记信息、充电联盟的充电桩数据等。整理成表格后，字段通常包括：统计月份、省份名称、车辆类型（纯电动/插电混动）、品牌名称、车型名称、销量数值、价格区间等。

导入SQL脚本只是第一步，更关键的是理解表之间的关系。销量事实表通常关联着时间维度表、地区维度表、车型维度表。这样做的好处是，当你做按省份筛选、按时间趋势下钻、按价格段聚合的时候，SQL写起来很自然，Django的ORM查询也更好组织。

如果你拿到的不是SQL而是CSV，清洗的流程一般是：先用Pandas读取CSV，做缺失值处理，把空销量填成0，把字符串里的“万辆”这类单位去掉，转换成数字类型；然后把省份名统一成标准名称，比如“北京”和“北京市”要合并成同一个；最后按照设计好的表结构逐行写入MySQL。资料包里没有把CSV附上，只给了SQL备份，但我还是建议你自己找一份类似的公开数据走一遍清洗流程，这对理解数据建模非常有帮助。

2.2 核心表结构设计与ORM模型对应

用Django操作MySQL，先要定义Model类，每个类对应一张数据库表。我在资料包里看到的核心表大致包括：CarModel（车型信息）、SaleRecord（销量记录）、ProvinceInfo（省份信息）。这三张表搭出了一个简单的星型模型。CarModel存品牌、车型、能源类型、价格区间、续航等静态属性；ProvinceInfo存省份名称、区域归属等信息；SaleRecord存某年某月某省份下某车型卖了多少辆。

定义好Model之后，用makemigrations和migrate命令同步到数据库。这里要特别注意，资料包给的SQL脚本是已经建好表的，如果你直接用脚本导入，再执行migrate，有可能会报“表已存在”的冲突。我实际操作时是先手动删除相关表，再重新migrate，用Django自己生成的表结构来跑，这样代码和库是严格匹配的，后面查询逻辑不会踩字段不存在的雷。

ORM查询是这套项目最实用的部分。比如你想算出所有省份的累计销量，只要一行代码：SaleRecord.objects.values('province').annotate(total=Sum('sales'))。这个写法等价于SQL里的“SELECT province, SUM(sales) FROM sale_record GROUP BY province”，但Django帮你处理了防SQL注入和转义，开发效率高很多。资料里的接口基本都是这种aggregate加annotate的组合查询，学会了这一套，你自己做后台统计类页面完全够用。

2.3 数据库连接配置与mysqlclient安装避坑

运行这套项目之前，必须先装好数据库驱动。Django连接MySQL，默认推荐的是mysqlclient。这个包在Windows上经常会让你卡一下，因为它是带C扩展的，需要编译环境。我自己装的时候遇到过“MySQLdb 找不到”和“error: Microsoft Visual C++ 14.0 is required”这类报错。

避坑方法很简单：优先使用Python3.8到3.10的版本，安装前先升级pip，再用 pip install mysqlclient 试试。如果提示需要编译，直接去对应Python版本的第三方包网站下载已经编译好的whl文件，安装whl后就不会报错了。装好之后，在Django的settings.py里配置数据库连接，填上数据库名、用户名、密码、主机和端口，然后把时区设置为Asia/Shanghai。这里有个细节，Django默认的USE_TZ是True，时间字段存取会和北京时间的存储结果有偏差，做销量统计时涉及月份分组，统一改成False更省心。

有一个更容易被忽略的点：字符集。创建数据库的时候要指定utf8mb4，建表时也保持这个字符集，否则中文品牌名和省份名在查询关系里可能出现乱码。资料包的SQL脚本里已经做了处理，但你自己新建库时容易漏这一步。实测下来用utf8mb4后，ECharts地图上的中文标签显示完全没有问题。

3. Django后端开发与接口设计思路

3.1 创建项目与App的组织方式

资料包里用到的Django组织方式是：整个项目根目录下，一个项目配置目录加一个核心业务App。如果你自己从零开始照着资料做，先执行 django-admin startproject ev_project，再执行 python manage.py startapp analysis 就能得到类似结构。

为什么要把业务逻辑单独放一个App而不是全部写在项目配置里？因为Django的设计哲学是“每个App负责一个可复用的业务模块”。在这个项目里，用户认证、销量统计、图表数据接口、后台管理，这些功能在未来是可能被拆开复用的。单独放一个App，你改销量查询逻辑的时候不会影响用户登录，代码也更好维护。

App创建好之后，记得去settings.py的INSTALLED_APPS里注册。很多新手绕不开的坑是：创建了App但忘记注册，结果页面模板、静态文件、迁移全都找不到，报了各种奇怪的错误。资料包里这类基础的配置已经写好了，但你要理解它为什么这么配，才能在自己新建模块时不出错。

3.2 核心页面路由与视图函数

一套可视化项目，页面分两类：一类是用户直接访问的HTML页面，比如首页、登录页、数据大屏页；另一类是给前端Ajax请求的JSON接口，类似 /api/sales/trend 这种地址。Django里用urls.py做路由分发，视图函数决定用户请求到来之后返回什么内容。

资料包中首页视图比较简单，直接用render返回一个模板；数据大屏页面也类似，但页面里有大量图表数据要动态加载，所以大屏页面本身只返回框架HTML，图表数据全部由接口异步返回。这种“首屏HTML加后续Ajax填数据”的模式，是前后端交互的主流做法。它最大的优点是，页面打开速度快，图表加载不会阻塞页面结构渲染，数据更新时前端不用刷新整个页面，体验好很多。

写视图函数时有一个习惯值得学习：把查询数据库的逻辑尽量写在独立函数里，或者直接写在ModelManager里，视图函数保持短小。为什么？因为视图函数一旦变长，你很难测试，出现Bug也不好排。拿销量趋势接口举例，你可以把查询语句封装成一个函数get_sales_trend(year=None, province=None)，视图里只做参数解析和JSON返回，这样代码结构清晰，后面要加缓存也很方便。

3.3 JSON接口怎么设计最不容易返工

接口设计是这个项目的灵魂。大屏上每一个图表都背后对应一个接口，接口返回的JSON结构直接决定了前端图表好不好渲染。我见过太多项目，后端返回一个嵌套很深的字典，前端取数据要绕好几层，改起来痛不欲生。这套资料里的接口结构比较规范：统一返回一个包含code、message、data的字典，data字段里放图表需要的核心数据，比如名称列表nameList和数值列表valueList。

以省份销量Top10的接口为例，返回的data形如：{"nameList": ["广东", "浙江", "江苏", ...], "valueList": [12345, 9876, ...]}。前端拿到后，直接把nameList赋给ECharts的xAxis.data，把valueList赋给series.data，一个柱状图就完成了。这种扁平结构在数据量不大时是最实用的，避免在前端做复杂的数据变换。

做接口时还要处理好两个细节：参数校验和异常捕获。前端传个非法年份过来，后端不应该报500错误，而是返回code为400的JSON，并附带错误提示。数据为空时同样要做拦截，返回一个空列表而不是None，免得前端在渲染图表时报错。资料包里的接口在异常处理上并不算特别完善，我按自己的习惯加了一个统一的装饰器或者中间件，专门捕获视图抛出的异常并转换成标准JSON，代码鲁棒性提升很多。

3.4 文件导出与StreamingHttpResponse下载功能

资料包里有一个多媒体资源管理实战包的功能是“前端浏览与下载文件”，在Django里实现下载有三种常见方式：HttpResponse直接返回文件内容、FileResponse分块传输、StreamingHttpResponse做流式响应。如果文件不大，HttpResponse就够了；如果是几十兆以上的Excel或CSV导出，一定要用StreamingHttpResponse，它能边生成边传，不会把整个文件都读进内存。

设置响应类型和下载文件名，需要用Content-Disposition响应头，写法是attachment; filename="report.csv"。注意文件名如果是中文，需要做URL编码，否则浏览器可能下载下来是乱码。Django的StreamingHttpResponse在JsonResponse的基础上再包一层生成器，就能实现逐行写CSV。这个方法在项目答辩演示时特别有用：你在页面上点一下“导出数据”，浏览器立即开始下载一份带当前筛选条件的表格，评委的观感会很好。

我在资料包的基础上给销量明细模块加了这个导出功能，把Django的QuerySet迭代器传给CSV生成器，几万行数据秒级导出，内存占用很小。具体的生成器写法很简单，就是一个函数，内部用csv.writer把每行数据写入StringIO，然后yield出来。这个技巧你们做管理后台时早晚会用上。

4. 可视化大屏与图表实现详解

4.1 大屏页面布局逻辑

数据可视化大屏之所以叫“大屏”，是因为它的核心场景是投到一块大显示器或者LED拼接屏上，观众离得远，所以信息要够大、够直观、对比要够强烈。资料包里的大屏页面，整体是深色背景，卡片式分区块，标题居中，地图放在中间偏左的位置，右侧和下方是各种统计数据。

布局上常用的是Grid加Flex弹性布局。因为大屏分辨率不可以写死，需要在不同尺寸下自适应。资料包里用的是典型的rem加vw方案：根节点字体大小按屏幕宽度动态计算，图表尺寸按容器百分比填充。我更推荐结合媒体查询和scale缩放来做，把一张设计稿按1920×1080设置好，再用CSS transform的scale属性整体缩放，这样在笔记本电脑上演示时，大屏也不会出现折叠错位的问题。

我实测过，直接用固定像素宽度在1080P的屏幕上刚好铺满，但在普通笔记本屏幕上看横向滚动条就会出现，非常影响观感。按我上述方案改造之后，无论是投影仪还是笔记本，都能保证图表完整显示。资料包里虽然给了适配方案，但我在真实演示时发现transform方式最省心，墙面上的实际展示效果也最好。

4.2 ECharts地图、柱状图、饼图组合实战

整个大屏最醒目的部分是China地图，用来展示各省的电动汽车销量分布。ECharts的地图需要注册GeoJSON或使用内置地图数据。新版ECharts不能像老版本那样直接使用china地图，需要单独引入地图数据文件或者从第三方获取GeoJSON。资料包里应该已经处理好了地图数据，如果你自己二次开发，要去下载一个中国省级行政区域的GeoJSON文件，注册到ECharts里，再把各省销量值映射到map的series数据里，设置visualMap连续型图例，颜色越深代表销量越高。

地图旁边，一般搭配品牌销量Top10的柱状图和能源类型占比的环形饼图。柱状图注意排序，让最高的在顶部，形成清晰的长短对比，视觉冲击力才会出来。饼图注意把数据比例较小的分类合入“其他”项，避免标签拥挤。大屏页面上的数字滚动、图表自动轮播更新，都可以用ECharts的setInterval来实现。我做完之后又把柱状图的柱子颜色改成渐变，标题加了悬浮阴影，观感立刻提升了一个档次。

组合图表复用同一个数据的思路也要掌握。中国地图和省份榜单加载的是同一个销量接口，你只需要在接口里把省份字段和销量字段拆出来，一份数据同时喂给两个图表。既能保证数据一致性，又省了一次请求，这也是大屏项目前端性能优化的常用手段。

4.3 前后端分离模式下的接口联调技巧

如果资料包的版本是Django直接用模板渲染，那它属于前后端不分离的传统模式；但网络上的热词里有大量“django前后端分离”，说明很多人已经习惯用Vue或React加Django的组合。这套资料的大屏页面，即使在模板模式下，也可以改写成一个独立的静态HTML，通过fetch或者axios请求接口，再把返回的JSON渲染到ECharts上，本质上就是前后端分离。

把前端静态HTML放在Django的static目录或单独跑一个前端开发服务器，两者都能工作。区别在于跨域配置：如果前端页面和后端接口不是同一个端口，就要在Django里使用django-cors-headers这一类的中间件，允许跨域请求。我在联调时踩过这个坑，前端控制台一直报CORS错误，改成允许所有来源后就好了。但在生产环境，建议精确指定允许的来源，不然容易有安全风险。

前后端分离还有一个优势：开发效率高。后端改一套接口，前端可以多个页面复用；前端调整布局和配色，也不需要重启Django服务。对于做毕业设计，你要演示的时候，直接把后端跑起来，前端静态页面用VS Code的Live Server或者直接打进Django里，演示环境可以随时切换。

4.4 大屏适配与性能优化

大屏性能优化通常被忽视，但演示现场最怕的就是卡顿。ECharts的图表数量如果超过四五个，每次刷新数据都重新setOption，可能会有肉眼可见的停顿。优化的方法是：只有数据源变化时才调用setOption，静态数据不要重复加载；图表在页面切换或隐藏时销毁实例；加载数据时显示loading动画，让用户明白系统还在工作。

还有一个经验：把不必要的动画关掉。大屏页面追求的是炫酷，但过度动画在低性能投影仪上会掉帧。我一般保留初始动画，但把过渡动画的时长调到500毫秒以内，这样既顺畅又不卡。JSON数据压缩也很重要，如果接口返回的数据里有大量没用的字段，前端拿到的数据包过大，也会拖慢渲染。可以用Django的values()只查询需要输出的字段，从源头上减负。

5. Django Admin后台与界面美化经验

5.1 登录认证与管理员设置

Django自带Admin后台，是个开箱即用的管理界面，它有用户认证、权限分配、数据增删改查，非常适合做数据管理。用 python manage.py createsuperuser 创建管理员账号，然后访问/admin就能登录后台。资料包里除了用户模块，还预设了部分导航菜单，方便评委快速看到“这个系统是有后台管理的”。

如果你觉得默认的Admin界面太朴素，想把它做得更有现代化气息，网络热词里提到的“django admin界面美化”正好对应这个需求。界面美化的思路分两种：一是引入第三方主题包，比如django-simpleui，它提供了一套现成的中后台界面风格，安装后在settings.py里注册即可；二是自己写CSS覆盖，把导航栏颜色、按钮样式、表格条纹改成和自己大屏页面一致的风格。

我在资料项目里用的是第二种，因为要跟大屏的深色主题保持统一。具体做法是在项目static目录下新建一个admin_extra.css，然后在Admin的base_site.html里把它引入。这样登录后整个后台的视觉风格都变了，评委在演示“从后台管理数据到前台图表实时更新”的模块时，体验会连贯很多。

5.2 后台列表页配置技巧

Admin后台配置的核心在于admin.py。注册模型之后，通过list_display指定列表页显示的字段，比如车型名称、品牌、能源类型、价格区间、续航里程。通过list_filter增加筛选导航，比如按能源类型筛选、按价格区间筛选。通过search_fields添加搜索框，让别人能直接输入品牌名来找记录。这些配置加起来不到十行代码，但后台管理系统的可用性直接翻倍。

如果想在后台看到销售数据汇总，可以把销量统计的逻辑放到Admin里，方法是为Model添加一个方法，返回统计值，并设置admin_order_field。不过要注意，统计方法会执行SQL查询，如果数据量太大，列表页可能会变慢。我的做法是只对Top10或者筛选后的QuerySet做统计，避免全表扫描。

还有一个实用配置是related_lookup_fields和autocomplete_fields。如果销量记录表要关联车型表，后台填写销量单时不想从一堆下拉列表里找车型，用autocomplete_fields可以在输入框里直接搜索，非常提升使用体验。这个配置在纯靠外键录入数据的业务场景里特别香。

5.3 Redis可视化与缓存加速

热词里多次出现“redis可视化工具”“redis客户端可视化工具”，说明这已经是很多项目的标配。为什么纯展示项目要用Redis？因为大屏页面的接口数据其实变动频率不高，每次都去MySQL里做复杂的聚合查询，纯属浪费数据库资源。把聚合结果缓存到Redis里，设置过期时间比如300秒，第一次请求时查库并把结果写入Redis，之后请求直接读缓存，响应速度能从几百毫秒降到几毫秒。

Django中接入Redis，用django-redis这个库最省事。在settings.py里配置好CACHES，然后在视图里用cache.get和cache.set操作即可。调试时最常见的坑是Redis服务没启动，导致接口报ConnectionError。我个人习惯是在本机装Redis，再搭配一个RedisDesktopManager之类的可视化客户端，数据到底缓存了没有、key长什么样一目了然。

资料包项目里，我是这样做的：给销量趋势接口的QuerySet结果做了15分钟级别的缓存，因为销量数据不可能每秒钟都在变；地图数据做了30分钟级别的缓存。大屏刷新数据的同时，后端基本不会产生新的数据库压力，这个模式放到真实生产环境也能扛得住一定流量。

6. 部署上线与常见问题排查速查

6.1 本地调试环境跑通全流程

不管是自己学习还是答辩演示，先把项目在本地完全跑通是最重要的。启动顺序一般是：第一步启动MySQL，导入数据或用migrate建表；第二步启动Redis（如果你用了缓存）；第三步在项目根目录下执行 python manage.py runserver，浏览器访问0.0.0.0:8000，就能看到首页。

这一步经常遇到ModuleNotFoundError找不到某个包。解决办法是建立一个虚拟环境，在requirements.txt里把依赖全部装好。用虚拟环境是最佳实践，Django项目依赖多，直接装到系统Python里容易和别的项目冲突。我见过很多人在这一步浪费了大量时间，其实只要耐心看完整的报错信息，再把对应包装上，问题就能解决。

跑通之后，最好做一次功能回归测试：注册新用户、登录、访问大屏、切换图表参数、下载导出文件、进入后台修改数据，每个环节都操作一遍。资料包里项目的路由已经配好了，但你改过代码之后必须重新回归，防止改一个字段名导致首页直接500。

6.2 上线部署：Nginx加Gunicorn配置心得

本地runserver只能用于开发，真正上线或者给别人演示，要用Gunicorn或uWSGI启动Django服务，再用Nginx做反向代理。Gunicorn的命令很简单：gunicorn ev_project.wsgi:application -w 4 -b 0.0.0.0:8000，-w指定工作进程数，一般设为CPU核心数的两倍左右。

Nginx负责处理静态文件和转发动态请求。Django项目里所有静态文件需要先执行 python manage.py collectstatic，把散落在各App、各目录的静态资源收集到STATIC_ROOT指定的目录里，Nginx的配置片段大致是：location /static/ 指向STATIC_ROOT目录；location / 则用proxy_pass转发到Gunicorn服务的端口。

如果你对Nginx配置不熟，热词里提到的“nginx可视化配置工具”可以降低门槛，比如用一些开源的Nginx Web管理面板，在页面上填写域名、端口、代理地址，它会自动生成配置文件并且reload Nginx。省去了手写大量location块的麻烦，也减少了语法错误的风险。

6.3 部署安全要点与服务器防火墙

上线之后不能只图能访问，还要考虑基本安全。首先，Django的settings.py里 DEBUG 必须设为False，否则如果项目代码报错，浏览器上会直接展示详细的堆栈信息，源码路径完全暴露，非常危险；ALLOWED_HOSTS要填上你服务器的IP或域名，否则Django会拒绝请求。

其次，MySQL和Redis不能被公网随意访问。我见过有人把Redis的6379端口暴露到公网，结果被扫描工具当肉鸡，这个教训希望大家引以为戒。解决办法是设置防火墙只放行80/443端口，数据库和应用内部通信走内网IP或回环地址。Gunicorn服务本身也只监听127.0.0.1，外面来的请求一律通过Nginx转发。

最后，Django的SECRET_KEY不能在进Git时一并提交。这个密钥泄露会导致签名和加密功能被绕开。平时的做法是把SECRET_KEY这类敏感信息放到环境变量或本地.env文件中，在settings.py里用os.environ读取，这样即使代码上传到公开仓库，密钥也不会泄露。

6.4 常见报错与解决方案速查表

我在复现过程中把遇到的高频报错整理成了一个速查表，每个问题后面是我实测有效的处理方式。这张表直接贴给你们：

这张表不能解决所有问题，但覆盖了90%的新手坑。遇到报错时先看最后一行错误信息，网上的资料五花八门，你自己复现一下、稳住心态，绝大多数都能解决。

6.5 其他人踩坑点汇总

报错解决后，还有几类不容易发现但实际演示时会暴露的问题。第一个是浏览器缓存。你更新了Django模板或静态文件，但浏览器可能还在用旧的JS和CSS，导致页面看起来“没更新”。解决方法是硬刷新（Ctrl+F5），或在引用静态文件时加一个版本号参数，比如style.css?v=20250101。

第二个是端口冲突。80端口经常被本机已经安装的IIS、Apache或者其他开发环境占用。你可以用 netstat -ano | findstr :80 查看是谁占用了端口，然后关掉它，或者让Nginx换成其他端口。

第三个是文件导出功能，如果用HttpResponse直接返回中文文件名，大多数浏览器会正常，但个别版本会出现乱码。用StreamingHttpResponse时，推荐把文件名用RFC 5987标准编码，格式是filename*=UTF-8''%E4%B8%AD%E6%96%87.xlsx，这样所有浏览器都能正确解析。

这套资料给我的整体感觉，就是它把所有知识点都串成了一条完整的产品线。你拿到手之后，先按步骤把环境配好、把项目跑起来，然后逐步去改数据源、改图表配置、改后台模块，慢慢就会形成自己的理解。改到最后你会发现，毕业设计只不过是一个起点，你掌握的是“如何把一个数据业务做成一个可展示、可部署、可交付的系统”的能力，这个能力在任何行业都用得上。