Vue3+TagCanvas实战：年会抽奖系统的技术架构与性能优化深度复盘

2024年初，我接手了一个年会抽奖工具的开发任务。彼时团队规模约150人，活动现场需要一套稳定、可控且具有一定视觉冲击力的抽奖系统。

当时的约束条件很明确：

开发周期压缩到48小时内；必须兼容Chrome/Safari等主流浏览器；现场网络环境不可控，需要Offline-First设计。

为什么选择Vue3作为基础框架

技术选型阶段，我排除了纯DOM方案和React方案。

前者维护成本过高，后者对于简单场景过于笨重。Vue3的CompositionAPI提供了良好的逻辑复用能力，Pinia的状态管理也足够轻量。TypeScript的静态类型检查则在多人协作场景下至关重要。

实际开发中，Composables模式被大量使用：抽奖逻辑、3D标签云封装、音频控制三大模块各自独立，通过统一接口暴露方法。这种设计使得核心逻辑与UI层完全解耦，后续调整界面时无需触碰业务代码。

TagCanvas是实现3D标签云效果的核心依赖。初始化时需要配置以下参数：

weight从1到15决定了标签的字体大小梯度；maxSpeed控制旋转动画的灵敏度；minSpeed则设定了最低转速阈值，防止视觉停滞。

关键的性能优化点在于：头像图片必须预加载，否则首次渲染时会出现明显的闪烁。解决方案是建立Image对象缓存池，配合requestIdleCallback实现非阻塞预加载。

localStorage承担了配置、名单、结果的存储职责，IndexedDB则专门管理头像元数据。这种分层设计的依据是：前者适合存储小体积的JSON配置，后者擅长处理二进制图片数据。

持久化策略采用Write-Through模式：每次状态变更后立即同步到存储层。相比Debounce方案，这增加了少量写操作，但彻底消除了数据丢失风险。

对于头像存储，采用了文件名即用户Key的命名规范，配合IndexedDB的索引能力，实现了O(1)的头像查询效率。

这个功能源于一次真实的事故。去年年会进行到一半时，领导临时要求增加一个特别奖。如果奖项写死在代码里，整个流程将被迫中断。

解决方案是双层配置架构：代码层维护默认奖项的版本化管理，UI层提供运行时的新增能力。两者完全正交，通过PiniaStore统一协调。

实践证明，这类现场工具的业务弹性往往比代码优雅性更重要。

GitHubPages作为静态托管方案，配合GitHubActions实现自动化部署。构建流程包含依赖安装、TypeScript编译、资源压缩、产物发布四个阶段，总耗时约90秒。

生产环境监控显示，该系统已在多个企业内部活动场景中稳定运行，累计处理抽奖记录超过5000条。