企业官网建设流程全解析

我做了几个旅游类的数据可视化项目之后，发现很多团队的实际需求其实是类似的：数据量不算海量，用不上大数据平台；但业务方又不想在Excel里看一堆数字，想要一张能“讲故事”的动态大屏。这篇文章就从一个真实可落地的项目出发，拆解如何用 Django 做后端数据服务，配 ECharts 做前端可视化，在两周内搭出一套旅游数据分析可视化系统。内容包含数据库表设计、ORM 聚合查询、API 接口封装、大屏图表实现，以及部署时容易踩的坑，适合有一定 Python 基础、想做完整 Django 实战项目的开发者参考。

1. 项目思路与整体架构设计

1.1 这个系统到底解决什么问题

旅游行业的数据有个特点：维度多、杂、散。有景区维度的客流和门票收入，有时间维度的淡旺季波动，有客源维度的来源地分布，还有游客满意度、停留时长这些软性指标。地方政府文旅局、景区运营公司、旅行社这三类角色，关心的数据侧重点各不相同，但如果只拿原始数据表格出来，沟通成本很高。

这套系统的定位很明确：把旅游数据从 Excel 表格里解放出来，做成一个“一屏观全局”的可视化分析平台。它解决的不是"能不能算出来"的问题，而是"能不能一眼看懂"的问题。我给它规划了四个核心能力：

• 景区热度实时排行：当日/当月客流前10名景区，用横向柱状图展示。
• 游客来源地分析：按省份统计游客占比，用中国地图或饼图呈现。
• 时间趋势分析：月度客流和收入趋势，用折线图反映淡旺季规律。
• 核心指标卡：总游客量、总收入、平均满意度、平均停留时长做头部摘要。

这些需求扔给任何一个BI工具（比如Power BI、帆软）都能做，为什么还要用 Django 自己搭？主要原因是：数据源可能要对接景区票务系统、OTA平台接口，数据处理逻辑复杂，而且后续可能要做预测模型、爬虫采集等定制功能，用 Django 可以保持业务逻辑和展示层全部在自己掌控范围内，改起来灵活，也方便二次开发。

1.2 技术选型：为什么要用这套组合

先说我最终选型，再讲理由：

Django 在这个项目里几乎是"标准答案"级别的选择。第一点，它内置了 Admin 后台，景区信息表、游客数据表可以直接通过后台增删改查，等于免费拿到了一个数据维护系统，省去写一堆表单页面的时间。第二点，它的 ORM 对聚合统计的支持足够强，按月份分组、按景区分组、多表关联统计这些需求，用annotate加values就能搞定，不用写裸 SQL。第三点，Django 的模板系统直接把 ECharts 页面渲染出来，不需要做前后端分离，省去了 CORS 跨域和 token 鉴权的繁琐工作。

ECharts 选得也没什么悬念。在国内做数据可视化，ECharts 的文档和社区成熟度是最高的，百度地图、中国地图这些组件开箱即用。而且它对移动端适配做得不错，大屏缩放到小屏幕上也不会太崩。相比之下，D3.js 学习成本高，Highcharts 商业授权要钱，Chart.js 的图表类型和交互深度不如 ECharts 丰富。

数据库我选了 MySQL 而非 SQLite，理由是这类系统后期大概率要对接多端数据源，SQLite 在并发写入上是短板，而且 MySQL 的分组、日期函数和 ECharts 需要的数据格式匹配度更好。

1.3 整体架构与数据流向

这套系统的架构非常简洁，核心就三层：

数据采集/导入 → Django ORM → 聚合查询API → ECharts渲染

数据采集层：初期用 Mock 数据生成脚本模拟一年的旅游数据（约5万条），后期可以替换为爬虫采集或第三方接口对接。数据经过清洗后写入 MySQL。

业务逻辑层：Django 通过 ORM 执行聚合查询，对景区、时间、客源等多个维度分组统计，将结果整理成JSON结构，按API形式抛出。

展示层：前端页面通过fetch或jQuery.ajax请求API，拿到 JSON 数据后传给 ECharts 的option配置，渲染出大屏图表。

这个架构的巧妙之处在于：后端只负责"吐数据"，不关心图表长什么样；前端只负责"画图"，不关心数据是怎么算出来的。解耦带来的好处是，哪天想换图表库，或者想挪到微信小程序展示，后端代码一行都不用改。

2. 环境准备与Django工程搭建

2.1 环境准备与依赖安装

创建项目前先把虚拟环境准备好。我用的是 Python 3.10，用venv创建独立环境，避免和系统Python环境互相污染。

python3 -m venv tourism_env source tourism_env/bin/activate pip install django==4.2.15 mysqlclient pillow redis

有两个细节可以留意一下。

第一，mysqlclient这个包在 macOS 或者 Linux 上安装前需要先装 MySQL 开发库，不然会编译报错。Ubuntu 上用sudo apt-get install default-libmysqlclient-dev能解决；Windows 上如果没有现成的编译环境，直接换成pymysql并在 Django 的__init__.py里加上pymysql.install_as_MySQLdb()更省事。

第二，Redis 缓存是可选的，但强烈建议加上。大屏页面的数据接口会被前端每10秒轮询一次，如果每次都实时查 MySQL，数据库压力不小。把聚合结果缓存到 Redis，10分钟内数据不重算，响应时间能从 200ms 降到 30ms 左右。

2.2 创建项目和app

依赖装好之后，创建工程和应用：

django-admin startproject tourism_analysis cd tourism_analysis python manage.py startapp analysis python manage.py startapp visualization

我习惯把项目拆成两个app：

• analysis：负责数据模型、数据清洗、聚合查询，这是项目的心脏。
• visualization：负责页面渲染、图表API接口、静态资源管理，这是项目的门面。

这种拆分在刚开始看起来有点"过度设计"，项目小的时候一个app也能搞定。但旅游数据分析系统后期大概率会加预测模块、报告导出模块，app模块化之后扩展边界非常清晰。我自己早期做Django新手项目时就吃过亏，所有views、models、utils堆在一个app里，三个月后再看根本不想维护。

配置settings.py时，需要把两个app加进INSTALLED_APPS，并配置数据库连接：

DATABASES = { 'default': { 'ENGINE': 'django.db.backends.mysql', 'NAME': 'tourism_db', 'USER': 'root', 'PASSWORD': 'your_password', 'HOST': '127.0.0.1', 'PORT': '3306', 'OPTIONS': {'charset': 'utf8mb4'}, } } # Redis缓存配置 CACHES = { "default": { "BACKEND": "django_redis.cache.RedisCache", "LOCATION": "redis://127.0.0.1:6379/1", "OPTIONS": {"CLIENT_CLASS": "django_redis.client.DefaultClient"}, } }

charset配置成utf8mb4是防止景区名称里出现生僻字或emoji符号时写入报错，这个坑我在之前一个项目里踩过，数据库表建好之后再来改字符集非常麻烦。

2.3 数据建模与迁移

数据模型是整个系统的地基。我设计了张业务表：景区信息表（ScenicSpot）和游客统计表（TouristFlow）。

ScenicSpot存景区的静态属性，比如名称、所在城市、景区等级、门票价格；TouristFlow存每天每个景区的动态统计数据，比如游客数量、收入、客源省份、满意度评分。两张表通过外键关联。

from django.db import models class ScenicSpot(models.Model): name = models.CharField(max_length=100, verbose_name="景区名称") city = models.CharField(max_length=50, verbose_name="所在城市") level = models.CharField(max_length=10, verbose_name="景区等级", choices=[('5A', '5A级'), ('4A', '4A级'), ('3A', '3A级')]) ticket_price = models.DecimalField(max_digits=6, decimal_places=2, verbose_name="门票价格") class Meta: verbose_name = "景区信息" ordering = ['id'] class TouristFlow(models.Model): scenic_spot = models.ForeignKey(ScenicSpot, on_delete=models.CASCADE, verbose_name="景区") visit_date = models.DateField(verbose_name="统计日期") tourist_count = models.IntegerField(verbose_name="游客数量") revenue = models.DecimalField(max_digits=12, decimal_places=2, verbose_name="当日收入") province = models.CharField(max_length=50, verbose_name="客源省份") satisfaction = models.FloatField(verbose_name="满意度评分") stay_hours = models.FloatField(verbose_name="平均停留时长") class Meta: verbose_name = "游客统计" ordering = ['-visit_date'] indexes = [ models.Index(fields=['visit_date', 'province']), ]

建表之后执行迁移：

python manage.py makemigrations python manage.py migrate

这里特别说明一下为什么要设置联合索引。TouristFlow这张表一旦接入真实数据，每天都要按日期和省份过滤，是全表扫描还是走索引，性能差距可以到几十倍。对visit_date和province建联合索引，WHERE visit_date BETWEEN ... AND ... AND province='北京'这类查询的效率会高很多。

3. 数据分析与API接口实现

3.1 分析维度与业务指标设计

做可视化之前一定要先把业务指标梳理清楚，否则图表画得再好看也只是花架子。我从业务方的角度把分析拆成4个维度：

• 时间维度：天、月、年三个粒度，重点看季节性波动和同比环比。
• 景区维度：单个景区排行、同城景区对比。
• 客源维度：跨省游客占比、省内省外比例。
• 质量维度：满意度、停留时长、人均消费。

围绕这四个维度，输出六张核心图表，没做更多，因为大屏不是报表，图多了反而抓不住重点：

1. 顶部指标卡：总游客量、总收入、满意度均值、人均消费。
2. 月度客流趋势折线图（双线：客流 + 收入）。
3. 景区热度排行横向柱状图。
4. 客源省份占比饼图。
5. 城市客流对比柱状图。
6. 满意度雷达图。

3.2 数据生成与预处理

真实项目里数据来自景区票务系统的导出文件，但开发阶段我写了一个generate_data.py脚本来生成模拟数据。这个脚本放在应用根目录下，用 Django 的shell命令跑：

# analysis/management/commands/generate_data.py import random from datetime import date, timedelta from django.core.management.base import BaseCommand from analysis.models import ScenicSpot, TouristFlow class Command(BaseCommand): help = '生成模拟旅游数据' def handle(self, *args, **options): spots = list(ScenicSpot.objects.all()) start_date = date(2023, 1, 1) end_date = date(2023, 12, 31) provinces = ['北京', '上海', '广东', '江苏', '浙江', '四川', '山东', '河南', '湖北', '陕西', '湖南', '福建'] for spot in spots: for i in range((end_date - start_date).days + 1): current_date = start_date + timedelta(days=i) # 旺季（5-8月，10月）客流更多 season_factor = 1.5 if current_date.month in [5, 6, 7, 8, 10] else 1.0 # 周末客流高于工作日 weekday_factor = 1.3 if current_date.weekday() >= 5 else 1.0 base_count = random.randint(800, 3000) tourist_count = int(base_count * season_factor * weekday_factor) revenue = tourist_count * float(spot.ticket_price) * random.uniform(0.6, 1.1) TouristFlow.objects.create( scenic_spot=spot, visit_date=current_date, tourist_count=tourist_count, revenue=round(revenue, 2), province=random.choice(provinces), satisfaction=random.uniform(3.8, 5.0), stay_hours=random.uniform(2.0, 6.0), )

注意这个脚本里包含了季节性因子和周末因子，这是做旅游分析时很重要的业务知识——如果不做这种规则处理，生成的数据就会是完全白噪声，画出来的图表没有任何规律可循，后面的聚合分析也就失去了意义。模拟数据也要模拟出真实的业务规律，这是很多人忽略的地方。

3.3 ORM聚合查询与接口代码实现

数据生成完之后，核心工作就是聚合查询。这里说两个关键点。

第一，不需要序列化器那一套。Django REST Framework 的ModelSerializer确实很香，但本项目API只做读取不做写入，直接构造字典返回JSON即可，更轻。

第二，聚合查询最常用的就是values+annotate组合。比如按月分组统计客流量：

from django.db.models.functions import TruncMonth from django.db.models import Sum, Avg, Count def monthly_trend(request): """月度客流与收入趋势""" cache_key = 'monthly_trend_data' cached = cache.get(cache_key) if cached: return JsonResponse(cached) result = (TouristFlow.objects .annotate(month=TruncMonth('visit_date')) .values('month') .annotate( total_tourists=Sum('tourist_count'), total_revenue=Sum('revenue'), avg_satisfaction=Avg('satisfaction') ) .order_by('month')) data = { 'months': [item['month'].strftime('%Y-%m') for item in result], 'tourists': [item['total_tourists'] for item in result], 'revenue': [float(item['total_revenue']) for item in result], 'satisfaction': [round(item['avg_satisfaction'], 2) for item in result] } cache.set(cache_key, data, timeout=600) return JsonResponse(data)

这里面的关键逻辑是annotate(month=TruncMonth('visit_date'))：TruncMonth函数将日期字段截断到月份精度，比如2023-05-20会被归一化成2023-05-01，然后再按归一化后的分组，得到的就是月度聚合数据。这在SQL层面相当于写成GROUP BY DATE_FORMAT(visit_date, '%Y-%m-01')。

景区热度排行又是另一种写法：

def spot_ranking(request): """景区客流排行TOP10""" result = (TouristFlow.objects .values('scenic_spot__name', 'scenic_spot__city') .annotate(total_tourists=Sum('tourist_count')) .order_by('-total_tourists')[:10]) data = { 'names': [item['scenic_spot__name'] for item in result], 'cities': [item['scenic_spot__city'] for item in result], 'values': [item['total_tourists'] for item in result] } return JsonResponse(data)

注意这里用的是scenic_spot__name这种跨表字段写法，Django ORM 会自动生成 JOIN 查询，不需要手动去关联表。但是有一点要想清楚：如果不加[:10]切片，前端一次性拿到全量数据，图表渲染没问题，但JSON体积会大，加载也会慢。TOP10这种硬需求，在SQL层面就limit掉，是最简单的优化手段。

3.4 URL路由与接口设计

接口定义时最好遵循一个规律：路径里让人一眼看懂"查的是什么"，参数里指定时间范围等条件。

from django.urls import path from visualization import views urlpatterns = [ path('api/dashboard/', views.dashboard_overview, name='dashboard_overview'), path('api/monthly-trend/', views.monthly_trend, name='monthly_trend'), path('api/spot-ranking/', views.spot_ranking, name='spot_ranking'), path('api/province-distribution/', views.province_distribution, name='province_distribution'), path('api/city-comparison/', views.city_comparison, name='city_comparison'), path('api/satisfaction-analysis/', views.satisfaction_analysis, name='satisfaction_analysis'), ]

然后让浏览器直接打开接口地址测试数据是否正常返回。这一步顺手做一下接口的可视化审查，比如总游客量有没有因为数据重复而翻倍、景区排行里有没有出现null名称等。

接口层面还有个问题值得注意：大屏系统的数据是定期轮询还是手动刷新。我推荐大屏页面用setInterval每30秒自动刷新，指标卡每10秒刷新。缓存设置在600秒，所以接口轮询的压力很小，能扛住一整天挂在大厅屏幕上。

4. 可视化大屏开发实战

4.1 页面布局与图表规划

先说大屏页面的视觉设计思路。旅游数据的受众（领导汇报、游客中心大屏）普遍有个习惯：看一眼就得能总结出结论。所以布局要遵循"总-分"模式，最重要的指标卡放最上面，中间放趋势和排行，两侧放分布和对比。

我采用的是经典的栅格布局：

┌─────────────────────────────────────────────┐ │ 指标卡1 │ 指标卡2 │ 指标卡3 │ 指标卡4 │ ├──────────────┬──────────────┬───────────────┤ │ 月度客流趋势 │ 景区热度排行 │ 客源分布饼图 │ ├──────────────┴──────────────┴───────────────┤ │ 城市对比柱状图 │ 满意度雷达图 │ 数据更新状态 │ └─────────────────────────────────────────────┘

表格里的这种布局就是大屏系统里最经典的dashboard结构，用Bootstrap栅格完全能实现：

<div class="container-fluid"> <div class="row"> <div class="col-md-3"><div class="card" id="card-total">...</div></div> <div class="col-md-3"><div class="card" id="card-revenue">...</div></div> ... </div> <div class="row"> <div class="col-md-6"><div id="chart-trend" class="chart-box"></div></div> <div class="col-md-3"><div id="chart-ranking" class="chart-box"></div></div> <div class="col-md-3"><div id="chart-province" class="chart-box"></div></div> </div> </div>

大屏背景颜色我用的深色系（#0f1224），图表透明背景，字体用白色。对比一下深色和浅色两种方案：深色大屏在展厅灯光下对比度更高，领导拍照也更好看；浅色主题在办公电脑上阅读更舒适。如果这套系统是内部办公用的后台分析系统，选浅色主题就好；挂在游客中心大屏上，建议用深色。

4.2 ECharts图表代码实现

ECharts 5 的用法可以总结成三步：init，传option配置，setOption。核心的难点全在option配置里。

比如月度趋势折线图，配置两个Y轴（左轴客流、右轴收入），因为客流和收入的量级不一样，共用一个Y轴会让其中一条线几乎贴底，看不出变化规律：

// 静态资源/js/dashboard.js $(document).ready(function () { var trendChart = echarts.init(document.getElementById('chart-trend')); $.getJSON('/api/monthly-trend/', function (data) { trendChart.setOption({ tooltip: { trigger: 'axis' }, legend: { data: ['游客量', '旅游收入'], textStyle: { color: '#fff' } }, grid: { left: '8%', right: '8%', bottom: '8%', containLabel: true }, xAxis: { type: 'category', data: data.months, axisLabel: { color: '#aaa' } }, yAxis: [ { type: 'value', name: '游客量（万人）', axisLabel: { formatter: function (value) { return (value / 10000).toFixed(0) + '万'; } } }, { type: 'value', name: '收入（万元）', axisLabel: { formatter: function (value) { return (value / 10000).toFixed(0) + '万'; } } } ], series: [ { name: '游客量', type: 'line', smooth: true, data: data.tourists, areaStyle: { opacity: 0.2 }, itemStyle: { color: '#4fc3f7' } }, { name: '旅游收入', type: 'line', smooth: true, yAxisIndex: 1, data: data.revenue, itemStyle: { color: '#ffb74d' } } ] }); }); });

用formatter函数把原始数值转换成"万"显示，会让图表标签干净很多。如果不加这个处理，旅游收入那儿会出现一大串零，大屏美观度直接下降一个档次。

景区排行柱状图建议用横向柱状图（yAxis是类目，xAxis是数值），因为景区名称短则4个字长则8个字，纵向柱状图的x轴只会挤成一团。横向柱状图还能方便地按数值大小排序，一眼看出谁是第一。

地图图表在这个项目里是可选的，需要先加载中国地图的GeoJSON。ECharts 5.0之后地图数据已不内置，需要单独引入china.js或使用 echarts 扩展，网上可以找到很多现成资源。如果嫌地图数据包麻烦，用饼图展示客源省份分布也一样直观。

4.3 图表自适应与数据刷新

大屏页面有个特殊需求：经常需要在不同分辨率的屏幕上展示，从32寸显示器到LED拼接屏都有可能。如果不做自适应，全屏之后图表要么拉伸变形、要么留白过大。

我用ECharts官方推荐的resize方案：

window.addEventListener('resize', function () { trendChart.resize(); rankingChart.resize(); provinceChart.resize(); });

同时把图表容器设置成100%宽度，固定高度或按比例计算。实际项目中32:9的超宽屏会用到grid分栏，这里不展开，普通16:9屏幕这套配置完全够用。

自动刷新用setInterval：

function refreshAllCharts() { $.getJSON('/api/monthly-trend/', function (data) { trendChart.setOption({ xAxis: { data: data.months }, series: [ { data: data.tourists }, { data: data.revenue } ] }); }); // 其他图表同理 } setInterval(refreshAllCharts, 30000); // 每30秒刷新一次

这里有个细节：刷新的时候不要重新init图表，而是复用原图表实例调用setOption，这样图表不会闪动。setOption可以只传变化的字段，未传字段保持不变，ECharts 会做 merge。如果传setOption(newOption, true)，notMerge参数为true会整体替换，但会导致图表重绘闪烁，不建议在大屏上用。

5. 常见问题排查与经验复盘

5.1 ORM聚合查询的坑：group by用了哪些字段

用values('scenic_spot__name').annotate(Sum('tourist_count'))没有问题，但如果在values里多加几个字段，比如values('scenic_spot__name', 'province')，那么聚合粒度就变了——分组维度从"景区"变成了"景区+省份"的组合。这个坑比较隐蔽，因为代码不会报错，但是结果和预期差得很远。

调试这种问题有一个通用思路：停掉缓存，先在shell里跑查询，打印str(qs.query)看生成的SQL，检查GROUP BY后面跟了几个字段。如果GROUP BY字段和分组意图不一致，优先修改values参数。

5.2 时区导致的时间数据偏移

Django 有个USE_TZ=True的默认配置，MySQL 存的是UTC时间。国内时间和UTC相差8小时，如果当天凌晨的业务数据被记录成UTC时间，查询visit_date时就会出现一天偏差。

因为这个项目统计的都是自然日数据，DateField本身不涉及时区转换，所以没踩到DateTimeField的坑，但如果你把统计日期改成了DateTimeField，在按月分组时建议在settings.py设置TIME_ZONE = 'Asia/Shanghai'，并且明确USE_TZ = True。如果发现数据整体偏移一天，把USE_TZ设为False是最快的解决办法，但代价是Django和数据库的时区逻辑都由你自己负责，两边必须保持一致。

5.3 可视化图表细节：中文标签、字体和大数字

旅游数据分析系统里，图表文字全是中文，有几个细节直接影响大屏的观感：

• 字体用系统默认的"Microsoft YaHei"或"PingFang SC"，相比ECharts默认的无衬线字体，中文渲染会清晰很多。
• 大数字展示不要用科学计数法，用JS的toLocaleString('zh-CN')给数字加千分位分隔符，比如1,234,567比1234567更易读。
• 饼图标签容易重叠，配置label: { formatter: '{b}\n{c} ({d}%)' }分行显示名称和占比，并且开启avoidLabelOverlap: true。
• 柱状图数值过大时，坐标轴标签不要全部显示，设置interval: 'auto'让ECharts自动抽稀。

还有一个容易被忽略的点：大屏项目通常会把页面投到电视或LED屏上，如果电视长期显示固定界面，会有烧屏风险。我一般会在页面右下角加一个缓慢移动的数字时钟，顺带显示数据更新时间，既解决了烧屏问题，也解决了"数据到底是不是最新的"这个领导最爱问的问题。

5.4 性能优化与上线清单

系统上线前，有几件和代码无关但必须做的事：

1. 把DEBUG = False，不然出错页面会暴露服务器路径和配置信息。
2. ALLOWED_HOSTS配置成实际域名或IP，开发环境下经常有人忘了配，生产环境一刷新就报DisallowedHost。
3. 用 Gunicorn 启动 Django：gunicorn tourism_analysis.wsgi:application -w 4 -b 127.0.0.1:8000，再用 Nginx 做反向代理和静态资源托管。
4. 静态文件收集：python manage.py collectstatic，否则 CSS 和 JS 文件在 Nginx 下面根本找不到。

性能层面，我的经验判断是：数据量在 10 万级以内，这套架构随便跑不卡；如果超过百万级，建议给 MySQL 加只读从库，或者把聚合结果做成定时任务（crontab+manage.py shell脚本）在凌晨算好之后存到独立统计表里，大屏只查算好的结果，不再实时跑GROUP BY。

我在实际做项目时，第一版就直接上了实时聚合查询，页面加载一次大概要2秒。优化之后改成定时预计算+Redis缓存，页面加载降到300ms以内，体感提升非常明显。如果你的大屏有"秒开"需求，强烈建议走预计算这条路。

写在最后

回到标题说的"旅游数据分析可视化系统"，总结下来，本质是用 Django 做数据的搬运工和加工厂，用 ECharts 做数据的翻译官。项目难度不在技术本身，而在整理需求和把数据算对的过程。

我个人实际做下来有几个体会：第一，模型设计一定要花时间想清楚，时间维度和景区维度是主轴，别急着写视图函数；第二，接口返回的 JSON 结构先定好，前端写起来才会顺手；第三，模拟数据阶段就要带业务规律，不然图表画出来没有说服力，领导看了会说"这数据是不是假的"。最后再说一句，项目里图表不需要贪多，五到六张能说明核心问题的图，远比十张没有重点的图有价值。