先说个背景很多人看到一个微剧小程序能跑出日活破万的数据第一反应通常是“这得有多少人和预算”。实际上我做这个项目时团队规模很小从确定用 uni-app 开工到第一版通过审核上线前后正好七天。上线第五天日活冲到了 1.1 万之后一周稳定在 8000 到 12000 之间峰值到过 1.3 万。这篇文章不是标题党式的复盘而是把我做这个短剧平台过程中的真实决策、技术选型、踩坑记录和流量逻辑完整拆开讲一遍。如果你正在用 uni-app 做小程序或者打算入局微短剧、短视频分发类产品我踩过的坑和建议你大概率能直接用上。1. 为什么短剧平台选 uni-app而不是原生小程序1.1 我们当时的真实处境做这个项目之前我们手里已经有了短剧内容的授权和一批成片资源最紧迫的问题不是“怎么把产品做得更炫”而是“怎么最快把内容变成一个小程序让用户能看到、能付费、能分享”。团队配置是两名前端加一名后端UI 设计几乎等于零所有界面都走组件库和模板。在这种背景下原生小程序开发其实不是最优解。我们天然有一整套基于 Vue 的技术经验和组件生态如果切到微信小程序原生 WXML / WXSS等于把已有经验扔掉重学而且只能做微信一端。更重要的是我们想把同一个内容库后续铺到 H5、App 甚至更多小程序平台uni-app 的“一套代码多端编译”对我们是刚需。1.2 uni-app、Taro、原生小程序的三方取舍当时确实在 uni-app 和 Taro 之间犹豫过也做过快速对比真实感受如下表维度微信原生Tarouni-app上手成本需要重学 WXML/WXSS熟悉 React/Vue 语法即可熟悉 Vue 语法即可和普通 Vue 项目几乎一样多端支持只支持微信系支持主流小程序和 H5/React Native支持微信、支付宝、百度、抖音小程序和 H5、App组件生态官方组件稳定但组件少需要自己适配插件市场比较丰富短剧常见需求能找到现成封装IDE 配套微信开发者工具CLI 任意编辑器HBuilderX 或 CLI云打包方便长期维护微信生态内最稳社区活跃项目方向偏 React文档全面历史迭代久踩坑资料多我们最终选了 uni-app 还有一个现实原因团队里后端同学也会用 Vue整体不需要岗位切换。HBuilderX 对 uni-app 的支持确实顺手尤其是云打包和真机运行这两个能力省掉了大量环境配置时间。当然 uni-app 也不是没有缺点后面我会专门讲它“太方便”背后的坑比如某些 API 在小程序端和 H5 端行为不一致会让你在联调时怀疑人生。1.3 关于 HBuilderX 和项目搭建的冷知识很多人用 uni-app 会直接打开 HBuilderX 创建项目我也这么干了。但建议不要只在 HBuilderX 里点运行要把它理解成一个编译工具链真正负责业务开发时项目结构和普通 Vite Vue3 项目非常像可以用命令行创建用习惯的编辑器写代码HBuilderX 只用来做真机调试和云打包。我还碰到过一个细节同一个 uni-app 项目用 CLI 创建和用 HBuilderX 创建目录结构有差异依赖管理方式也不同。如果一开始团队多人协作建议统一用 CLI 版本并用 npm scripts 管理构建不要一边 HBuilderX 内置依赖、一边 npm 装依赖否则很容易出现“我本地能跑你本地报错”的灵异事件。2. 短剧不是视频工具而是一个内容分发系统2.1 微剧用户的真实行为路径在做微剧小程序前我对短剧的理解是“把视频做出来放上去播就行了”。真正跑起来才发现短剧产品核心不在播放器而在内容分发和用户激励链路。用户进入一个小程序后典型路径是这样的先看到一部剧的封面和标题点击进入详情页看到“第1集免费试看”播放一集后弹出“解锁下一集”的提示用户要么看广告解锁要么分享给好友解锁要么直接支付买全集。这个路径中视频播放只是载体真正驱动日活的是“下一集什么时候能看”和“怎么解锁更划算”。把这条路径想清楚技术架构才能做对。当时我们技术团队的第一版需求文档本质上不是“做一个视频列表”而是“做一个围绕内容分销的闭环系统”。首页推荐、搜索、分类、详情、播放器、支付、广告、邀请裂变这些模块都服务于同一个目标让用户进入小程序后尽可能多试看并通过分享或解锁行为把新用户带进来。2.2 把“日活破万”拆解成可执行指标“日活破万”听起来很吓人拆开就清晰了。我们当时的测算公式很简单日活 小程序自然访问量 分享回流用户 渠道投放进入用户其中分享回流用户占了很大比重。我们的解锁机制设定了一集剧需要 3 个好友助力也就是说一个用户想连续解锁两集至少产生 6 次页面访问。这意味着每进入一个深度用户小程序就会被动增加不少额外访问。短剧内容天然具备“追更”属性用户为了看下一集非常愿意分享到微信群。更精确地说我们当时的目标不只是日活破万而是“日启动量做到 3 万次到 5 万次”。当分享裂变系数跑起来后一个用户可能带来 2 到 3 次访问所以真正需要的日活可能只有几千人但页面访问量会被反复解锁和回流放大。2.3 七天内必须砍掉的功能边界做一款产品的第一天最容易犯的错就是什么都想要。我们当时列了两页纸需求最后砍到只剩这些首页推荐流展示热播剧支持上下滑动切换剧集列表页一部剧的分集标识免费和付费播放页横屏播放、暂停、进度记忆、上下集切换解锁系统广告解锁、分享解锁、支付解锁三种方式分享海报自动生成带二维码的分享图我的页面观看历史、解锁记录、邀请人数砍掉的东西包括社区评论、弹幕、排行直播、消息通知、复杂会员体系、多语言、深色模式。不砍这些一周根本不可能上线。所有被砍的需求都有同一个特征无法直接带动内容分发和用户增长。哪怕它们能提升体验也只能等日活起来后再补。3. 七天上线计划每天到底在干什么3.1 Day 1 到 Day 2工程脚手架、登录态、请求封装前两天理论上做不了太多页面因为基础设施必须扎实。我们的第一件事是搭建仓库、目录结构和基础路由。uni-app 的路由本质上是 pages.json 配置我当时把首页、剧集详情、播放页、我的页面四个核心页面全部在 pages.json 里注册好再写了一套简单的 tabBar 框架确保后面每天只需要往里填充业务代码。登录态是短剧平台最容易被忽略但又最核心的部分。小程序端我们直接用uni.login获取 code发给后端换取 openid 和 session token存到 Storage 里。这里要特别注意微信小程序登录态是存在客户端本地的每次请求必须通过自定义 header 把 token 带上不能依赖小程序默认携带否则后端无法识别用户。请求封装是第一优先级我写了一个简单的request.js把uni.request包成 Promise统一处理错误码、登录过期、loading 状态。说实话这个文件看着简单但后面所有接口都靠它一旦一开始写得糙后面每做一个页面都要补漏洞非常浪费时间。核心代码大概是这样// utils/request.js const BASE_URL https://api.example.com/v1 export function request({ url, method GET, data {}, loading false }) { const token uni.getStorageSync(token) if (loading) uni.showLoading({ title: 加载中, mask: true }) return new Promise((resolve, reject) { uni.request({ url: ${BASE_URL}${url}, method, data, header: { Authorization: Bearer ${token}, Content-Type: application/json }, success: (res) { if (loading) uni.hideLoading() const body res.data || {} if (res.statusCode 401) { // token 过期跳登录页重新静默登录 uni.navigateTo({ url: /pages/login/index }) reject(body) return } if (body.code 0) { resolve(body.data) } else { uni.showToast({ title: body.message || 请求失败, icon: none }) reject(body) } }, fail: (err) { if (loading) uni.hideLoading() uni.showToast({ title: 网络异常, icon: none }) reject(err) } }) }) }3.2 Day 3 到 Day 4首页、剧集详情、播放页主流程第三天开始写页面我是倒着写的先写播放页再写详情页最后写首页。为什么是倒着来因为播放页是团队心里最没底的部分如果第三天发现播放器有硬伤还有时间改方案如果最后两天才发现那就等着上线捅娄子。播放页直接用了组件自带的video组件没有引第三方插件。最开始考虑过引入一个付费播放器插件后来发现短剧场景下我们需要的功能非常基础播放、暂停、全屏、播放下一个、记录进度。原生video组件完全能撑住而且更稳定。用第三方插件的好处是 UI 好看坏处是真机上偶尔会出现手势和播放下集冲突的 bug排查成本比省下来的 UI 成本高太多。首页采用列表流和抖音形态接近用户往下滑就是切换到下一部剧每部剧露出封面、标题、简介和“第几集解锁到第几集”的状态。这里遇到一个比较大的坑uni-app 的页面滚动和video组件在同屏时容易出现层级问题尤其是 cover-view 覆盖。实际验证后我们放弃了让视频在首页直接小窗播放只放封面静态图和“立即观看”按钮点击后跳到独立播放页这样把 video 组件的层级问题挡在了核心路径之外。这个决定当时看起来像“功能缩水”实际上对稳定性和上速度帮助巨大。3.3 Day 5分享海报、解锁闭环、数据上报到第五天主播放路径已经能跑通开始做增长相关功能。微剧小程序最重要的增长功能就是分享解锁而分享解锁的载体是海报。海报不能直接用后端生成图片再返给前端那样每次生成都要请求接口并发一高很容易崩。我们采用前端 canvas 绘制方案先拿封面图、标题、二维码图片地址利用 canvas 合成一张带小程序码的海报再通过uni.saveImageToPhotosAlbum保存到用户相册。这里有个近乎必踩的坑canvas 绘制本地图片没问题但绘制网络图片必须先下载到本地否则部分真机绘制会失败。我们封装了一个downloadImage的 Promise保证所有图片都变成本地缓存路径后再开始绘制。解锁闭环的逻辑很关键伪代码如下// 点击“解锁下一集” async function handleUnlock(dramaId, episodeId) { const status await getEpisodeLockStatus({ episodeId }) if (status.unlocked) { // 已经解锁直接播放 playEpisode(episodeId) } else { uni.showActionSheet({ itemList: [看广告解锁, 邀请好友解锁, 购买全集], success: (res) { if (res.tapIndex 0) { // 调起广告组件客户端展示广告 showRewardedVideo(episodeId) } else if (res.tapIndex 1) { // 调起分享面板分享后解锁 openSharePanel(episodeId) } else { // 跳转支付页面 uni.navigateTo({ url: /pages/pay/index?dramaId${dramaId} }) } } }) } }广告解锁用的是微信小程序官方的激励视频广告组件。这里提醒一句激励视频广告需要自己的小程序有广告位 ID而且广告填充率不一定 100%必须处理后端调整逻辑。我们当时一天能靠广告解锁几千次但有一个很现实的现象很多用户点“看广告解锁”后广告没加载出来直接卡死所以我的代码里加了超时兜底如果广告组件加载超过 5 秒自动降级成普通提示让用户换成分享解锁。3.4 Day 6 到 Day 7提审、真机回归、灰度发布第六天开始打磨提审素材第七天提交审核。小程序的审核比想象的更看中“功能可用性”和“内容合规性”。我们因为短剧类目问题提前准备了版权授权证明和相关资质避免在审核环节被卡。真机回归一定不能只测开发者工具。微信开发者工具模拟器里很多行为是正常的一到真机就出问题比如video组件全屏方向控制、相册权限弹窗顺序、分享回调是否触发等。我们当时用一个很笨但有效的方法拉了一个十几人的核心用户群在群里发体验版二维码让他们在不同机型上跑主流程第二天汇报问题。灰度发布我们用的是微信公众平台的“分阶段发布”功能不用一次性全量先放 10% 用户观察错误日志和崩溃率。这个习惯救了我们一次后面会单独讲。4. 播放器、解锁和签名整个项目的技术心脏4.1 播放器选型和 video 组件的坑要做短剧播放器就是心脏。我们选型没有任何花样直接用video组件。在 uni-app 里写 video最需要注意的是组件和页面层级的兼容问题。在同一页面里如果既有滚动列表又有 video很容易出现 video 浮到最上层、把其他弹窗和按钮盖住的 bug。短剧播放页相对干净只有一个视频所以没有这个烦恼。但如果未来你想做首页沉浸式滑动播放就一定要考虑cover-view和页面内弹层的遮蔽问题一般的view在 iOS 上盖不住 video必须用cover-view。播放器实现里uni.createVideoContext是必用的。需要在页面加载完成后创建实例否则play()调用会失效。我们同样遇到了 iOS 真机上首次播放不自动播放的问题原因是视频需要用户手势才能带声音播放。解决方案首次播放时展示一个播放按钮封面用户点击后再调videoCtx.play()同时把autoplay设成 false。这个交互看着多了一步但在 iOS 上比死活自动播要稳得多。4.2 进度上报与断点续播短剧用户很可能看到一半切走过几个小时再回来看所以断点续播很重要。我们的做法是监听timeupdate事件但因为timeupdate触发频率很高不能每次都上报必须节流。// 播放页 onTimeUpdate let lastReportTime 0 function onTimeUpdate(e) { const current e.detail.currentTime const duration e.detail.duration // 每 5 秒上报一次进度 if (current - lastReportTime 5 || current duration - 1) { lastReportTime current reportProgress({ dramaId: currentDramaId, episodeId: currentEpisodeId, currentTime: Math.floor(current), duration: Math.floor(duration) }) } }断点续播这里有大学问什么时候算“看完一集”不能等ended事件因为很多用户是拖进度条到最后几秒或者看到结尾前就切走了。我们的判定是播放进度达到 90% 以上算“已完成”后端会记录到一个观看进度表里。这样首页再推荐时能优先推没看完的剧而不是已看完的对留存会有帮助。4.3 防盗链与签名 URL短剧内容一旦被盗链CDN 费用会失控更严重的是内容会被别人拿去二次分发。我们做了两层保护第一层是 CDN 的 Referer 防盗链只允许小程序域名请求第二层是后端签名 URL播放地址带过期时间和签名参数过期后自动失效。签名的逻辑不复杂但细节多。后端用视频路径、过期时间戳和一个密钥拼接后做 MD5再拼成完整播放地址。前端每次播放前向接口请求这个地址不要把所有播放地址一次性下发。为什么要这样做因为一次性下发 80 集地址等于把内容仓库给用户打开了会有抓链接和整剧下载的风险。我建议所有做短剧的朋友都能把播放地址动态化哪怕每次进入播放页都重新请求一次体验损失也远小于被盗链的风险。4.4 解锁记录和后端对账前端的解锁状态只用于展示最终能不能播必须由后端控制。用户点“解锁”后广告回调、分享回调、支付回调都会把解锁指令发给后端后端在数据库里写一条解锁记录。播放时后端还要验证播放凭证前端拿到的播放地址必须携带这次解锁的 token否则拒绝播放。初期我们差点做漏了“用户重复付费”的保护。微信支付回调偶尔会出现延迟用户付完款页面还没跳转又点了两次支付结果后端生成了两笔订单。后来加了一层幂等校验同一个剧集 ID 同一个用户 ID 在 30 秒内只能生成一个待支付订单重复请求直接返回原订单号才把这个 bug 堵住。5. 日活破万前夜一次流量脉冲带来的架构压力5.1 流量是怎么突然涨起来的上线第五天我们在某个渠道投放了一条短剧切片视频底部直接挂小程序链接。当晚八点用户点击量突然起来小程序后台的访问次数曲线直接从平缓变成接近垂直拉升日活很快破了万。这个场景听起来很爽实际上那两小时我是在紧张中度过的。因为访问量和真正的有效播放量之间有很大差距如果首页接口扛不住用户看到的就是页面空白或加载中整晚投放就等于白费。5.2 流量进来后先崩的是什么第一次脉冲时最先崩的不是播放器而是首页推荐接口。首页接口原本是查询剧集列表包含每部剧的当前热度、更新集数、封面图地址等信息。后端服务压力一大数据库连接被占满接口响应时间从 200ms 飙升到 3 秒。另外一个小程序特有的性能问题用户下拉列表时我们一次请求 10 部剧图片都是原图 URL首页图片多达 10 张 2K 以上的封面部分用户手机内存不够直接白屏或者卡顿。流量起来后图片加载失败率非常高。5.3 事后优化缓存、静态化、图片瘦身流量脉冲之后的优化优先级非常明确首页推荐数据加了 Redis 缓存缓存时间 30 秒榜单变动可以接受延迟但接口必须保证稳定。剧集详情页、播放页的配置信息全部静态化简单来说就是尽量不查数据库直接返回预生成的 JSON 格式数据。封面图全部改造为 CDN 图片并在 URL 上加压缩参数把 2K 图压成 750px 宽。这个优化后首屏加载速度提升非常明显。播放页做预加载当前视频播放到 80% 时提前请求下一集的播放地址用户点击“下一集”时就能立刻开始播放少一次等待缓冲。这些优化不是第一版就要全做的而是流量信号出现后快速响应。这也是一周上线的核心思想先用最小系统上线再根据实际访问情况补性能。如果一开始就搞微服务和一堆中间件七天肯定交付不了。6. 这一周我最顺手的调试手段工具、日志和抓包6.1 开发者工具 Network 面板和真机调试现在很多教程都在讲高大上的性能分析但真正解决日常问题最快的手段可能只是小程序开发者工具里的 Network 面板和 Console 面板。我习惯把所有接口都打印出耗时在小程序开发者工具的控制台里看所有请求的发起顺序和返回时间。首页卡顿的时候我发现真正的问题不是接口慢而是首页同时发起了 14 个请求有些是图片预加载有些是广告拉取。通过 Network 面板把无用的请求停掉页面卡顿直接缓解根本不需要动后端。真机调试的核心价值是排查“开发者工具里没有、真机上才有”的问题。我们遇到最典型的就是iOS 分享回调不触发、某些安卓机视频无法自动播放、相册权限拒绝后没有任何提示。这些必须真机重现不然很难想到。6.2 用代理工具定位自己后端的响应问题“抓包”这个词在小程序圈子里经常被误以为是用来搞别人接口的实际上对我而言抓包是一种最基本的联调手段对象一定得是自己能控制的服务端。开发小程序时最烦的就是后端接口返回的数据字段和前端约定不一致。比如后端返回isLocked前端代码写成了is_locked数据就一直不对。这种问题看代码很难看出来用代理工具把请求响应打开发现字段名写错了马上就能修正。但我要强调这种做法只能用于你自己开发并拥有授权的小程序调试自己的接口。任何试图绕过别人小程序安全机制的行为既踩法律红线也没有任何技术价值。6.3 日志规范把埋点当核心功能做刚上线的项目最怕的就是线上出了问题但查不到原因。我们在开发第四天就把埋点体系加进去了虽然很简陋但每个关键行为都有记录进入首页、点击剧集、播放开始、播放 30 秒、播放完成、广告点击、分享发起、支付成功。埋点直接上报到后端接口后端记录到一张大表里。日活破万之后这张表每天会有几十万条记录查询要加索引否则很容易拖垮业务库。等第一版跑通后可以再考虑接入更专业的统计工具但在前面七天一个简单的日志接口可能就是救命稻草。7. 复盘日活破万一半靠架构克制一半靠内容分发7.1 技术并不酷但它必须可靠这个项目后期有不少人问我用什么高性能框架用了什么炫酷的架构是否需要引入微前端、是否需要自研播放器、是否需要上容器。我自己的答案是在一周上线、日活从零跑到破万的背景下越朴实的技术越可靠。uni-app 已经很完整地帮我们处理了多端差异我做的只是在它上面做减法少用插件、少做复杂的交互动画、尽量不碰系统底层能力所有精力都放在“用户能不能顺利看完一集”这件事上。这套逻辑听起来老土但短剧这类产品的特性是页面可以丑一点卡片可以简单一点但视频必须点开就能看解锁必须顺畅分享必须能完成一旦在关键路径上卡壳用户流失速度比流量进来的速度还快。7.2 真正撑起日活的三个产品机制复盘时我们总结了三个最核心的增长动作没有一个是技术上的花活分享解锁用户为解锁下一集而主动分享带来大量免费流量每 30 秒一个剧情钩子短剧内容本身具备极强的连续性用户一旦看到高潮部分就停不下来小程序码和海报的传播属性分享图做好看一点用户转发的意愿会明显更高技术只是把这三件事稳定地实现出来真正的日活引擎在产品和内容这也是我想提醒所有开发者的不要迷信某个框架或者某个工具能帮你做出爆款它能帮你的是把想法稳定落地。7.3 下一步想做的事和当前的不足第一版上线之后我们陆陆续续在补之前砍掉的功能比如合理的关键词搜索优化、更完整的会员体系、用户观看历史跨设备同步、以及通过 H5 形态把内容分发到更多外部场景。同时也在继续优化后端查询性能和播放器稳定性。说实话微剧这条赛道的护城河不在前端的某个动画效果而在内容库的丰富度和分发效率。技术团队能做的是用 uni-app 快速覆盖更多端让同一批内容在更多入口触达用户。最后分享一个这几天踩坑后自己在项目里坚持的习惯无论项目多急代码里都要留下可观测的日志尤其是播放开始、解锁成功、支付回调这类关键节点。日活破万的时候第一个晚上你的技术团队可能根本来不及看用户反馈全靠日志判断哪里出了问题。这个习惯比任何框架选型都管用。
