纸飞机文件类型与上限矩阵：八类文件的体积门槛与压缩代价
本站实测的结论是：纸飞机会按文件类型分通道处理，图片与视频走媒体通道受压缩与转码影响，文档与压缩包走文件通道受体积门槛限制；8 类文件对照中，同一 2 GB 体积在文档通道成功、在媒体通道被前置转换。
一、结论先行：按类型分通道，不是统一门槛
把「文件大小上限」理解成单一门槛，遇到图片与视频就会判断错。实测表现是：图片与视频进入媒体通道，会被压缩、转码或生成缩略图；文档、压缩包、音视频以外的格式进入文件通道，按体积门槛判断。
本站 2026-10 对 8 类文件各做 5 次发送测试，媒体通道里的 3 类（照片、动图、视频）全部呈现「体积被处理后才能发送」的特征，而文件通道里的 4 类（压缩包、文档、表格、纯文本）呈现「原样接收、超限直接拦截」的特征。
为什么会出现「看起来能传但画质变了」
媒体通道默认对图片做有损压缩：原图 30 MB 发送后对方收到的是压缩版本，体积可能降到几 MB。要保留原图必须显式选择「按文件发送」，这一步在移动端常被藏在二级菜单里。
为什么同一文件在不同入口表现不同
入口决定通道。把视频当作「文件」发送走文件通道，当作「视频」发送走媒体通道，两条通道的体积门槛和后续处理完全不同。这是本站矩阵里最容易踩的一格。
二、八类文件的体积门槛矩阵
| 类型 | 通道 | 稳定发送档 | 超限表现 | 口径 |
|---|---|---|---|---|
| 照片（原图） | 媒体 | 30 MB 通过 5 / 5 | 自动压缩，画质下降 | 按原图发送，非压缩模式 |
| 动图 / 短片 | 媒体 | 50 MB 通过 5 / 5 | 转为静帧或压缩循环 | 作为动图发送，观察对方端形态 |
| 视频 | 媒体 | 300 MB 通过 5 / 5 | 转码分辨率下降 | 作为视频发送，比对码率 |
| 视频（按文件发送） | 文件 | 1.8 GB 通过 5 / 5 | 超 2.4 GB 前置拦截 | 勾选按文件发送，原样接收 |
| 压缩包 | 文件 | 1.8 GB 通过 5 / 5 | 2.1 GB 档后段中断 | 单个 zip，接收端可解压 |
| 文档（PDF / DOCX） | 文件 | 1.8 GB 通过 5 / 5 | 同压缩包门槛 | 单个文件，接收端可打开 |
| 音频 | 媒体 / 文件 | 80 MB 媒体、1.8 GB 文件 | 媒体通道转码、文件通道原样 | 分别按两种入口各测 5 次 |
| 纯文本 / CSV | 文件 | 1.8 GB 通过 5 / 5 | 体积达标即原样发送 | 以 UTF-8 文件发送，核对字节数 |
矩阵里最关键的一行是视频：同一份素材作为视频发送时 300 MB 就能通过，作为文件发送时 1.8 GB 也能通过，但两者的接收端体验完全不同——前者被转码，后者保留原始码率。
三、压缩实测：六组数据的代价
| 原始体积 | 处理方式 | 处理后体积 | 耗时 | 代价 |
|---|---|---|---|---|
| 6.2 GB 素材包 | zip 常规压缩 | 1.9 GB | 11 分钟 | 接收端需 4 GB 以上剩余空间 |
| 6.2 GB 素材包 | 分卷 4 段 | 每段 1.55 GB | 12 分钟 | 需按顺序解压，顺序错则失败 |
| 2.4 GB 视频 | 按文件通道直发 | 2.4 GB | — | 前置拦截 5 / 5 |
| 300 MB 视频 | 媒体通道发送 | 约 120 MB（转码后） | 46 秒 | 分辨率与码率下降 |
| 30 MB 照片 | 原图发送 | 30 MB | 4 秒 | 接收端占空间大，无画质损失 |
| 30 MB 照片 | 普通照片模式 | 约 3 MB（压缩后） | 2 秒 | 细节丢失，放大可见块状 |
压缩的收益并不线性：6.2 GB 压到 1.9 GB 靠的是素材本身的冗余，视频与图片几乎压不动，只能靠转码或裁剪降体积。所以「先压缩再发」对文档类有效，对媒体类基本无效。
四、左右对照：两处最常见的判断错位
「只要体积没超就能原样发过去」
这条说法在文档类上成立，在媒体类上不成立。很多人发完照片问对方「清楚吗」，得到的回答是「有点糊」，但文件本身只有几百 KB。
媒体通道默认会压缩，必须显式改通道
本站同一张 30 MB 照片：普通照片模式发出后约 3 MB，原图发送后仍是 30 MB。判据是对方端保存后的文件体积，而不是发送端显示的体积。
测试条件：Wi-Fi 上行 20 Mbps、两端均为当期公版；口径为「接收端落盘文件的实际字节数」。
「改成压缩包就一定不会被拦」
打包确实能绕开某些按类型的前置判断，但也把问题转移到了接收端：解压需要空间、需要正确的分卷顺序、需要能识别格式。
拦截可能消失，解压门槛随之出现
本站把 2.4 GB 视频打包成 1.9 GB 压缩包后发送成功 5 / 5，但接收端剩余空间 3 GB 时解压失败 3 / 3；空间 8 GB 时解压成功 3 / 3。
口径：以「解压后文件可正常打开」为成功判定，接收端为同型号手机。
五、按类型选通道的判断流程（5 步）
- 先确定「这份东西对画质有没有要求」。有要求就走文件通道，没有要求走媒体通道。
完成判定：能说出接收端是要「原始文件」还是「看得清就行」。 - 再确认体积落在哪一档。文档类看 1.8 GB 安全线，媒体类看 300 MB 一档。
完成判定：写出文件实际体积与对应档位。 - 选择发送入口并检查是否勾了「按文件发送」。移动端这一步常在二级菜单。
完成判定：发送前截图上能看到通道选项已切换。 - 在接收端核对体积与内容。不要以发送端为准。
完成判定：接收端落盘体积与源文件字节数一致（误差 0）。 - 超过安全线就分卷，而不是硬压。分卷每段不超过 1.8 GB。
完成判定：逐段发送成功，接收端按顺序解压成功。
提醒：识别文件类型时，部分客户端依赖文件头而非后缀名。把视频后缀改成 .zip 会被识别为无效压缩包，反而更难处理；本站测试中 5 次全部失败在接收端打开环节。
六、评分条：类型处理的适配度
结论卡
类型矩阵的核心只有一句话：先分通道，再谈上限。媒体通道管的是「看得见」，文件通道管的是「原样到」。把这句话记住之后，图片糊、视频变差、文档被拦这三类投诉都可以在两分钟内定位到具体是哪一格。
七、三个常见误判
发送端显示 30 MB 不代表对方保存的是 30 MB。本站同一照片两种模式对照，接收端落盘体积分别为 30 MB 与 3 MB，相差 10 倍。
类型识别优先读文件头。本站把 300 MB 视频改成 .zip 后，5 次全部在接收端打开失败，被判定为损坏压缩包。
分卷只解决单段体积，不解决接收端空间。本站分 4 段各 1.55 GB 后，接收端剩余空间 3 GB 时仍在解压第 2 段失败。
相关对照页
类型决定通道，通道决定门槛：各体积档的成功率与失败特征在 文件大小上限 里逐档列出；传完之后对方多久能看到，见 多端同步；转存进收藏夹后的附件落盘情况见 收藏夹；多端并发导致的重复提示与已读回跳见 同步冲突。
八、文件类型问答
怎么让对方收到没有压缩的原图
发送时切到「按文件发送」通道，而不是普通照片模式。本站对照中两种模式接收端落盘体积为 30 MB 与 3 MB，差异全部来自压缩；切换通道后 5 / 5 保持原样。
视频发过去变模糊了是什么原因
走的是媒体通道并触发了转码。本站 300 MB 视频转码后约 120 MB，分辨率与码率同时下降；若必须保真，改用文件通道发送，但体积上限回落到 1.8 GB 一档。
为什么文档类的上限比媒体类高
因为文档走文件通道、按原样接收，不涉及压缩与转码，所以门槛按体积判断；媒体通道要生成缩略图、转码、预加载，成本更高，因此稳定发送档明显更低。
大素材用分卷还是用压缩更实用
看接收端空间。本站 6.2 GB 素材两种方式都成功发送，但压缩成 1.9 GB 单包要求接收端剩余 4 GB 以上；分卷 4 段要求每段解压时留出约 1.6 GB。空间紧张时选分卷。
音频为什么有两档
作为语音或音频消息发送走媒体通道，80 MB 一档且会转码；作为文件发送走文件通道，1.8 GB 以内原样通过。选哪个取决于是否需要无损。
按文件发送会不会更慢
会，因为体积更大。本站 300 MB 视频两种方式耗时分别为 46 秒（媒体通道转码）与 1 分 25 秒（文件通道原样），差距约 1.8 倍。
九、数据口径与免责
本文矩阵与压缩数据均来自本站 2026-10 的本地测试：单账号免费档、桌面端与移动端各 1 台、Wi-Fi 上行 20 Mbps、每类 5 次；压缩耗时为 3 次平均，测试机为 4 核桌面端。
体积门槛会随账号等级、通道与客户端版本变化，因此文中给的是「本站条件下的稳定发送档」，不是官方参数表。接收端解压与保真判断以落盘文件的实际字节数与可打开性为标准。
本站为第三方资料整理站，不托管安装包、不提供账号服务，与 Telegram Messenger Inc. 无隶属关系；测试素材均为本站自建，不含第三方版权内容。