企业官网建设流程全解析

毕业设计选了这个题目，做着做着发现它其实是把旅游行业里最经典的三个场景——门票购买、酒店预订、管理端数据看板——全塞进了一个系统里。当时我就意识到，光把CRUD写完根本不够，门票的库存扣减、酒店的房态管理、订单状态的流转、图表可视化的数据聚合，每个环节都有讲究。这篇文章就把这个项目从架构设计到落地实现的完整过程拆开讲清楚，包括我踩过的坑和最后总结的经验，希望能给正在做类似系统的你一些参考。

这个项目表面上是"微信小程序 + Spring Boot + 可视化"三个关键词的堆叠，实际上是一套完整的业务系统。所以我不打算只讲代码片段，而是按一个真实项目的推进顺序，从业务分析、数据库设计、后端接口、小程序端交互、可视化图表实现，到最后部署上线的常见问题，形成一个可以直接复用的完整思路。

1. 项目全貌拆解：一套系统里的三个身份

1.1 业务模块到底包含哪些

在做任何代码之前，先把这个项目的业务边界画清楚。标题叫"旅游门票酒店预订系统"，核心服务对象是两类人：一是普通游客，他们通过微信小程序完成景点门票和酒店的查询、下单、支付；二是平台运营人员，他们通过管理后台维护景点和酒店信息，处理订单，查看经营数据。

从功能维度拆，整个系统存在三个截然不同的"身份视角"。

第一是C端用户的微信小程序，这是游客直接接触的部分。核心功能包括：

• 用户登录与授权（微信一键登录、手机号绑定）
• 景点门票浏览与搜索（按地区、热度、价格筛选）
• 门票详情与下单（选择日期、数量、游客信息）
• 酒店列表与详情（房型展示、入住日期、价格日历）
• 酒店预订与订单确认
• 订单中心（查看全部订单、待支付、已支付、已完成、退款申请）
• 个人信息管理

第二是B端管理后台，运营人员使用，功能包括：

• 景点库管理（新增、编辑、上下架）
• 酒店库管理（酒店基础信息、房型管理、价格设置）
• 订单管理（订单查询、确认、取消、退款处理）
• 用户管理
• 数据统计与可视化（订单量趋势、销售额统计、热门景点排行、酒店入住率）

第三是系统底层的技术支持组件，包括统一认证鉴权、Redis缓存、异常处理、日志记录、微信支付回调处理等。

这三个身份之间的数据流向其实很清晰：小程序产生业务操作，后端通过接口接收请求并处理业务逻辑，管理后台读取数据库中的业务数据并通过图表展示。把这个数据流理顺，后面的开发就会顺畅很多。

1.2 技术选型：为什么是这个组合

技术栈的选择一定要说明白，这不只是"跟风用热门技术"，每个环节都有它存在的理由。

后端选择Spring Boot，这个几乎没有悬念。Spring Boot在Java生态里就是做微服务和业务系统的标准方案，约定优于配置，起步依赖很方便，内嵌Tomcat让部署变得简单，配合MyBatis-Plus操作数据库能省掉大量繁琐的SQL编写。更重要的是，Spring Boot的生态系统非常成熟——Spring Security做权限、Redis做缓存、Spring Validation做参数校验，这些都是开箱即用。

前端选择微信小程序，理由更直接：旅游场景是强移动端、强社交分享的场景。用户不用下载App，微信里搜一下或者扫个码就能用，用完即走，这种轻量体验非常适合低频的旅游消费决策。而且微信小程序自带支付能力，微信支付在旅游业里几乎就是标配。

可视化部分，管理后台用ECharts是最靠谱的选择。ECharts对中文支持好、文档完善、图表类型丰富，做订单趋势、销售统计、景点热度排行都很顺手。如果你做的是大屏版，同样可以用ECharts配合可视化大屏组件来搭建。

补充一个关键点：系统编号里的"4_y65c9x2y"这种版本号不用太在意，它就是项目归档时自动生成的标识，重点还是功能本身。

1.3 开发数据库设计先行

数据库设计是整个项目的定海神针，定好了表结构，后端接口写起来才会顺畅。这个系统的核心数据表可以分为四组。

用户相关：

• 用户表（user）：用户id、微信openid、昵称、头像、手机号、注册时间

景点相关：

• 景点分类表（scenic_category）：分类id、名称、排序
• 景点表（scenic）：景点id、所属分类、名称、简介、详细地址、图片URL、价格、开放时间、库存上限、状态

酒店相关：

• 酒店表（hotel）：酒店id、名称、地址、星级、简介、图片、联系电话、状态
• 房型表（room_type）：房型id、所属酒店、房型名称、面积、床型、价格、数量、状态

订单相关：

• 订单表（ticket_order）：订单id、订单编号、用户id、景点id、游玩日期、门票数量、总金额、状态、支付时间、创建时间
• 订单表（hotel_order）：订单id、订单编号、用户id、酒店id、房型id、入住日期、离店日期、入住人数、总金额、状态、支付时间、创建时间

特别提醒，订单编号不要用数据库自增ID，要单独生成，格式建议为时间戳 + 用户id后四位 + 随机数，这样既保证全局唯一，还能在排查问题时一眼看出订单生成的大概时间。

库存字段的设计是我这次深有体会的地方。景点门票的"每日库存"和酒店的"每日房量"是动态变化的，不能简单地用一个固定库存字段去递减。我用的方案是增加一张"库存日期表"：库存表（scenic_stock），针对景点和日期记录当天的可售数量，下单时校验并扣减。酒店同理，用"房型+日期"作为维度管理房量。这个设计直接避免了"国庆节第一天卖光了，但第二天还没到却显示无票"这种尴尬问题。

2. Spring Boot后端：订单、库存和支付三个硬骨头

2.1 分层架构与项目骨架

Spring Boot项目的包结构我习惯按照业务模块划分，而不是严格按技术分层。一个典型的包结构长这样：

com.example.travel ├── controller // 接口层 ├── service // 业务逻辑层 ├── mapper // 数据访问层 ├── entity // 实体类 ├── vo // 视图对象 ├── dto // 参数传输对象 ├── config // 配置类 ├── common // 公共返回结果、全局异常处理 └── utils // 工具类

每个业务模块在service下独立一个目录，比如service/ticket、service/hotel、service/order、service/stats，实际上读写数据更方便。全局返回结果我用了一个统一的Result<T>类，包含code、message、data三个字段，这样前端拿数据时只用关注code是否为200，不用处理各种异常情况。

全局异常处理必须写。我见过很多项目没有统一的异常处理，导致数据库报错信息直接暴露给前端，这既不安全，体验也不好。我采用@RestControllerAdvice实现全局异常捕获，业务层抛出自定义的BizException，异常处理器统一封装返回，前端能拿到明确的错误提示，后端日志里也能看到具体的堆栈信息。

2.2 数据库表结构：订单状态机是核心

以门票订单表为例，核心字段我这样设计：

ticket_order - id BIGINT PRIMARY KEY AUTO_INCREMENT - order_no VARCHAR(64) UNIQUE NOT NULL COMMENT '订单编号' - user_id BIGINT NOT NULL COMMENT '下单用户' - scenic_id BIGINT NOT NULL COMMENT '景点id' - play_date DATE NOT NULL COMMENT '游玩日期' - ticket_count INTEGER NOT NULL DEFAULT 1 COMMENT '门票数量' - total_amount DECIMAL(10,2) NOT NULL COMMENT '订单总金额' - status TINYINT NOT NULL DEFAULT 0 COMMENT '订单状态：0待支付，1已支付，2已完成，3已取消，4退款中，5已退款' - name VARCHAR(50) NOT NULL COMMENT '游玩人姓名' - phone VARCHAR(20) NOT NULL COMMENT '游玩人手机号' - create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP - pay_time DATETIME NULL COMMENT '支付时间'

订单状态机是整个系统设计的灵魂。它的流转逻辑是：

• 创建订单 => 状态0（待支付）
• 用户支付 => 状态1（已支付）
• 已支付订单到游玩日后自动或定时任务更新为状态2（已完成）
• 用户主动取消 => 状态3（已取消）或状态4（退款中）

这个状态机在后端代码中通常用一个枚举类来定义，这样在代码里写OrderStatus.PAID.getStatus()比写魔法数字1清晰得多。管理后台处理退款时，会把状态从已支付切换到退款中，退款成功后再切换到已退款。这里要注意，退款中的订单不能直接变成已完成，必须走完退款流程才能做最终状态变更。

2.3 门票下单：库存扣减与支付回调的处理

门票下单是整个系统里并发要求最高的场景。热门景点在节假日可能出现集中抢购，如果用"先查库存再更新库存"的方式，很容易超卖。

我的解决方案分两步。

第一步，下单接口先用SELECT ... FOR UPDATE锁定库存记录。这里要注意，必须在事务内执行且确保索引命中，否则行锁会退化成表锁，性能反而下降。伪代码如下：

@Transactional(rollbackFor = Exception.class) public OrderResult createTicketOrder(TicketOrderDTO dto) { // 1. 检查用户登录状态 // 2. 查询景点信息，确认上架状态 // 3. 查询当日库存，锁定库存记录 ScenicStock stock = scenicStockMapper.selectForUpdate(dto.getScenicId(), dto.getPlayDate()); if (stock == null || stock.getAvailableCount() < dto.getTicketCount()) { throw new BizException("当日库存不足，请调整游玩日期"); } // 4. 扣减库存 scenicStockMapper.decreaseStock(stock.getId(), dto.getTicketCount()); // 5. 生成订单记录，状态为待支付 // 6. 返回订单信息 }

但是SELECT ... FOR UPDATE有个明显问题：它会把锁一直持有到事务结束。如果用户下单后迟迟不支付，库存就被锁住，其他用户无法购买。所以我做了两件事来规避：

第一，支付超时处理任务。系统设定订单15分钟未支付自动取消，使用Spring Quartz或者简单的定时任务扫描超时订单，取消订单并回补库存。这道兜底逻辑保证锁不会被无限期占用。

第二，支付成功后回补确认。微信支付结果是异步回调通知后端，所以在用户支付成功后，系统才会真正完成状态变更。回调顺序是：支付回调改订单状态为已支付 => 已支付订单的库存不用再回补，保持扣减状态即可。

酒店预订的流程基本一致，区别在于要按入住日期区间扣减库存。比如用户预订7月1日到7月3日的房间，那这三天的房量都要扣减。

2.4 酒店搜索与价格日历的SQL优化

酒店列表页的查询条件是：城市 + 入住日期 + 离店日期 + 人数。这里最核心的SQL是根据日期筛选出"每一天都有空闲房"的酒店。一个比较高效的思路是：

先查出所有满足城市条件的酒店，再通过子查询排除掉"在入住日期与离店日期之间，房型已满"的酒店。这个SQL要在hotel表、room_type表、hotel_stock表（按日期记录房量）三表之间做JOIN。数据量大了以后要给hotel_stock表的hotel_id + date字段建联合索引，不然查询会非常慢。

价格日历是我觉得这个项目里比较体现产品细节的地方。前端需要展示某个酒店未来30天每天的房价，而后端不能每次实时查房型表再动态计算。我的做法是：在room_type表里设置基础价格，为特定日期（节假日、周末）单独维护一张"价格日历表"（price_calendar），记录特殊日期的加价比例或具体价格。前端请求时，后端同时读取基础价格和特殊价格，合并返回30天价格数组。这样既有灵活性，也避免了每晚定时任务刷价格表的麻烦。

3. 微信小程序端：从页面到交互的完整实现

3.1 开发框架的选择

微信小程序开发目前主流有两条路：原生开发和uni-app跨端开发。这个项目我选的是原生开发，原因是项目只做微信小程序一个端，没必要引入跨端框架的编译层，原生开发的性能和调试体验都更好。如果你后续有鸿蒙App、安卓/iOS的需求，再考虑用uni-app重写也不迟。

原生小程序的目录结构按页面划分，核心代码文件类型是.wxml（页面结构）、.wxss（样式）、.js（逻辑）、.json（页面配置）。项目结构大致如下：

miniprogram/ ├── app.js // 全局逻辑、登录处理 ├── app.json // 全局配置、页面路由 ├── app.wxss // 全局样式 ├── utils/ │ ├── request.js // 请求封装 │ └── util.js // 工具函数 └── pages/ ├── index/ // 首页 ├── ticket-list/ ├── ticket-detail/ ├── hotel-list/ ├── hotel-detail/ ├── order-confirm/ ├── order-list/ └── mine/

3.2 请求封装与登录态管理

小程序端的请求封装是很多人容易忽略但实际坑最多的地方。我的utils/request.js会统一处理以下事情：

1. 在请求头中自动携带token（从本地缓存读取）
2. 统一处理不同HTTP状态码，401跳转登录页
3. 统一处理后端返回的code，非200时调用全局toast提示
4. 封装GET、POST方法，方便业务代码调用

const request = (options) => { return new Promise((resolve, reject) => { wx.request({ url: BASE_URL + options.url, method: options.method || 'GET', data: options.data || {}, header: { 'Content-Type': 'application/json', 'Authorization': wx.getStorageSync('token') }, success: (res) => { if (res.statusCode === 200 && res.data.code === 200) { resolve(res.data.data); } else { wx.showToast({ title: res.data.message || '请求失败', icon: 'none' }); reject(res.data); } }, fail: (err) => reject(err) }); }); };

登录是整个小程序最关键的身份认证环节。我的做法是：用户首次进入页面，调用wx.login()获取临时code，将code发送给后端，后端调用微信的code2Session接口换取openid，然后在后端生成自定义token返回给前端。前端把token保存在本地缓存里，后续所有请求都带上这个token。这样就不需要用户手动输入用户名密码，体验很顺畅。

有一个特别容易踩的坑是：使用手机号组件获取用户手机号时，需要先在微信公众平台申请开通，并且要跟已认证的小程序账号绑定。如果没用认证的AppID（比如测试号），手机号功能就用不了。实测阶段建议先用账号密码模拟登录，正式上线前再切换成微信手机号授权。

3.3 门票列表页与酒店详情页的关键交互

门票列表页的核心是筛选与搜索。顶部放一个搜索框，下面可以按照"热门排序""价格排序""地区筛选"三个维度切换。这里我用了微信小程序自带的scroll-view实现列表滚动加载更多，触底时自动请求下一页数据，避免一次性加载全部门票导致页面卡顿。

酒店详情页相比门票详情要复杂一些。我设计了三个模块：

• 酒店信息区：轮播图、名称、地址、星级、评分
• 房型列表区：每个房型卡片展示面积、床型、价格，点击"预订"按钮跳转订单确认页
• 入住信息栏：入住日期、离店日期、房间数，日期选择器基于微信小程序原生picker组件封装

发现一个原生的坑：picker的日期选择在快速切换时，可能会因为bindchange事件触发多次而出现选择日期错乱。解决办法是在切换日期时加一个防抖逻辑，或者直接改用第三方日期组件。实测下来，用Vant Weapp的日历控件体验更好，而且它免费开源，小程序里直接npm依赖就能用。

3.4 订单确认与微信支付流程

订单确认页要同时展示门票或酒店的信息、数量、单价、总价以及游玩人信息填写。这里有个产品细节很实际：用户选完游玩日期后，还需要填写游玩人姓名和手机号，如果每次下单都重新输入会很烦。我在用户首次填写后，把它保存在本地缓存和用户表里，下次下单自动带出，只保留可编辑功能。这种方式减少了用户操作步骤，下单转化率明显提升了。

微信支付的接入流程分成三步：

1. 用户点击"立即支付"按钮，前端请求后端创建微信支付统一下单接口
2. 后端调用微信支付接口，得到payment参数（包括时间戳、随机串、package、signType等等）
3. 前端调用wx.requestPayment，拉起微信支付面板，用户输入密码完成支付

后端接支付回调一定要处理"重复通知"的问题。微信支付会在一定时间内多次回调同一个支付结果，如果每次回调都直接修改订单状态并回补库存，就会造成重复扣库存的严重bug。我的处理方式是：

// 在支付回调处理中，增加幂等检查 if (order.getStatus() == OrderStatus.PAID.getStatus()) { log.info("订单重复回调，orderNo={}", orderNo); return Result.success(); }

每次回调先检查订单的状态，如果已经是已支付，直接返回成功，不再重复处理。

4. 可视化模块：不是图表堆砌，是数据决策

4.1 为什么管理后台必须做可视化

标题里"可视化"这个关键词，很多人第一反应就是"图表展示"，但实际做下来我发现，它的本质是给管理人员提供一个"用数据做决策"的工具。在这个旅游系统里，可视化模块的价值主要体现在三个方面：

• 一眼看出整体经营情况：今日订单数、今日销售额、本月订单趋势
• 识别热门产品：哪些景点卖得最好、哪些酒店订得最多
• 发现问题：某个景点的销量连续下降、某个酒店的订单集中在某一天

所以我在设计后端统计接口时，不是简单地返回一堆明细数据让前端自己算，而是后端直接聚合好指标，前端直接展示。这样既减少前端的计算工作量，也避免跨页面的分析逻辑不一致。

4.2 后端统计接口的数据聚合逻辑

我设计了一个统计模块，包含以下几个接口：

• GET /admin/stats/overview：返回今日订单数、今日销售额、总订单数、总销售额、用户总数
• GET /admin/stats/order-trend?days=30：返回最近30天每天的订单数和销售额
• GET /admin/stats/hot-scenic?limit=10：返回销量前十的景点
• GET /admin/stats/hotel-occupancy?days=30：返回各酒店的入住率

这些接口底层都是SQL聚合。以订单趋势为例，最直接的SQL是：

SELECT DATE(create_time) AS date, COUNT(*) AS order_count, SUM(total_amount) AS amount FROM ticket_order WHERE create_time >= DATE_SUB(CURDATE(), INTERVAL 29 DAY) GROUP BY DATE(create_time) ORDER BY date;

这里有个很容易踩的坑：如果某一天没有任何订单，这条SQL返回的结果里就看不到那天，前端做折线图时就会出现断档。我的解决办法是在Java代码里补全缺失的日期，生成一个完整的30天序列，没有数据的日期用0填充。这个细节虽然小，但很影响图表的美观度和可读性。

热门景点排名接口，我用的是订单表的聚合加景点表的关联查询：

SELECT s.name AS scenic_name, COUNT(so.id) AS order_count, SUM(so.ticket_count) AS ticket_count FROM ticket_order so JOIN scenic s ON so.scenic_id = s.id WHERE so.status IN (1, 2) GROUP BY s.id, s.name ORDER BY ticket_count DESC LIMIT 10;

这里有一个小经验：统计时只统计已支付状态（status=1）和已完成状态（status=2）的订单，把待支付和已取消的订单排除掉，否则数据会虚高，管理人员看了容易误判。

4.3 ECharts在管理后台的落地

管理后台我用的是一个轻量级的Vue + Element UI + ECharts组合。ECharts的接入方式很成熟，在Vue组件里引入echarts包，然后在mounted钩子中初始化图表实例，通过setOption传入统计数据。

订单趋势图的核心配置大概是这样的：

// 伪代码：订单趋势折线图 option = { xAxis: { type: 'category', data: dateList }, yAxis: { type: 'value', name: '订单数' }, series: [ { name: '订单数', type: 'line', data: orderCountList, smooth: true }, { name: '销售额', type: 'line', data: amountList, smooth: true, yAxisIndex: 1 } ] };

要注意的是双Y轴处理。订单数和销售额的量级完全不一样（订单数可能是几十，销售额可能是几万），如果放同一个Y轴，订单数的曲线几乎会被压平。设置yAxisIndex让两条曲线分别对应左右两侧的Y轴，图形看起来就正常多了。

可视化大屏版我在后面又扩展了一个页面，把核心指标做成了大屏看板展示在办公室的电视上，整体用了背景色渐变、数字滚动动画、以及轮播的Top榜单。不需要特别复杂的可视化库，ECharts + 一点CSS动画就够了。

4.4 可视化性能优化的两个小技巧

数据可视化模块最容易出性能问题的是两个点：

第一，每天定时刷新的统计接口，如果查询范围很大，会很慢。比如查询一年订单趋势，SQL要扫描一整年的订单表。我的做法是加一层Redis缓存，统计接口的结果缓存在Redis中，缓存时间为10分钟，并且管理后台操作订单后主动清掉缓存。这样管理人员打开看板时，响应速度基本是毫秒级。

第二，前端图表要按需渲染。ECharts的整个包体积不小，如果一次性全部引入，页面加载会有明显延迟。我直接在管理后台项目里通过echarts/core按需引入LineChart、BarChart、PieChart这些核心组件，剩下的按需注册，最终打包体积能减少一半以上。这个小改动在低配电脑上访问后台时感知非常明显。

5. 部署上线与踩坑总结

5.1 环境配置与部署清单

开发和测试环境跑通以后，部署上线这步看似简单，实际上坑很多。我的部署方案是：

• 后端：打包成jar，部署在服务器的Tomcat上（也可以用Docker容器方式）
• 前端：微信开发者工具上传代码到微信公众平台，提交审核
• 数据库：阿里云RDS MySQL
• 缓存：Redis服务
• 文件存储：图片和景点介绍等静态资源放在MinIO（一个开源的分布式对象存储），比直接存数据库的字段里或者服务器本地文件都方便很多

这里有个特别容易犯的错：小程序正式版要求请求的域名必须备案，并且要在微信公众平台配置为request合法域名，而且必须用HTTPS协议。开发调试时经常使用本地IP加端口，但提交审核前一定要把后端接口域名换成已备案的HTTPS域名。如果漏了这一步，小程序线上请求会直接失败，而且提示信息很模糊，容易排查很久。

数据库连接池的配置也不能忽视。生产环境我一般设置initial-size: 10、max-active: 100、min-idle: 5，并且开启连接池的检测SQLtest-on-borrow: true。如果没有这些配置，高峰期可能出现连接不够，或者数据库主动断开时连接池持有了失效连接，表现就是偶发的请求超时。

5.2 高频踩坑与解决方案

在做这个项目时，我整理了一份高频坑位清单，这里挑几个特别有价值的分享。

坑一：微信登录openid获取失败。出现这种情况，大概率是AppID和密钥配置错了，或者后端请求微信接口时参数签名不对。排查方法是先看后端日志，看返回的errcode是多少；如果是40029说明code无效，如果40163说明code已经用过，重复使用了。特别注意，wx.login()返回的code只能用一次，后端必须在有效期内（5分钟）使用，否则会失效。

坑二：下单支付成功，但订单状态没变成已支付。这个问题90%出在微信支付回调的URL配置。我在微信支付平台设置的支付回调URL必须带上/api/pay/wxpay/notify这个完整路径，并且这个URL要能被外网访问到。如果回调URL配置成了内网地址或本地IP，微信支付回调永远到达不了你的服务器。建议在回调接口里加上日志打印，出现问题时先看有没有回调记录。

坑三：库存数据错乱。我遇到过一次，原因是测试时用同一个数据，手动改数据库字段导致库存和订单数量对不上。这提醒我，库存与订单的扣减一定要在同一事务里，不能分两步。如果分两步操作，事务A扣库存成功但事务B生成订单失败，库存就白白少了。解决方案就是我在第2.3节写的伪代码那样，把检查和扣减放在同一个@Transactional方法里。

坑四：小程序端提交订单时重复提交。用户手快点了两次"提交订单"按钮，结果生成了两笔一样的订单。解决方式很简单：前端在按钮提交后立刻置为不可点击，同时后端在创建订单方法里加一个幂等校验，比如用同一个requestId去重，这个requestId由前端生成，传给后端，后端查询是否存在相同requestId的订单，存在则直接返回那个订单。

坑五：耗时统计接口把管理后台卡住。我使用EXPLAIN检查慢SQL时发现热门景点排名这个查询走了全表扫描，原因是ticket_order表的scenic_id没有索引。给scenic_id建了普通索引后，查询速度提升了大概10倍。做数据可视化统计时，给所有聚合查询的WHERE条件涉及的字段都建索引，这几乎是必须的。

5.3 项目收尾时的体验优化

功能做完之后，一定要留出专门的时间做体验优化，这个阶段花的精力值回票价。

推荐几个小而美的优化点：

• 小程序端所有列表页都加"加载中"和"没有更多了"的提示，不然用户会觉得页面卡了。
• 门票详情页和酒店详情页的图片要压缩，用WebP格式，一张高清图从原来的300KB压到80KB，加载速度明显改善。
• 订单列表页显示状态时用彩色标签区分（待支付黄色、已支付绿色、已取消灰色），一眼就能看清，不用点进详情才知道什么状态。
• 后端全局响应增加一个timestamp字段，前端可以根据这个字段做简单的超时校验，排查网络原因崩溃时很有用。

写在最后

这个项目做完，我最大的体会是：旅游预订系统看起来不复杂，但把门票、酒店两个业务线融进一套体系，再把可视化数据打通，细节非常多。最核心的收获有两个：一是库存和订单状态管理一定要有清晰的设计思路，不然并发场景下很容易出事故；二是可视化不等于堆图表，要让数据真正服务于运营决策，指标的口径和数据的准确性比图表的美观度更重要。

如果你也要做类似的项目，建议按我上面的顺序推进：先拿一天时间把业务和表结构设计透彻，再写后端接口，然后开发小程序端联调，最后做可视化大屏。数据库表设计一定要多花时间，后续改表结构是一种巨大的隐性成本。祝你的项目顺利上线。