365天等待完整版视频，一个Golang开发者的时间困境与破局实战

那天深夜，我盯着进度条发呆

凌晨两点十七分，我家那只橘猫又跳到键盘上，把一堆乱七八糟的字符拍进了终端，我把它拎走，继续盯着屏幕——不是代码，是一个视频播放器的进度条，那个该死的进度条，在99.7%的地方卡了整整三天。

你可能觉得我在说什么盗版电影或者某部追了一年的番剧，不对，我说的是我们自己项目里那个号称“365天后才能看到完整版”的视频处理管线，没错，我们用Golang写了一套视频处理系统，但客户非要搞一个“慢速发布”机制——视频每天只解密一小段，整整一年才能看到完整内容，听起来很离谱对吧？但这是真事儿，而且我觉得这个案例里藏着不少Golang开发中特别容易被忽视的坑,值得掰开揉碎了讲一讲。

需求从哪来？客户说“我要仪式感”

先把这个项目的背景交代清楚，对方是一家做在线教育的公司，不是那种卖盗版课的，而是搞“陪伴式学习”的，他们的核心卖点是：你报了一门365天的课程，每天解锁一节课，不能快进，不能跳转，这个“完整版视频”指的是整个年度的课程合集，但它在技术实现上被切成了365个碎片,每个碎片对应一天。

客户原话是：“我们要制造一种期待感，就像追剧一样，你知道结局在那里，但你必须一天一天等。”

行吧，需求方永远是对的，我们当时接这个活儿的时候，整个后端团队的核心技术栈就是Go，说实话，Go做这种定时解锁、流媒体转发的活儿挺合适的，goroutine天生适合处理并发请求，标准库里的net/http也够用，但问题是，“等待365天”这个时间维度，给代码设计带来了一些平时根本想不到的麻烦。

第一个坑：时间不是你想的那样

写代码的人都知道，处理时间要用time.Time，存时间戳用int64，但当你真正要设计一个跨365天的定时任务时,事情就变得微妙了。

我们最初的设计特别天真：数据库里存一个unlock_time字段，类型是DATETIME，每天凌晨0点跑一个cron任务，把当天的视频片段的status从locked改成unlocked,听起来没问题吧？

但上线第三天就出了幺蛾子，有个用户反馈说，他早上七点就看到了第二天的视频内容，排查了半天，发现是时区问题，我们的服务器部署在华东，但客户的新用户里有几个在新疆，用的是UTC+6，凌晨0点，在乌鲁木齐其实是前一天晚上10点，cron任务按服务器本地时间跑,结果就提前解锁了。

这个问题的根源在于，我们想当然地用了服务器本地时间，而不是用户维度的时间，后来改成所有时间都按UTC存储，展示层再转换成本地时区，但这里又冒出一个新问题：跨年的夏令时怎么办？ 虽然中国不搞夏令时，但客户说他们未来可能拓展东南亚市场，那边有些国家有，Go的time包处理自时区转换没问题，但如果你存的是一串固定时间戳,转换起来就非常痛苦。

我们最终的方案是：存time.Time带时区信息，而不是裸的Unix时间戳，Go的数据库驱动比如pgx对timestamptz支持得不错，查询的时候统一用UTC比较，只在输出到前端的时候转成用户本地时间，这个改动花了两天，但彻底解决了“时间错乱”的bug。

第二个坑：视频碎片怎么存？别用文件系统硬扛

一开始我们很傻很天真，把365个视频片段直接扔在服务器磁盘上，路径就是/data/videos/2024/04/15.mp4这样，然后NGINX直接做静态文件服务，按日期目录来,但用户量一大就崩了。

具体表现是：每天凌晨0点一过，大量用户同时请求当天的视频片段，磁盘I/O直接打满。 因为视频不是一次性生成的，是客户那边传过来一整年的原始视频，我们每天切片一次，但切片过程中，ffmpeg进程占用了大量CPU和临时磁盘空间，高峰期系统负载到了30多,接口响应时间从50ms飙到5秒。

后来我们痛定思痛,做了三件事：

1. 把视频切片服务独立出来，用context.Context控制超时,防止ffmpeg挂死。
2. 引入对象存储，不是自建MinIO那种，是直接上云（客户不差钱），把切片好的视频传到S3兼容的桶里，Golang的aws-sdk-go-v2用起来顺手，但要注意的是上传和下载都要走流式接口，别一次性ReadAll到内存，一个视频几百MB,内存会爆。
3. 加了一层本地缓存，用groupcache的思路做了个简单的热点缓存，每天0点后的前十分钟，命中率高达90%以上,因为大家都在看同一个视频。

这里有个细节：Go的io.Copy配合io.Pipe做流式上传特别优雅,写了一段伪码：

pr, pw := io.Pipe()
go func() {
    defer pw.Close()
    ffmpegCmd.Stdout = pw
    ffmpegCmd.Run()
}()
uploader.Upload(ctx, pr)

这段代码让ffmpeg的输出直接流向对象存储,内存占用几乎为零。

第三个坑：状态机设计，别用简单的布尔值

“365天等待”听起来就是一个很长的状态机，每天有个状态：locked、unlocked、watched、expired，最初我们只用了一个is_unlocked布尔字段，后来发现想查“用户A已经看了多少天”“哪些用户还有3天就结束”这类统计,完全没法写SQL。

改成状态机之后,我们用Go写了一个简单的枚举：

type VideoStatus int
const (
    StatusLocked VideoStatus = iota
    StatusUnlocked
    StatusWatched
    StatusExpired
)

但真正要处理的是状态转换的原子性，用户请求播放第二天视频时，前端会调用一个unlockToday()接口，这个接口里要先检查当前时间是否已经过了解锁点，然后更新数据库状态，如果并发请求同时来，会导致状态被重复更新，或者更严重的是，用户前一天没看，第二天想看两天的视频（客户允许补课），那状态机的跳转就要支持“从locked直接到unlocked，但跳过watched”这种逻辑。

我们用Golang的sync.Mutex加了进程内锁，再用数据库的SELECT ... FOR UPDATE保证跨节点的原子性，但说实话，如果你不想引入Redis做分布式锁，那就把状态转换做成幂等的——无论状态是locked还是watched，只要时间到了，就允许置为unlocked，这样即使并发请求重复执行,结果也是一样的。

这里给个血泪教训：最开始我们没有幂等设计，结果某个周五晚上十一点半，一个用户疯狂点播放按钮，触发了几十个并发请求，把数据库连接池打满了，虽然当时是测试环境,但也够吓人的。

第四个坑：日志和监控，你根本离不开它们

365天的时间跨度，意味着你的服务要连续跑一年不出大问题，这不是开玩笑，我们中间经历过一次内存泄漏，原因是某个第三方库内部缓存了http.Client的响应体没释放，排查过程就不描述了，反正最后是靠pprof和go tool trace定位到的。

从那以后,我养成了两个习惯：

1. 每个请求都带request_id，用中间件生成，放到context.Context里，日志统一输出，Golang的slog库（标准库里的log/slog）配合context传播很方便。
2. 定时跑go vet和staticcheck，别信编译器,静态分析能抓到不少并发问题。

还有一点，监控指标别只看服务端，因为是视频播放，前端体验很重要，我们用Prometheus暴露了video_fragment_download_duration和video_fragment_error_total这些指标，后来发现，用户所在网络的运营商对跨网请求特别慢，又加了CDN加速,这一步把平均首帧时间从3秒降到了800毫秒左右。

第五个坑：测试，特别是时间相关的测试

365天的逻辑，你怎么写单元测试？总不能真的等一年。

我们用Go的time包注入方案：把获取当前时间的函数改成接口，测试时传入一个可控的“时钟”。

type Clock interface {
    Now() time.Time
}
type realClock struct{}
func (realClock) Now() time.Time { return time.Now() }
type mockClock struct {
    current time.Time
}
func (m mockClock) Now() time.Time { return m.current }

然后所有业务逻辑都依赖这个Clock接口，测试里把current设成未来的某一天，直接验证状态机跳转是否正确，这个方法救了我们无数次，尤其是测试“第365天解锁完整版”这个终极场景——不用真的等一年。

那365天之后呢？

这套系统上线已经跑了大概两百天，目前稳定得让人有点无聊，但有意思的是，客户又开始提新需求了——他们想把“等待完整版”这个体验做成一个会员增值功能，比如付费可以提前解锁若干天，这意味着状态机要支持“跳过时间”的逻辑，而且价格策略会影响解锁概率，哎，需求这个东西,永远没有尽头。

但回过头想，这个项目里很多坑，并不是Go特有的，任何语言都逃不过时间处理、并发控制、状态管理这三座大山，Go只是让我更容易犯这些错误，但也更容易让我调试——比如go test -race能抓出很多数据竞争，标准库的net/http/httptest写接口测试也很顺手。

橘猫又跳上来了，这次它踩到了Ctrl+C，把我一个在跑的集成测试给中断了，行吧，今天就聊到这儿，如果你也在写类似这种“长周期解锁”的业务，记住一件事：别把时间当成一个数字，把它当成一个会咬人的怪物，处理好时区，设计好状态，写好测试，然后祈祷一年后你的代码还在稳稳地跑着。 至于那365天等待的完整版视频，也许到那天我自己都没兴趣看了——但系统在,它就永远在那。