动态太多导致发布视频时加载很慢，这个场景我见过很多次。尤其当一个人的主页连续更新了几个月，动态数量超过几千条之后，发布按钮点下去，页面会明显顿住，状态栏一直转圈，选视频素材那一刻更明显。“我的朋友，请删掉一些动态吧”这句话虽然像玩笑，但它背后其实是一个非常典型的性能问题：发布页在偷偷加载大量历史数据。
下面按我实际排查的顺序拆一遍。普通用户可以重点关注清理和归档部分，开发维护者重点看列表、接口、缓存和媒体压缩。不要一上来就动手全量删数据，先找到卡点，再决定怎么改。
1. 为什么动态一多，发布视频就会明显卡顿
1.1 发布页要加载的东西比你想的多
很多人以为发布视频就是把文件选好、填一行文案、点发布。真去打开一个动态很多的主页发布页时，事情没那么简单。页面要处理登录信息、草稿、编辑框、话题、定位、可见权限、素材选择器，还要把历史动态列表或相册缩略图提前拉出来。动态越多，前端要渲染的节点越多，后端接口要返回的数据越大，网络传输和本地渲染的时间自然就上去了。
所以在很多实际项目里，慢的不是“上传视频”那一下，而是打开发布页和选择素材时，页面已经把所有历史动态都加载了一遍。这个动作通常发生在用户还没开始选视频之前，容易让人误判成“发布功能本身有问题”。
另外，发布页里的历史动态不只是文字。每条动态可能带封面图、缩略图、视频时长、点赞数、评论数、发布时间。对一个很久没整理的账号来说，这些数据会越积越多。哪怕每条动态只占很小的体积，几千条加在一起，也会让接口返回体积变得非常难看。
1.2 “慢”通常叠加在四个环节上
动态数量多不会只影响一个地方。从实际表现来看，问题一般会叠加在四个环节里。
| 环节 | 动态多时会发生什么 | 用户感受 |
|---|---|---|
| 后端查询 | 要查动态列表、媒体信息、互动数据，数据量越大耗时越长 | 打开发布页转圈 |
| 数据返回 | 全量返回时体积大，网络传输慢 | 等了很久页面才出来 |
| 前端渲染 | DOM节点多，图片请求多，滚动和点击掉帧 | 页面卡顿、操作不跟手 |
| 媒体预览 | 素材库或相册一次性加载大量缩略图甚至原图 | 选视频时特别卡 |
这几件事不是每次全都同时发生，但动态数量多会让每个环节的下限都变高。比如后端一次查几千条记录，还要拼装里面的封面、时长、互动信息，接口时间很难下降；前端拿到几千个节点后，又要发起大量缩略图请求，低配置手机很容易被拖垮；如果选择视频时还要扫整个媒体库，卡顿就更明显。
所以最直接的思路，就是减少发布页需要加载的动态数量。这也是“请删掉一些动态”这句话有一定道理的原因。但如果只靠用户手动删，其实治标不治本。短时间内看着清爽，过一两个月数据又涨回来。我在实际项目里更建议把优化重点放在页面和接口的设计上，让发布页不再依赖全量数据。
2. 先诊断：你的“慢”到底卡在哪一环
2.1 普通用户怎么分清楚卡点
普通用户没法直接看接口，但可以看现象。不要只跟别人说“发布视频太慢了”，要记录一下“慢在哪个动作之后”。我一般会建议分四类情况判断。
| 现象 | 更可能的原因 | 优先处理方式 |
|---|---|---|
| 打开发布页就一直转圈 | 历史动态列表接口慢，或前端渲染太重 | 先归档、隐藏不想要的动态，再看是否变快 |
| 选视频文件时卡顿 | 本地媒体库太大，缩略图预览过多 | 清理相册或素材库，选视频前先压缩文件 |
| 上传过程缓慢 | 网络上行慢，或服务端要转码 | 压缩视频、降低码率，避开网络高峰 |
| 点“发布”后保存很久 | 后端生成封面、入库、存媒体耗时 | 普通用户只能等待；开发者要改异步处理 |
如果你每次卡在同一个动作，记录比猜测可靠。比如“打开发布页要3秒，但选择视频那一刻更明显”，这通常说明问题在历史动态列表和素材库预览，而不是上传链路。
2.2 开发者要记录四个关键指标
不要凭感觉去优化。我一般会在浏览器开发者工具里走一遍标准流程：清掉缓存，打开无痕窗口，进入发布页，完整执行一次“打开—选择视频—取消”流程，然后看 Network 面板里的请求列表。
重点看四样东西：
- 接口数量
- 接口总耗时
- 接口返回体积
- 媒体请求数量
连续测五次，去掉最高最低，取中位数。如果接口返回体积很大，大概率是发布页把全量动态列表塞了进来；如果体积不大但耗时很长，问题更可能在数据库查询、缓存策略或服务端组装逻辑；如果体积和耗时都不高但页面还是卡，重点看前端渲染和媒体资源加载。
这类问题最怕只改一个地方。比如只把接口查询加了个索引，但前端还在一次渲染几千条，速度提升也有限。先定位是哪几个环节叠加，再逐项处理。
2.3 不要忽略素材库和相册预览
还有一类卡顿和动态列表无关，但很容易被忽略：发布页自带的素材选择器。用户选择视频时，系统可能会扫描整个媒体库或相册，缩略图一张张加载出来。如果这些缩略图是原图，或者几百张一次性全部渲染，卡顿就会发生在“选文件”阶段。
这个环节和动态列表是两套数据，优化时要单独处理。相册列表要做分页，缩略图要走压缩和CDN，选中的文件才读取原始视频。否则就算你删掉了大量动态，选择视频时还是会卡。
3. 按优先级清理动态和归档历史内容
3.1 先备份，再统计，别直接删
无论是普通用户还是开发者，清理动态之前最重要的一件事都是备份。普通用户在社交平台里，最稳的操作不是“删”，而是先设为“仅自己可见”或“隐藏”，观察几天再决定。开发者清理线上数据前必须备份数据库和媒体目录。
# 以文件备份为例 tar -czf backup_media_$(date +%Y%m%d).tar.gz /path/to/media数据库备份建议用常规导出工具，同时确认备份文件能正常打开、大小合理。很多问题不是删错了才出现，而是备份文件损坏但没人检查，真到恢复的时候才发现根本用不了。
备份之后先统计一下，别凭感觉判断。可以先数一数某个用户或某个分类下到底有多少条动态，里面文字动态、图片动态、视频动态各占多少。视频动态的缩略图和封面请求最多，清理它的效果通常比清理文字动态更明显。
-- 示例：按状态统计动态数量 SELECT status, COUNT(*) AS cnt FROM user_dynamics WHERE user_id = '目标用户ID' GROUP BY status;字段名会随着表结构变化，直接照抄不一定能跑通。重点是先把数量摸清楚。
3.2 推荐的清理顺序
我比较推荐按这个顺序处理：
- 先备份数据库和媒体目录。
- 按类型统计动态数量，找到大头。
- 找出测试内容、过期活动、无互动内容和重复素材。
- 先隐藏或归档，不直接删除。
- 确认发布页速度有改善，再决定是否物理删除。
为什么要先隐藏而不是直接删？因为“删除”这个动作很难撤销。隐藏、仅自己可见、软删除都保留了一条后退的路。如果你清理后发现某些动态还有价值，或者平台策略变化需要恢复历史内容，还能找回来。
对开发者来说，最合适的方案是给动态表加一个状态字段，比如active、archived、deleted。发布页只查active状态，归档数据不参与前台加载。用户想看历史内容时，再去单独的存档页面查。
-- 示例：把 2022 年之前、状态为 active 的动态改为 archived UPDATE user_dynamics SET status = 'archived' WHERE user_id = '目标用户ID' AND created_at < '2022-01-01' AND status = 'active';执行更新之前，先写一条等价的SELECT确认影响行数，确认无误后再更新。这条建议在几乎所有数据变更场景里都适用。
3.3 用“归档”代替“删除”
不同处理方式对前台加载的影响完全不同，可以看一下这个对比。
| 处理方式 | 数据还在吗 | 发布页是否加载 | 恢复难度 |
|---|---|---|---|
| 隐藏 / 仅自己可见 | 在 | 不加载 | 容易 |
| 软删除 / 归档表 | 在 | 默认不加载 | 可恢复 |
| 物理删除 | 不在 | 不加载 | 不可恢复 |
普通用户优先用“仅自己可见”或“隐藏”，开发者优先用软删除和归档状态。物理删除只适合清理测试数据、垃圾内容，或者有明确合规要求的数据。不要为了追求页面速度把所有动态都删干净，历史内容本身也有价值。
另外，清理后要注意缓存。有些平台把动态列表做了缓存，你改了数据库之后，接口可能还会返回旧数据。这时候需要刷新缓存或等待缓存过期，否则容易误判成“清理没效果”。
4. 页面和接口层面的核心优化
4.1 让发布页默认只加载最近的动态
手动删动态只能缓解一时。更稳定的做法是改发布页的数据加载方式，让它不再一次加载全量动态。
最有效的一招，是把“发布时展示历史动态”的接口改成默认只返回最近20到30条，用户向下滚动时再加载更多。前端不再一次性渲染几千个节点，接口返回体积会明显下降。
进入发布页： 请求 GET /dynamics?limit=30&before= 渲染最近 30 条 用户上拉加载更多： 请求 GET /dynamics?limit=30&before=上一页最后一条id 追加渲染这是一段伪代码，意思比实现重要。后端可以继续保留历史查询能力，但发布页前端默认不主动拉全量数据。
如果产品希望发布页里有“最近使用素材”的功能，也可以基于这个逻辑做。只展示用户最近使用过的素材，而不是把所有历史素材都堆在发布时间。
4.2 接口返回字段要瘦身
很多时候速度慢不是因为数据条数多，而是每条动态返回的字段太多了。列表接口根本不需要返回每条动态的完整内容、超长文案、评论列表、地理位置、标签详情。只要返回发布页展示时最需要的那几个字段就够。
{ "items": [ { "id": "dynamic_1001", "type": "video", "cover": "https://cdn.example.com/covers/1001_cover.jpg", "duration": 18 } ], "has_more": true }详情字段放到详情接口里，用户真正点开某条动态时再请求。这样做的好处是传输体积变小，前端解析时间变短，列表渲染也会更快。不要在图列表接口里拼 HTML，也不要把视频原文件地址提前返回给前端。
4.3 媒体文件要先压缩再展示
发布页里的图片和视频预览，是拖慢加载的另一个重要原因。图片方面，最直接的做法是使用缩略图，用户点击或选中之后再加载原图。视频方面，不要在列表阶段就把完整视频加载到内存里，只展示封面和时长，等用户确定上传时再读取文件。
实际项目中，图片缩略图已经是常规操作，很少有页面会直接拉原图。视频的问题是更容易踩坑：压缩参数设置太狠，画质会明显下降；不压缩，上传和转码又很慢。我一般会先用一个小样本视频验证参数，对比画质和文件体积，再决定生产配置。
记住一个原则：发布页里能用封面图说明的，就不要提前加载原视频；能用缩略图说明的，就不要加载原图。把“预览看到的资源体积”压下来，发布页打开速度会快很多。
4.4 缓存和数据库索引要配合
动态数量涨到一定规模后，后端查询也会成为瓶颈。这时候需要做两件事：加缓存和加索引。
缓存方面，可以缓存发布页首屏接口的结果。缓存 key 按用户 ID 和最近动态数量设计，用户在发布新动态、修改状态、归档数据时，再让缓存失效。这里要注意，缓存并不是越多越好，缓存过期策略没做好，会出现“清理后接口还返回旧数据”的问题。
数据库方面，针对常用的查询条件建联合索引，比如用户 ID、状态、创建时间。
-- 示例：给常用查询条件建联合索引 CREATE INDEX idx_user_status_created ON user_dynamics(user_id, status, created_at);不是所有慢查询都能靠索引解决。索引本身会占用存储空间，也会影响写入性能。建索引之前先看慢查询日志，用执行计划确认当前查询慢在哪里，再决定要不要建。
4.5 视频上传链路也要降载
发布视频变慢，除了页面加载，还有一个容易被忽略的点：上传本身。
如果用户直接上传一个几百MB的原视频，服务端又要实时转码，整个过程会显得非常慢。更稳的做法是：前端先压缩，上传走分片，服务端转码放到异步队列。用户看到“已上传成功”后继续填写文案和发布，不用一直等转码完成。
这里要特别提醒一下：不要一上来就把分片并发开到最大。并发太高，不仅容易把上行带宽挤满，还可能给服务端造成压力。建议先测单文件上传的耗时，再逐渐增加分片数，观察失败重试和稳定性。
5. 验证优化效果并判断是否达标
5.1 怎么对比优化前后
优化做完之后，验证是不能省的。我会用同样的网络、同样大小的测试视频、同样的页面入口，分别跑“打开发布页—选择文件—取消”这个过程。连续测五次，记录一次数据。
关键点是清缓存，并且用无痕窗口。不清缓存的话，很多静态资源和接口结果都命中缓存，你会以为优化效果很好，但普通用户第一次访问时的体验还是卡。
有条件的话，可以用浏览器开发者工具导出 HAR 文件，或者手动记录几个关键数字。没有工具也没关系，记录你直观感受到的变化，比如“发布页从转圈3秒变成1秒内出现”。
5.2 看哪些指标
| 指标 | 优化后要观察的点 |
|---|---|
| 发布页首屏接口耗时 | 连续几次测试是否明显下降，数值是否稳定 |
| 接口返回体积 | 是否从“列表返回了大量字段”变成“只返回最近N条的轻量字段” |
| 媒体请求数量 | 是否从几十上百个缩略图请求变成只加载可见列表里的资源 |
| 页面滚动和选素材流畅度 | 是否有明显掉帧，长任务次数是否减少 |
| 上传耗时 | 是否受压缩和分片影响，是否可接受 |
不同项目的网络环境和机器配置差异很大，不建议直接套用某个固定时间阈值。重点看相对变化。如果发布页从“打开要等好几秒”变成“打开后基本能立即出现，选择视频不再掉帧”，优化目标就算达到了。
5.3 优化后仍卡，按这个顺序查
优化后如果依然慢，别急着改更多参数，按顺序排查：
- 清缓存，换无痕窗口，排除旧资源和本地缓存干扰。
- 看接口返回内容，确认是否还有全量数据返回。
- 看媒体请求，确认是否加载了原图或原视频。
- 看服务端日志和慢SQL，确认查询是否走了索引。
- 看CDN或静态缓存是否没刷新，导致旧资源还在。
如果这些环节都是正常的，页面还是卡，再把注意力放到前端渲染上。比如动态列表是否没有虚拟化、某个控件是否重复渲染、事件监听是否太多。这类问题和后端接口关系不大，但同样会造成页面卡顿。
5.4 低配置机器也一定要测
有些优化在高端手机上看着很快，但在低配置机器上还是会卡。建议保留一台低配测试机，或者用浏览器自带的 CPU 降频模拟功能，把渲染能力压到接近普通用户水平。
这一点容易被忽视。开发机器通常配置高，网络也好，测什么都快。但真实用户手里的设备和网络条件差距很大，发布页这种高频场景必须在更差的条件下验证。
6. 怎么防止动态数量和发布速度再次恶化
6.1 给动态设置数量上限和自动归档
手动整理只是临时手段，长期来看要建立机制。
普通用户可以给自己定一个整理节奏，比如每季度把旧动态批量改成“仅自己可见”，不重要的活动内容直接清理。开发者可以在服务端做规则：单个用户或单个分类下的活跃动态超过一定数量后，自动把最早的一批改成归档状态。
这样做不是限制用户发内容，而是让发布页和主页始终只处理活跃数据。历史内容仍然保存，只是默认不参与前台加载。用户需要时，再去存档列表查看。
6.2 发布流程里默认限制媒体资源体积
发布视频变慢，很大一部分原因是媒体资源没有前置限制。可以在用户选择视频时就检查大小和分辨率，如果超过阈值，提示先压缩或限制时长，避免超大文件直接进入上传队列。
服务端也要限制单文件大小和转码规格。不要等用户传上来一个几个GB的素材后，再让整个发布链路背锅。最好把这个限制放在最前面，能拦截多少算多少。
这里不要一刀切。如果产品本身定位就是高清视频分享，给高清用户单独通道或者独立上传策略，而不是让所有人统一压缩到同一个规格。否则优化发布速度的代价，可能是画质体验下降。
6.3 把发布页性能纳入日常检查
发布页这种入口，建议每次版本发布前后都跑一次性能检查。记录接口耗时、返回体积、媒体请求数。如果比上一版高出太多，就要及时查看是不是有人把全量列表又加了回来，或者某个新功能给发布页额外增加了请求。
有条件的话，加一个简单的接口性能监控告警。比如近十分钟发布页首屏接口的 P95 耗时超过某个阈值就提醒。不用做得非常复杂，先能发现趋势就好。很多项目的问题不是技术上解决不了，而是问题发生很久了才发现。
6.4 最后一点：不要只盯着“删动态”
踩过几次之后我发现，很多问题不是工具能力不够，而是数据量积累和页面设计不匹配。删动态只是第一步，真正让体验稳定的做法是：发布页永远只加载它需要的最近数据，历史内容走归档，媒体资源先压缩，再配合缓存和索引。持续观察，比一次大清理更有效。
