React + Vite + Docker 构建影院实时导航看板与云部署实战

原创

于 2026-05-26 15:33:46 发布 · 1k 阅读

1. 项目概述：一个实时影院中场休息导航看板

最近在做一个挺有意思的玩意儿，我管它叫 MovieSync 。简单来说，它是个给电影院中场休息用的实时看板。想象一下这个场景：电影放到一半，中场休息的灯亮了，你冲出影厅，想去上个洗手间或者买点爆米花，结果发现每个地方都排着长队。宝贵的十几分钟休息时间，全浪费在盲目排队和来回折返上了。MovieSync 要解决的就是这个痛点——它通过一个简洁的仪表盘，实时展示影院内各个功能区（洗手间、小卖部、休息区）的拥挤程度，让你一眼就能知道该往哪儿走，避开人潮。

这个项目从构思到上线，我全程都在“公开构建”——也就是把开发过程、技术选型、踩过的坑都分享出来。这不仅仅是秀成果，更重要的是把背后的决策逻辑和工具链也摊开来讲，希望能给同样在捣鼓类似项目的朋友一些参考。整个项目的前端用 React + Vite 搭建，追求极致的轻快；UI 是自己手搓的 Vanilla CSS，搞了点玻璃拟态的效果；后端部署则完全交给了 Google Cloud Run 这个无服务器平台，配合 Docker 多阶段构建，确保生产环境干净利落。

在整个开发流中，我深度整合了一个叫 Antigravity 的开发加速工具。它不是什么魔法，但确实像给项目装上了助推器，特别是在项目脚手架、开发迭代和云部署工作流这几个环节，极大地减少了那些繁琐、重复的配置工作，让我能把精力更集中在业务逻辑和用户体验本身。接下来，我会把这套技术方案的里里外外、为什么这么选、具体怎么实现，以及那些只有亲手做过才会知道的细节，毫无保留地拆解一遍。

2. 核心思路与技术选型解析

2.1 问题定义与解决方案设计

问题的核心其实非常具体： 信息不对称导致的资源（时间）错配 。在电影院中场休息这个短暂、高压的决策窗口里，观众缺乏对现场人流分布的全局感知。传统的解决方案（比如靠猜、靠问工作人员）效率低下。因此，MovieSync 的定位不是一个功能复杂的“影院管理系统”，而是一个 单一职责、即时生效的信息显示屏 。它的设计必须遵循几个原则：

极简信息呈现 ：用户扫一眼（通常在3秒内）就必须能理解当前状态。所以采用了最直观的“红绿灯”颜色编码系统：绿色代表畅通（可立即前往），橙色代表中等拥挤（可能需要短暂等待），红色代表高度拥堵（建议避开或选择其他目标）。
实时性优先 ：数据哪怕延迟5-10秒，在这个场景下都可能完全失效，导致用户做出错误决策。因此，从数据采集到前端展示的链路，延迟必须尽可能低。
零学习成本 ：用户不可能、也不应该去阅读使用说明。界面本身必须是自解释的。

基于这些原则，技术选型上的一切决策都服务于“快速、轻量、可靠”这个总目标。

2.2 前端技术栈：为什么是 React + Vite + Vanilla CSS？

React 的选择几乎是现代 Web 开发的首选，但在这里有更具体的考量。MovieSync 的看板本质上是一个 状态驱动的动态视图 。各个区域的人流密度状态是核心数据，这个状态的变化需要高效、可预测地驱动 UI 更新。React 的组件化思想和虚拟 DOM 差分更新机制，非常适合这种“数据变，视图自动变”的模式。相比直接操作 DOM 或者使用更轻量的库，React 提供了更健壮的状态管理基础和更丰富的生态系统（虽然本项目没用到太多第三方库），为后续可能的功能扩展（如多影院视图切换、用户偏好记忆）预留了空间。

Vite 则是提升开发体验和构建速度的关键。在项目初期，快速的冷启动和热更新（HMR）能让我几乎实时地看到代码改动效果，这对于精细调整 UI 动效和布局至关重要。Vite 基于原生 ES 模块的按需编译，比传统的 Webpack 打包器在开发阶段要快上一个数量级。在生产构建方面，Vite 内置了 Rollup 进行高效的 Tree Shaking 和代码分割，能生成优化过的静态资源，完美契合本项目最终需要被 Nginx 服务的部署形态。

注意：很多人会纠结于“这么简单的页面是否需要 React”。我的经验是，如果项目未来有任何状态复杂化或交互增加的可能性（哪怕只有10%），从 React 开始都是更稳妥的。反之，如果100%确定就是一个永不变化的静态页面，那确实没必要。但 MovieSync 的“实时数据模拟”和“动态颜色切换”已经构成了足够使用 React 的理由。

放弃重型 UI 框架，选择 Vanilla CSS ，这是一个经过权衡的决策。像 Material-UI 或 Ant Design 这样的框架固然能快速搭建出美观的界面，但它们会引入数百 KB 甚至 MB 级的额外 JavaScript 和 CSS 体积。对于 MovieSync 这种追求极致加载速度、很可能被投映在影院大屏或通过用户手机快速访问的场景，每一 KB 都值得计较。手写 CSS 虽然初期工作量稍大，但能实现完全定制化的设计（如玻璃拟态效果），并且最终产出的 CSS 文件经过压缩后可以小到忽略不计。这确保了页面在任何网络条件下都能瞬间加载。

2.3 后端与部署架构：Serverless 与容器化的结合

后端部分的核心需求是： 以极低的成本和运维负担，提供高可用的静态文件服务和未来可能的实时数据接口 。这几乎是为 Serverless 架构量身定做的场景。

我选择了 Google Cloud Run 。它允许我将整个应用打包成一个 Docker 容器，然后完全不用关心服务器、虚拟机、集群管理。Cloud Run 会根据传入的 HTTP 请求量自动从零缩放实例到 N，不用请求时就缩放到零，真正做到按使用量付费。对于 MovieSync 这种访问模式可能极不规律（电影散场时突发流量高，平时几乎为零）的应用来说，成本效益极高。

Docker 多阶段构建 是连接开发与云部署的最佳实践。它解决了两个问题：

构建环境与运行环境分离 ：第一阶段使用包含 Node.js、npm 等重型工具的镜像来安装依赖、打包 React 应用；第二阶段则仅使用轻量的 Nginx 镜像，只从第一阶段复制构建好的静态文件（ dist 目录）。这样，最终的生产镜像不包含任何源代码、开发依赖和构建工具，体积小、安全性高。
环境一致性 ：无论在本地、CI/CD 流水线还是 Cloud Run 上，应用都运行在完全相同的 Nginx 环境中，彻底杜绝了“在我机器上是好的”这类问题。

Nginx 作为静态文件服务器是久经考验的选择。它轻量、高效、稳定，配置简单。在 Docker 容器内，它监听 8080 端口，提供压缩、缓存等基础优化，完美胜任工作。

2.4 Antigravity 在开发流中的角色

Antigravity 在这里不是一个独立的技术层，而是一个 开发体验增强工具 。你可以把它理解为一套高度定制化的项目模板和自动化脚本的集合，但它通过更智能的方式与我的 IDE 和云平台集成。

在 MovieSync 项目中，它主要帮我解决了以下“脏活累活”：

项目初始化 ：不是简单的 create-react-app ，而是一键生成一个预配置了 Vite、React、ESLint (Airbnb 规则)、Prettier、以及针对 Cloud Run 部署的 Dockerfile 和 cloudbuild.yaml 的完整项目骨架。这为我节省了至少半天的统一配置时间。
开发环境热重载优化 ：它对 Vite 的 HMR 配置做了微调，使得在 Docker 容器内进行开发时，文件变化的侦测和更新速度更快，几乎与本地开发无感。