金融隐士本人做了几年的后端，这两年短剧赛道有多火大家也都看在眼里。从去年开始陆续接手了几个短剧小程序项目，最常被问到的就是“能不能用 Java 写短剧小程序”。这里先给个结论：抖音小程序前端本身跑的是 JavaScript 那一套，但整个业务后端、内容管理、支付对账、数据报表，完全可以用 Java 扛下来，而且 Spring Boot 这套生态在短剧这种重内容、重交易、重运营的场景里反而非常合适。这篇文章就从架构设计、后端实现、小程序端对接、支付与防盗链、上线避坑这几个维度，完整分享我基于 Java 搭建抖音短剧小程序的实操过程。
之所以专门拿“抖音短剧小程序”出来写，是因为它和普通的小程序商城有本质区别：内容即商品、时序即交易。用户不是来逛的，是来“追剧”的。第10集卡住要解锁，这一下就是转化关键点。所以整个系统设计都得围绕“内容分发 + 付费解锁 + 防搬运 + 数据回收”来展开。下面我按项目从零到上线的推进顺序，把每一步的关键决策和踩过的坑都铺开讲。
1. 项目整体设计与技术选型思路
1.1 短剧小程序的核心业务链路
先想清楚短剧小程序到底是做什么的。用户刷抖音时看到一条短剧切片，被剧情钩子吸引，点击跳转到小程序，开始从第1集看到第8集，第9集开始需要看广告或付费解锁，一直追到大结局。这个过程中涉及的核心环节有：短剧内容管理、用户观看进度、剧集解锁逻辑、广告或支付转化、观看数据回传。把这几个环节拆开，系统的技术边界就清楚了。
从这个链路能推导出一个关键设计原则：小程序的每个页面，都对应一组后端接口；用户每一次点击解锁，都是一次服务端校验。 我最早做过一版把解锁状态全放前端缓存的方案，结果上线第一天就被抓到漏洞——用户改一下本地标志位就能免费看完全集。后来所有剧集播放前必须向后端拉取播放凭证，服务端校验用户是否有权观看该集，这才把问题堵住。
1.2 为什么用 Java 技术栈来写短剧小程序
很多团队做小程序第一反应是用 Node.js 或者直接用云开发，但短剧项目有它自己的特殊性。一是短剧平台上新节奏极快，一部剧几十集，每集几百MB到1GB不等，内容管理和转码调度需要一套健壮的后台任务系统，Java 的 Spring Boot 加 XXL-Job 在定时任务和分布式调度上非常成熟。二是支付和分账逻辑复杂，抖音短剧小程序经常涉及用户付费、平台抽成、版权方分账，这些涉及到精确金额计算的场景，Java 的 BigDecimal 和成熟的支付对接方案比脚本语言更稳妥。
说实话，在面试和实际招聘里，Java 后端候选人数量也远多于其他语言，招人补人容易。团队里如果有人问“Java 能不能做小程序后端”，我的回答是：小程序前端没法用 Java 写，但前端的每一笔数据、每一次登录、每一笔支付，全都要经过 Java 后端。后端才是这个项目的真正心脏。
1.3 整体架构设计：从抖音入口到 Java 后端
我采用的架构是标准的“抖音小程序端 + Java 后端 + 对象存储 + CDN”四层结构。抖音小程序端负责展示和用户交互，所有业务请求都通过 HTTPS 调 Java 后端接口；后端负责用户登录态校验、剧集权限校验、订单和支付处理；视频文件本身存在对象存储上，通过 CDN 分发。
这里特别说明一下视频存储的选择。短剧视频体积大、并发下载高，如果直接放在应用服务器上，带宽和磁盘都是灾难。我通常用阿里云 OSS 或腾讯云 COS 存视频文件，配合 CDN 做加速。Java 后端只负责生成带签名的播放地址，小程序拿这个地址去 CDN 拉流。
为什么播放地址要由后端生成而不是直接暴露永久地址？这涉及防盗链。如果没有签名机制，视频地址被拿去站外随便贴，流量费用和版权风险都不可控。后面我会专门讲签名防盗链的实现细节。
1.4 开发环境与核心依赖清单
先列一下这个项目的基础环境，方便你搭建时对照。我用的是 JDK 17 + Spring Boot 3.2 + MyBatis-Plus 3.5 + MySQL 8.0 + Redis 7，抖音开发者工具用官方最新稳定版。Spring Boot 3 相比 2.x 在性能、可观测性上有明显提升，而且 Jakarta EE 命名空间已经是主流，新项目没必要再守着旧版本。
核心依赖包括：
xml复制<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-data-redis</artifactId>
</dependency>
<dependency>
<groupId>com.baomidou</groupId>
<artifactId>mybatis-plus-boot-starter</artifactId>
<version>3.5.5</version>
</dependency>
<dependency>
<groupId>mysql</groupId>
<artifactId>mysql-connector-java</artifactId>
<version>8.0.33</version>
</dependency>
<dependency>
<groupId>com.auth0</groupId>
<artifactId>java-jwt</artifactId>
<version>4.4.0</version>
</dependency>
<dependency>
<groupId>cn.hutool</groupId>
<artifactId>hutool-all</artifactId>
<version>5.8.25</version>
</dependency>
有人会问为什么不用 Spring Cloud Alibaba，短剧项目初期真没必要。单机 Spring Boot + Redis 足够扛住初期流量，等用户量上来再按需拆服务。一上来就微服务，只是给自己增加运维负担。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 后端核心模块与数据模型设计
2.1 数据库表设计：从短剧到订单
短剧小程序的数据模型不复杂，但每张表都有讲究。我梳理一下最核心的几张表，你用 Java 后端开发时可以直接参考。
首先是短剧表，短视频平台和长视频平台不一样，一部短剧通常有几十到上百集。剧集表必须有 episode_number 排序字段和 duration 时长字段。短剧的解锁方式通常是“前N集免费，后续单集解锁或整剧买断”，所以剧集表里要有 is_free 字段。还有一个容易被忽略的点：cover_url 封面图。抖音小程序的信息流卡片展示非常依赖封面，封面质量的优劣直接影响点击率。
用户表建议直接用抖音 openid 作为唯一业务标识，自增主键只是为了内部关联。用户表要有 last_login_time，方便后续做用户活跃度分析。
用户观看记录表是短剧小程序最重要的数据资产之一。它记录每个用户看到哪部剧的哪一集、看到几分几秒。这个表有两个用途：一是用户下次进入小程序时，能从上次位置继续播放；二是运营人员能看到“第几集流失率最高”，从而调整免费集数和付费点。
订单表就是常规的电商订单结构，但多了 drama_id 和 episode_number 两个字段，用来标识用户买的是哪部剧的哪一集或者整部剧。
建表时的 engine=InnoDB 和 utf8mb4 是我的固定习惯，不用多想。MySQL 8.0 默认字符集就是 utf8mb4，可以完整支持 emoji 表情，短剧评论区会用到。
2.2 用户登录与 JWT 会话设计
抖音短剧小程序和其他小程序一样，不能像传统网站那样用用户名密码登录。用户在小程序端通过 tt.login() 拿到一个临时 code，后端拿这个 code 去抖音开放平台换 openid 和 session_key。openid 是用户在抖音体系内的唯一标识，session_key 用于解密手机号等敏感信息。
这里要强调一个安全点：openid 不能直接暴露给前端作为身份凭证。 拿到 openid 后，后端要自己生成一个 token，我用的是 JWT。JWT 里只放 userId 和 openid，用对称密钥签名，有效期设 7 天。用户后续每次请求都带着 token，后端通过拦截器解析 token 得到用户身份。
有些项目为了省事，直接把 openid 当 token 用，这是很大的安全隐患。openid 泄露后别人可以伪造用户身份调用所有接口。JWT 虽然也不是绝对安全，但至少签名机制能防止伪造。
登录接口的核心逻辑是：
java复制@PostMapping("/api/auth/login")
public Result login(@RequestBody LoginRequest request) {
// 1. 用 code 换 openid
String openid = douyinService.code2Session(request.getCode());
// 2. 查用户是否存在，不存在则注册
User user = userService.findByOpenId(openid);
if (user == null) {
user = userService.register(openid);
}
// 3. 生成 JWT
String token = jwtUtil.generateToken(user.getId(), openid);
return Result.success(token);
}
2.3 剧集解锁逻辑与播放凭证设计
这是整个系统里业务最核心、最容易出问题的地方。它的核心诉求是：用户只能看他有权看的剧集。所谓“有权”分三种情况：免费集、已解锁集、整剧已购。代码逻辑上，每次用户请求播放地址时，后端都要做一次鉴权。
我的做法是设计一个 getPlayInfo 接口，接收 dramaId 和 episodeNumber，后端先查剧集信息，再查用户是否有权观看，全部通过后才生成一个带签名的临时播放 URL 返回给小程序。
播放凭证的签名机制是这样的：后端用 AccessKey 对“视频路径 + 过期时间”做 HMAC-SHA1，生成一个签名串，拼在 URL 后面。CDN 层验证签名，过期了自动拒绝访问。这种方式的好处是 URL 有时效性，就算被转发出去，几分钟后也自然失效。
不要用简单的 UUID 作为播放 token，UUID 只能防“乱猜”，防不了“转发”。有经验的用户截获一个有效链接后可以反复播放。一定要用带过期时间的签名 URL。
核心代码如下：
java复制@Service
public class PlayService {
@Autowired
private DramaEpisodeMapper episodeMapper;
@Autowired
private UserUnlockMapper unlockMapper;
public PlayInfoVO getPlayInfo(Long userId, Long dramaId, Integer episodeNumber) {
DramaEpisode episode = episodeMapper.selectByDramaIdAndNumber(dramaId, episodeNumber);
if (episode == null) {
throw new BizException("剧集不存在");
}
// 免费集直接放行
if (episode.getIsFree()) {
return buildPlayInfo(episode);
}
// 非免费集校验是否已解锁
UserUnlock unlock = unlockMapper.selectByUserIdAndEpisode(userId, episode.getId());
if (unlock == null) {
throw new BizException("该集未解锁");
}
return buildPlayInfo(episode);
}
private PlayInfoVO buildPlayInfo(DramaEpisode episode) {
String signedUrl = vodService.generateSignedUrl(episode.getVideoKey(), 3600);
return new PlayInfoVO(episode.getId(), signedUrl);
}
}
2.4 抖音支付对接与回调处理
短剧小程序最常见的付费方式是单集解锁、整剧解锁、会员三种。我用的是抖音小程序的支付能力。对接抖音支付时，最难的点在回调处理。用户支付成功后，抖音服务器会向你的后端回调接口发送一个通知，你的后端必须正确处理并更新订单状态。
我踩过的坑是：回调接口没有做好幂等，用户支付成功后重复收到回调，导致订单被重复更新、重复解锁。后来我在回调处理逻辑里加了唯一约束校验，同一个订单号只能成功处理一次。
支付回调的核心处理流程是：验签 -> 查订单 -> 更新订单状态 -> 给用户解锁剧集。验签尤其不能省，否则任何人都可以伪造支付回调，让自己的账号免费解锁所有剧集。我在验签上用的是官方 SDK 提供的 RSA2 验签方法，别自己造轮子。
java复制@PostMapping("/api/pay/callback")
public String payCallback(@RequestBody String notifyData) {
// 1. 验签
boolean signValid = douyinPayService.verifySign(notifyData);
if (!signValid) {
return "fail";
}
// 2. 解析通知内容，处理订单
PayNotify notify = douyinPayService.parseNotify(notifyData);
// 3. 幂等处理
boolean firstProcess = orderService.processPaidOrder(notify.getOrderId());
return firstProcess ? "success" : "success";
}
3. 抖音小程序端开发与 Java 后端联调
3.1 抖音开发者工具与工程初始化
抖音小程序用的开发工具叫“抖音开发者工具”，界面和微信开发者工具很像，但 AppID 体系独立。开发者需要先在抖音开放平台注册小程序账号，拿到 AppID，然后下载开发者工具创建项目。
创建项目时有两个框架选择：原生框架和 Taro 等跨端框架。短剧小程序如果只做抖音端，直接用原生框架就行，简单直接。如果后续要同步上微信小程序，建议直接用 Taro 或者 uni-app，一套代码多端发布。我个人的建议是：先别急着跨端，把抖音端跑通跑顺，再考虑多端。
抖音小程序的页面文件后缀和微信小程序略有不同，逻辑层文件是 .js，模板文件是 .ttml，样式文件是 .ttss。如果你写过微信小程序，上手成本基本为零。第一次运行官方模板项目后，熟悉一下目录结构，就可以开始改代码了。
3.2 登录流程在前端的完整实现
前端调用 tt.login() 拿到 code，然后请求 Java 后端登录接口换 token。这个流程只需要在首页启动时执行一次，后续请求都带 token。
javascript复制// pages/index/index.js
const app = getApp();
Page({
onLoad() {
this.login();
},
async login() {
const { code } = await tt.login();
const res = await request({
url: '/api/auth/login',
method: 'POST',
data: { code }
});
tt.setStorageSync('token', res.data.token);
}
});
这里有一个容易被忽略的细节：tt.login() 拿到的 code 是一次性的，而且有效期非常短。如果后端换 openid 失败，需要重新触发 tt.login() 拿新 code。网络超时的时候尤其容易出现这种情况。我在封装请求工具时，专门加了 code 过期自动重新登录的逻辑。
3.3 短剧列表页与播放页对接后端接口
列表页是用户进入小程序后的第一屏，决定了用户会不会继续看下去。这里有几个实用的运营经验：第一屏必须展示热度最高的短剧，热度按“近7天播放量”排序；封面上要叠加“全集”“更新至XX集”这样的角标；列表项要显示免费集数和总集数，降低用户的决策成本。
列表接口很简单，就是一个分页查询：
java复制@GetMapping("/api/drama/list")
public Result pageList(@RequestParam Integer page, @RequestParam Integer pageSize) {
Page<Drama> dramaPage = dramaService.page(new Page<>(page, pageSize));
return Result.success(dramaPage);
}
但千万别小看这个接口。如果列表接口每次都全量查数据库，用户量大一点数据库就扛不住了。我加了 Redis 缓存，首页第一屏的数据直接缓存，五分钟过期，由后台内容更新时主动失效。实测下来接口耗时从平均 120ms 降到了 20ms 以内。
播放页是短剧小程序最核心的页面。抖音小程序的 video 组件使用方式和 H5 的 video 标签很像，把后端返回的带签名播放地址直接塞给 video 组件即可。
html复制<video
src="{{playUrl}}"
controls
autoplay
bindplay="onPlay"
bindended="onEnded"
></video>
每次切换剧集时，前端要先调用 getPlayInfo 接口拿新的播放地址，而不是自己拼 URL。有的开发为了省事，视频地址直接写死在代码里，上线几天就会被刷爆流量。
3.4 用户观看进度上报与断点续播
断点续播是一个提升用户体验的重要功能。用户看了第3集的一半退出小程序，下次进来应该从上次的位置继续播放，而不是重新从第1集开始。
实现方案是：视频播放过程中每隔几秒钟上报一次进度，后端存到用户观看记录表。用户再次进入播放页时，后端把上次的播放位置返回给前端，前端设置 video 组件的初始播放进度。
java复制@PostMapping("/api/progress/report")
public Result reportProgress(@RequestBody ProgressReport request) {
progressService.saveOrUpdate(request.getUserId(), request.getDramaId(),
request.getEpisodeNumber(), request.getPlayPosition());
return Result.success();
}
这里有两个细节。第一，上报接口不能用户点一次就存一次，会打爆数据库。我用的是“节流上报”，前端每5秒上报一次，并且只在播放中状态才上报。第二，后端存进度时用 insert ... on duplicate key update，按用户和剧集联合唯一索引更新，避免重复数据堆积。
4. 视频防盗链、性能优化与常见问题排查
4.1 视频防盗链：签名 URL 的完整实现
短剧内容就是收入来源，防盗链是整个项目里绝对不能马虎的一环。我前面提到了签名 URL，这里详细说一下实现方式。
我用的是云厂商标准的时间戳签名方案。后端生成 URL 时，在原始视频地址后拼接 ?auth_key=timestamp-rand-uid-md5hash，云服务商 CDN 会根据源站和客户端时间自动校验签名是否过期。不同的云厂商参数格式不同，但原理一致。
如果自己用 Nginx 搭建视频服务，也可以用 Nginx 的 secure_link 模块实现类似功能。不过短剧项目我建议直接用云厂商 CDN，省心省力，带宽成本也能接受。
防盗链的重点不只是“防”，还要能“追”。我建议在日志里记录每次播放凭证的生成时间、用户ID、剧集ID。万一出现盗播事件，可以追溯是哪部剧、哪个用户、什么时间泄露的。这个在项目初期可能用不上，但一旦出问题，没有日志就只能干瞪眼。
4.2 Java 后端缓存策略与性能调优
短剧小程序的流量特点是突发性强：一部剧在抖音上爆了，几小时内可能涌入几万用户。Java 后端如果不做缓存设计，分分钟被流量打崩。我常用的三级缓存策略是：
第一级是本地缓存，用 Caffeine 缓存热播剧的详情信息，过期时间设 30 秒。第二级是 Redis 缓存，缓存列表页数据和短剧详情，过期时间设 5 分钟。第三级才是数据库。
除了缓存，数据库连接池也要调好。我常用的 HikariCP 配置是最大连接数 50，最小空闲连接数 10，连接超时 30 秒。这个参数要根据服务器配置和流量情况调整。我之前在 2 核 4G 的机器上把最大连接数调到 200，结果数据库直接被打挂了。连接数不是越大越好，越大反而增加数据库压力。
4.3 小程序审核与常见拒绝原因
抖音小程序上线需要提交审核，审核不通过的大多数原因都和类目资质、内容合规有关。短剧小程序需要提供《网络文化经营许可证》或相关内容备案资质，这是第一条硬杠杠，没有资质基本不可能过审。
另外一个常见的拒绝原因是“诱导分享”。有些短剧小程序为了让用户拉新，搞“分享给好友免费解锁一集”的活动，这个在抖音小程序审核里是违规的。抖音生态对诱导分享的打击力度很大，不建议碰这条红线。
内容上也有一些限制。短剧内容本身如果涉及低俗、暴力、擦边情节，审核基本不会过。我见过不少项目因为某一集内容违规导致整个小程序被下架，损失非常大。建议上线前做一次全量内容自查，尤其是前几集免费内容，因为审核人员重点看的就是免费部分。
4.4 热词里那些“脚本”和“爬虫”，不要碰
热词里出现了“抖音福袋自动抢脚本”“抖音商品抓取助手”“抖音爬虫”“抖音无水印下载”这些词。这里我必须负责任地提醒一句：这些都属于平台明令禁止的违规工具，轻则封号，重则有法律风险。做短剧小程序更是要离这些远一点，一个正规小程序绑定任何灰产脚本，都可能导致整个小程序被清退。
我们做技术的人，尤其要有边界感。短视频平台的机器人脚本、批量抓取、自动抢福利这类东西，不仅技术上有对抗成本，法律上也有明确的合规风险。项目的长期价值，永远建立在合法合规、尊重平台规则和版权的基础上。如果只是眼红某些灰产的短期收益，那是把自己的账号和项目往火坑里推，没有任何讨论余地。
4.5 业务上线后的数据监控与报警
系统上线只是开始，后面还有更重要的监控工作。短剧小程序最重要的几个指标是：播放失败率、支付成功率、解锁转化率、首屏耗时。我对接的每个短剧项目都会在后台配一套监控看板，至少包含：接口 QPS、支付回调失败数、播放凭证生成失败数、订单超时未支付数。
监控怎么做？初期不用上太重的系统，直接用 Spring Boot Actuator 暴露健康检查，再用一个简单的定时任务检查支付回调队列积压量，超过阈值就发告警通知。等业务量上来再考虑接入专业监控系统。
真正让我觉得“必须上监控”的一次经历是：某个支付渠道升级，回调参数格式变了，但我们没有及时感知，导致用户支付成功但小程序里一直显示未解锁，大量客诉涌进来。如果有监控，这个问题在几分钟内就能被报警捕获，不至于等到用户投诉才发现。
4.6 排查实录：抖音小程序登录失败“wx1cb4398e1413dce7”
热词里有一条“小程序获取登录后的微信用户失败:wx1cb4398e1413dce7”，虽然这是微信小程序的报错，但类似的登录失败问题在抖音小程序里也会遇到，这里一并说下排查思路。
这种报错通常是开发者在调试时把 code 写死了，或者 AppID 配置错误。抖音小程序排查登录问题，我会按这样的顺序来：第一步看 tt.login() 是否真的返回了 code；第二步看后端是否成功拿 code 换到了 openid；第三步看后端返回的 token 是否被前端正确存储。80% 的登录问题都出在这三步中的某一环。
另外一个常见的坑是后端开发在本地调试时，把抖音开放平台的 AppID 和 Secret 配置错了。这两个配置不对，code 换 openid 的请求必然失败。建议把配置中心化，用 application.yml 管理，并且不要提交到 Git 仓库。
4.7 热词“抖音蓝v号登录”与平台能力边界
还有一个热词“抖音蓝v号登录”，顺带说清楚。蓝V认证号本质上是抖音企业号的认证体系，它对应的是企业号开放平台，和小程序开放平台是两套体系。如果你想做的是企业号能力，比如通过小程序服务蓝V商家的客户，那么需要使用企业号开放平台的接口，而不是小程序 AppID。
这个点容易混淆，尤其是团队里既有小程序业务又有私域运营需求时。我的建议是：搞清楚自己到底要什么。短剧小程序要用的是小程序开放平台的登录、支付、内容能力；蓝V号登录对应的是企业号能力，比如团购、预约、私信管理等。两者不能混用，否则开发到一半发现接口调不通，返工成本很高。
5. 上线后的运营经验与个人实操体会
5.1 短剧的内容运营节奏与后端配合
短视频平台上做短剧小程序，成败往往不在技术上，而是在内容运营节奏上。这里分享几个后端要配合的业务需求，提前在系统里留好口子。
第一，免费集数要能灵活配置。一部剧刚开始推广时免费5集，热度下降后改成免费3集，运营要能在后台动态调整，不能让开发改代码。第二，解锁价格要支持运营活动，比如限时折扣、整剧打包价。第三，数据报表要能按天、按剧、按渠道维度筛选，方便运营判断哪部剧值得继续买量。
这些需求在系统设计阶段就要想到。我最开始做的时候，把免费集数写死在代码里，运营每次调整都要找开发，非常痛苦。后来重构成了运营配置表，每部剧在后台页面上直接改配置，省了无数沟通成本。
5.2 数据埋点与转化漏斗分析
数据埋点是短剧小程序运营决策的基础。抖音小程序的播放页是天然的转化漏斗：曝光 -> 点击 -> 播放第1集 -> 播到免费集最后一集 -> 点击解锁 -> 支付成功。每一层的流失率，都对应一个产品优化点。
埋点场景要覆盖：页面曝光、按钮点击、播放开始、播放结束、试看结束、解锁点击、支付结果。Java 后端在接口层做埋点采集，把关键日志输出到日志平台，再用离线任务做漏斗分析。刚开始不用上贵的商业分析工具，用好日志和 SQL 就能解决大部分问题。
5.3 短剧版权与内容安全的兜底方案
做短剧小程序，版权问题绕不开。正规做法是：每一部短剧都要有版权授权证明，上线前把授权文件存档。否则版权方投诉到平台，小程序会被直接下架，前期投入全部打水漂。
技术层面也要做好内容安全管理。抖音平台对短剧内容有明确的审核要求，后端要能支持对某一集内容做下架处理，而不是只能整部下架。我设计的剧集表里有一个 status 字段，0 表示正常，1 表示下架。前端拉取剧集列表时自动过滤已下架剧集，用户播放时如果发现剧集已下架，给出友好提示。
5.4 一点个人经验总结
做了几个短剧小程序项目后，我的一个深刻体会是：技术方案要提前为业务的热度波动做设计。短剧很容易因为抖音推流而出现瞬时高并发，所以缓存、限流、熔断这些能力，一开始就要有，否则等流量来的时候再补就来不及了。
另外，Java 技术栈在短剧这个领域，最大的优势其实是稳定和可控。一个短剧小程序要同时处理内容管理、用户体系、支付交易、分账结算、数据报表，几乎是一个小型电商系统加上视频分发能力。Spring Boot 生态在这一整套链路上都非常成熟，招人容易、排错容易、扩展容易，对创业团队和成熟团队来说都是稳妥的选择。
如果这篇文章能帮你少踩几个坑，让项目的推进顺利一些，那就很值得了。后面如果我在实践中遇到新的问题和解法，再回来更新。