X 归档里的 media 文件夹：里面存了什么，该怎么处理

下载并解压 X 数据归档之后，很多人第一眼会去看 tweets.js 或 tweets.csv，因为那里是文字。但真正占体积的往往是另一个文件夹：media。一个中等活跃度的账号，media 目录轻松超过几百 MB，活跃账号到几 GB 也不意外。

这个文件夹容易带来两个困惑：不确定它是不是有用的资料，也不确定清理隐私时该不该连它一起处理。先把它的构成说清楚，后面的判断会容易很多。

media 里放的是什么

内容	说明	体积影响
你原创发布的图片	发推时直接上传的照片、截图	数量最多，占主要体积
视频与动图文件	上传的视频，以及被转存的 GIF	单个文件最大
后续修改过的版本	同一张图的不同尺寸副本	容易被忽略的额外体积

注意这里只有你上传的文件。别人发布的内容、你转发的内容，通常不会连同原始文件一起打包。

文件命名规则说明了什么

media 目录里的文件大多以数字或字母数字串命名，看起来没有规律。这串字符对应平台内部的媒体标识，不是原始文件名。也就是说，你不能靠文件名判断是哪条推文。

好在有几个补救办法。文件的时间戳通常接近发布或上传时间，配合 tweets.js 里的发布时间，可以用时间窗口把文件和推文对应起来。整理量不大时，这条路径基本够用。需要更系统的做法时，可以参考归档里的 tweets.js 结构那篇。

为什么有些图在归档里找不到

归档不完整是常见现象，几种原因混在一起。

• 外链图片不打包。如果推文里放的是外部图床链接，归档通常只保留链接文本，不下载文件本身。链接失效后，归档里就只剩一段地址。
• 转推内容不在其中。你转发的他人内容，媒体文件一般归属于原作者，不会进你的归档。
• 已删除内容不会回头补。如果你在导出之前已经删过推文，对应文件一般不会出现在归档里。

还有一种情况是导出中断。归档包体积大，网络不稳定时可能生成不完整的压缩包，表现为解压报错或某些目录为空。遇到这种情况，重新申请一次导出比手工修补更省事，相关排查见归档下载失败的排查。

清理时该保留还是丢弃

判断依据是「这个文件夹有没有独立价值」，跟它占了多少空间无关。

情况	建议	原因
只关心隐私暴露	文本层优先，media 作为二次核对	风险信息主要在文字里，图里偶有截图类风险
要留存个人记录	整体保留，另做加密备份	媒体是原始素材，删了不易找回
只想省空间	按时间分层，保留近期	早期文件多数已无使用场景

容易被忽略的一点是：截图类图片本身可能携带风险信息，比如账单、证件、工牌、门禁卡。这类内容在文本扫描里看不出来，需要人工过一遍。归档存放在哪里、怎么保管，可以参考归档的安全存放。

处理大体积归档的实际做法

归档超过几个 GB 时，直接在本机全量打开会很吃资源。比较稳的做法是先分层，再针对处理。

1. 先看目录构成。确认 media 与文本文件各占多少，判断主要体积来源。
2. 按年份切分。把 media 里的文件按时间戳归档到不同年份目录，后续可以只处理需要的那一层。
3. 文本先跑一遍风险扫描。文字层的暴露点确定之后，再回头核对相关的媒体文件。
4. 截图类单独建一个目录。人工过一遍，这类内容自动化很难判断。
5. 整体做加密备份。归档包含大量个人信息，明文存放不合适。

处理体积较大的归档时，本地解析比上传云端更合适。200MB 以上的归档处理方式，大体积归档的处理有更具体的说明。

media 与删除操作的关联

有一点需要说明：删除推文时，随推文发布的媒体文件会一并处理，不需要单独操作。归档里的 media 目录只是导出时刻的快照，它不会因为你后来删了推文而自动更新。

所以不要把归档当成当前状态的镜像。判断现在还剩哪些内容，要看线上；判断历史上发过什么，才用归档。

About digital-footprint-health.shop

归档是全部后续判断的起点。在 digital-footprint-health.shop 从首页上传 X 数据归档，工具在本机解析全部推文，按联系方式、地址定位、机构关联、立场表达分层给出风险清单，归档不离开你的电脑。体检免费且只读，不删除任何内容；清理范围与计费方式在定价页，方法类文章集中在博客索引。