简介这是一套面向短剧与微短剧运营场景的完整源码方案适合中小型内容团队、创业者及开发者快速搭建可上线的短剧平台。方案覆盖微信小程序、APP、公众号多端版本并集成媒资管理、虚拟支付、微短剧播放等核心模块同时提供批量导入、多视频格式支持、SaaS多开、分销商分销、卡密兑换、分享海报、自动切换与小程序流量主等运营能力可满足从内容上架到变现的完整链路需求。资源包共471个文件以251个js与134个vue构成前后端主体逻辑辅以48个png界面素材、16个scss样式、6个json配置及少量wxs、nvue、ts等文件压缩包约3.57MB结构紧凑便于二次开发。目前已有274人学习下载适合希望低成本切入短剧赛道、快速验证运营模式的读者参考与复用。1. 一套代码撑起小程序、APP、公众号短剧可运营版本到底在解决什么去年帮一个做短剧的团队做技术选型他们最头疼的不是内容而是「同一部剧要在三个地方上架」——微信小程序里用户刷到第 8 集要付费解锁APP 里用户想离线缓存公众号里用户点进来只想看个切片。三个端三套后台运营改一次价格要登录三个系统数据还各算各的。这就是「短剧微短剧可运营版本」要解决的核心问题用一套后端、一套媒资、一套订单体系同时支撑微信小程序、APP、公众号三个前端入口并且把虚拟支付、媒资管理、分集解锁这些短剧特有的模块做成可配置、可运营的能力而不是写死在代码里。适合谁看如果你手里有一个短剧内容库想快速搭一套能收钱、能管内容、能看数据的系统或者你正在评估「自研还是买现成」这篇会从架构分层讲到具体模块的参数怎么设、坑在哪。不适合纯前端只想改样式的读者因为重点在运营链路和支付闭环。2. 三端复用怎么落地从媒资管理到虚拟支付的架构拆解2.1 为什么短剧系统必须把媒资管理独立成服务短剧和普通视频平台最大的区别是「集数多、单集短、更新快」。一部 80 集的短剧每集 2 分钟如果每集都当独立视频上传媒资库很快就乱。常见做法是把媒资管理拆成三层剧集元数据剧名、封面、简介、总集数、更新状态、分集索引第几集、时长、免费/付费标记、试看秒数、实际存储对象转码后的 m3u8 或 mp4 地址。微信小程序的媒资管理模块通常只暴露前两层给运营后台第三层由转码服务回写。我一般会建一张media_episode表关键字段这样设CREATE TABLE media_episode ( id BIGINT PRIMARY KEY AUTO_INCREMENT, drama_id BIGINT NOT NULL COMMENT 所属剧集ID, episode_no INT NOT NULL COMMENT 第几集从1开始, title VARCHAR(128) DEFAULT COMMENT 分集标题可空, duration_sec INT DEFAULT 0 COMMENT 时长秒数, is_free TINYINT DEFAULT 0 COMMENT 0付费 1免费, trial_sec INT DEFAULT 0 COMMENT 试看秒数0表示不可试看, play_url VARCHAR(512) DEFAULT COMMENT 播放地址转码后回写, status TINYINT DEFAULT 0 COMMENT 0待转码 1可播放 2下架, created_at DATETIME DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_drama_ep (drama_id, episode_no) ) COMMENT短剧分集媒资表;is_free和trial_sec是短剧运营的核心开关。免费集直接放行付费集如果trial_sec 0前端先播试看片段到点弹付费墙。status控制上下架避免转码没完成就被用户点到。注意uk_drama_ep唯一索引防止同一剧集出现两个「第 3 集」这是运营批量导入时最容易翻车的地方。2.2 微信小程序、APP、公众号三端如何共用一套接口三端共用的前提是「接口层不假设客户端类型」。我一般会在请求头里带一个X-Client-Type: mp | app | official_account后端只在一个地方做差异化登录态校验和支付参数组装。其余像剧集列表、分集详情、订单创建全部走同一套 REST 接口。以分集播放接口为例三端请求同一个/api/episode/play后端根据X-Client-Type决定返回什么# Flask 示例三端统一播放鉴权 app.route(/api/episode/play) def episode_play(): episode_id request.args.get(episode_id, typeint) client request.headers.get(X-Client-Type, mp) user get_user_from_token(request) # 三端 token 统一解析 ep db.query_episode(episode_id) if not ep or ep.status ! 1: return jsonify(code404, msg剧集不可播放) # 免费集直接返回完整地址 if ep.is_free: return jsonify(code0, data{url: ep.play_url, trial: 0}) # 付费集检查是否已解锁 unlocked db.check_unlock(user.id, ep.drama_id, ep.episode_no) if unlocked: return jsonify(code0, data{url: ep.play_url, trial: 0}) # 未解锁返回试看片段trial 秒数由运营配置 return jsonify(code0, data{ url: ep.play_url, trial: ep.trial_sec, need_pay: True, pay_channel: wechat_mp if client mp else app_pay })逻辑说明先判空和状态再判免费再查解锁记录最后才返回试看。pay_channel根据客户端类型返回不同值小程序走微信虚拟支付APP 走应用内支付公众号走 JSAPI。参数上trial_sec建议设 1530 秒太短用户没感觉太长等于白送。2.3 虚拟支付在小程序里的接入要点微信小程序的虚拟支付现在叫「小程序虚拟支付」和普通微信支付是两套东西。短剧属于虚拟内容必须走虚拟支付接口否则审核过不了。接入时注意三点一是需要在app.json里声明requiredPrivateInfos相关权限二是支付前必须调用wx.requestVirtualPayment而不是wx.requestPayment三是道具/内容 ID 要在微信后台提前配置。// 小程序端发起虚拟支付 wx.requestVirtualPayment({ signData: res.signData, // 后端返回的签名串 paySig: res.paySig, // 支付签名 signature: res.signature, // 用户签名 mode: short_series, // 短剧场景固定值 success: () { // 支付成功后刷新解锁状态 this.refreshEpisode(); }, fail: (err) { console.error(虚拟支付失败, err); } });signData、paySig、signature三个参数必须由后端生成前端只负责透传。mode填short_series是短剧类目的固定要求。常见错误是拿普通支付的参数来调虚拟支付会直接报10002参数错误。3. 运营后台怎么配剧集上架、价格策略与分集解锁的实操3.1 剧集上架的最小操作流程运营后台不需要花哨但必须让运营能独立完成「新建剧集 → 上传分集 → 设免费集 → 设价格 → 上架」这条链路。我一般把上架拆成五步每步都有状态校验新建剧集填剧名、封面、简介、总集数状态为「草稿」。批量上传分集视频系统自动转码转码完成回写play_url。设置免费集范围比如前 5 集免费第 6 集开始付费。设置解锁价格支持「单集解锁」和「整剧解锁」两种模式。全部检查无误后点「上架」status从 0 变 1。这里有个血泪经验免费集不要设太多。我见过一个团队前 20 集免费结果用户看完 20 集直接走人付费转化率不到 1%。一般前 35 集免费第 6 集开始试看 15 秒转化率能到 8%12%。3.2 价格策略的三种模式与参数配置短剧的付费模式比长视频灵活常见三种模式适用场景关键参数注意点单集解锁用户只想看某几集单集价格、解锁有效期有效期建议永久否则客诉多整剧解锁用户想一次看完整剧价格、是否含未更新集未更新集要标记「待更新」会员订阅高频追剧用户月费、可看剧集范围要和单集解锁做互斥判断配置时我一般会在drama表加三个字段unlock_mode1单集 2整剧 3会员、single_price分、whole_price分。价格单位用「分」避免浮点误差。整剧解锁要特别注意如果用户买了整剧后续更新的集数应该自动解锁否则用户会觉得被坑。3.3 分集解锁的数据库设计与查询优化解锁记录表是短剧系统里增长最快的表。一个日活 1 万的小程序一个月能产生几十万条解锁记录。设计不好查询会拖垮整个播放接口。CREATE TABLE user_unlock ( id BIGINT PRIMARY KEY AUTO_INCREMENT, user_id BIGINT NOT NULL, drama_id BIGINT NOT NULL, episode_no INT DEFAULT 0 COMMENT 0表示整剧解锁, unlock_type TINYINT DEFAULT 1 COMMENT 1单集 2整剧 3会员, order_id BIGINT DEFAULT 0, created_at DATETIME DEFAULT CURRENT_TIMESTAMP, KEY idx_user_drama (user_id, drama_id), KEY idx_order (order_id) ) COMMENT用户解锁记录;查询时先查episode_no 0的整剧解锁再查具体集数。idx_user_drama这个联合索引是关键没有它每次播放都要全表扫。另外建议加一层 Redis 缓存key 用unlock:{user_id}:{drama_id}value 存已解锁的集数集合过期时间设 10 分钟。这样 90% 的播放请求不用查库。4. 避坑与排查短剧系统上线后最容易翻车的 5 个点4.1 虚拟支付报 10002 参数错误现象小程序调wx.requestVirtualPayment直接失败错误码 10002。原因九成是signData里的字段和微信后台配置不一致比如道具 ID 没配、价格单位写成了元而不是分、mode没填short_series。解决先核对微信后台「虚拟支付」里的道具列表确保product_id完全一致再检查后端签名时用的价格是不是「分」最后确认mode字段。三个都对还报错就用微信开发者工具的「虚拟支付调试」面板看原始请求。4.2 公众号里点播放没反应现象公众号菜单点进短剧页面点播放按钮无响应小程序里正常。原因公众号 H5 里调用了小程序才有的wx.requestVirtualPayment或者视频地址是wxfile://协议。解决公众号端必须走 JSAPI 支付播放地址用 https 的 m3u8。判断客户端类型后走不同支付分支不要一套代码硬套三端。4.3 分集列表加载更多时重复现象用户上滑加载更多第 2 页和第 1 页出现相同剧集。原因分页查询没有稳定排序LIMIT offset, size在数据插入时偏移错乱。解决改用游标分页用episode_no last_episode_no代替offset。或者至少加ORDER BY episode_no ASC保证顺序稳定。4.4 转码没完成用户就能点播放现象运营刚上传第 10 集用户立刻就能在列表里看到并点播放结果 404。原因上传后直接写入了media_episode且status默认给了 1。解决上传时status设 0转码回调成功后再改成 1。前端列表接口只返回status 1的分集。这个坑我踩过两次后来直接在数据库层加默认值 0谁也别想绕过。4.5 整剧解锁后新集数没自动解锁现象用户买了整剧第二天更新了 5 集用户点进去还是提示付费。原因解锁判断只查了episode_no精确匹配没处理episode_no 0的整剧记录。解决播放鉴权时先查episode_no 0 AND unlock_type 2命中则直接放行。同时更新集数时不需要额外写解锁记录查询逻辑覆盖即可。5. 从能跑到能运营一套短剧系统的验证清单与迭代习惯系统搭完只是开始能不能运营起来要看几个硬指标。我一般会在上线前跑一遍验证清单三端登录是否都通、免费集和付费集边界是否正确、虚拟支付能否走通一笔真实订单、整剧解锁后更新集是否自动放行、后台改价后前端是否实时生效。这五条任何一条不过都不算可运营版本。验证支付闭环时我习惯用一笔 1 分钱的测试订单走全流程从下单、支付、回调、写解锁记录到播放鉴权每一步打日志。很多团队只测到支付成功就结束了结果回调没处理用户付了钱还是看不了客诉直接爆炸。# 用 curl 模拟支付回调验证解锁逻辑 curl -X POST https://your-domain.com/api/pay/callback \ -H Content-Type: application/json \ -d {order_id: 123, status: success, sign: test_sign} # 然后查解锁记录 curl https://your-domain.com/api/debug/unlock?user_id1drama_id100回调接口一定要做幂等同一笔订单重复回调不能重复写解锁记录。我一般用order_id做唯一索引插入冲突就忽略。迭代上短剧系统的运营节奏很快今天加一个「限时免费」明天改一个「整剧折扣」。我的习惯是把所有运营可变的参数都抽到配置表而不是写死在代码里。价格、免费集数、试看秒数、解锁模式全部走drama_config表运营在后台改完立即生效不用发版。这样迭代速度能快三倍也少了很多「改个价格还要等开发排期」的扯皮。最后说一个我自己的教训早期我总想把功能做全结果三个月没上线。后来学乖了第一版只做「小程序 虚拟支付 分集解锁」这条最短闭环跑通收钱之后再补 APP 和公众号。短剧这个赛道快比全重要。希望帮到你。本文还有配套的精品资源点击获取