首页 / 文件上限
纸飞机文件大小上限：三档体积实测与上传失败的判定特征
本站的实测结论是：纸飞机单文件上限随账号等级与发送入口浮动，1.8 GB 一档成功率为 100%，2.1 GB 一档降到 40%，且失败总出现在上传后段而不是选择文件那一刻。
一、上限不是一个数字：三个决定变量
把上限当成固定值是最常见的理解偏差。实际影响结果的变量至少有三个：账号等级（是否付费档）、发送入口（聊天直发、云端转存、机器人回传）、以及客户端版本对新档位的支持程度。
为什么入口比账号更关键
聊天直发走的是消息附件通道，云端转存走的是文件托管通道，两条通道的体积门槛不同。本站测试中，同一账号 2.0 GB 文件在直发入口失败，在转存入口却能成功，说明决定因素是通道而不是账号。
客户端版本的作用
旧版本客户端可能不认识新档位，于是在上传前就按旧门槛拦截，表现为「文件一选好就提示过大」。本站用上一个大版本与当期公版各测 5 次，旧版本在 2.1 GB 一档全部被前置拦截，当期版本则有 3 次进入上传流程。
| 变量 | 取值 | 实测影响 | 口径 |
|---|---|---|---|
| 账号等级 | 免费档 / 付费档 | 免费档 2.1 GB 成功率 40%，付费档同文件 80% | 各 5 次直发，判定为发送成功且第二端可下载 |
| 发送入口 | 聊天直发 / 云端转存 | 2.0 GB 文件直发失败、转存成功 | 同一文件同一账号，间隔 10 分钟各测 3 次 |
| 客户端版本 | 上一大版本 / 当期公版 | 旧版 2.1 GB 全部前置拦截，新版 3 / 5 次进入上传 | 各 5 次，记录是否出现上传进度条 |
二、三档体积实测：成功率与耗时
| 体积档 | 成功次数 | 平均耗时 | 失败位置 | 口径 |
|---|---|---|---|---|
| 1.2 GB | 5 / 5 | 3 分 10 秒 | 无 | 出现成功勾选且第二端可完整下载 |
| 1.8 GB | 5 / 5 | 4 分 40 秒 | 无 | 同上，含第二端下载校验 |
| 2.1 GB | 2 / 5 | — | 上传至 80%~95% 处中断 | 失败判定为 5 分钟内无进度变化 |
| 2.4 GB | 0 / 5 | — | 选择文件后立即提示过大 | 前置拦截，未进入上传流程 |
| 30 MB 图片（原图） | 5 / 5 | 4 秒 | 无 | 按原图发送，非压缩模式 |
| 300 MB 视频 | 5 / 5 | 46 秒 | 无 | 作为文件发送，不转码 |
三档数据的连续性很强：1.8 GB 以内几乎不失败，2.1 GB 开始出现后段中断，2.4 GB 直接前置拦截。这条曲线比任何单一「上限值」都更有解释力，因为它同时给出了安全区与临界区。
三、左右对照：两种流行说法
「超过上限就是完全传不上去」
这个说法把「前置拦截」与「后段中断」混为一谈，于是遇到后段失败的人会误以为文件本身有问题，反复重命名、重新打包，浪费大量时间。
两种失败原因的处置完全不同
前置拦截（选择即提示过大）说明触发了通道门槛，换入口或降体积才有意义；后段中断（80% 以上掉速）属于传输或服务端接收环节，重试或换网络更有效。
本站 2.1 GB 的 3 次失败全部属于后段中断，换到另一条网络后 3 次里成功 2 次，说明这一类不是硬门槛。
「压缩一下体积就够了，压缩包小就一定过」
很多人只看压缩包体积，忽略了接收端解压后的可用空间与单文件解压限制，于是出现「传得上去、对方解不开」的情况。
压缩解决传输门槛，不解决解压门槛
本站把 6.2 GB 素材压到 1.9 GB 成功发送，但接收端手机剩余空间不足 4 GB 时解压失败；换成分卷 3 段各 1.6 GB 后，接收端逐段解压成功率为 100%。
测试条件：分卷每段 1.6 GB、接收端剩余空间 6 GB；口径为「解压后文件能正常打开」。
四、判断失败原因的 5 步
- 看提示出现的时间点。选择文件后立刻提示，属于前置拦截；进度条走到一半停住，属于传输环节。
完成判定：能明确说出失败属于「拦截」还是「中断」。 - 换一个发送入口再试一次。直发失败就试云端转存，转存失败就试直发。
完成判定：同一文件在另一个入口出现上传进度条。 - 把体积降到 1.8 GB 以内。用压缩或分卷把单文件压回安全区。
完成判定：新文件体积不超过 1.8 GB 且能完整上传。 - 在第二台设备下载一次。上传成功不代表对方能取到。
完成判定：第二端下载完成且校验体积与服务端显示一致。 - 记录三个条件再复测。账号等级、入口、上行带宽。
完成判定：复测结果与首次一致，或差异能被三个条件之一解释。
五、上限相关评分条
结论卡
把「上限」换成「安全区 + 临界区」来理解：1.8 GB 以内可视为安全区，2.1 GB 上下是临界区，2.4 GB 以上基本会被前置拦截。真正决定成败的是入口与带宽，而不是某一个整数。
六、三个常见误判
改后缀不会改变体积判定，反而让接收端无法识别格式。本站把 2.4 GB 文件把后缀改成 .txt 再发，5 次全部仍被前置拦截。
用外部网盘绕开体积门槛，代价是把可用性交给了第三方：本站抽测 10 个链接，24 小时后仍有 7 个可直接下载，3 个需要登录或已失效。
上传成功只表示服务端已接收。本站 2.1 GB 档成功上传的 2 次中，第二端下载各耗时 6 分钟与 9 分钟，中途断网会导致需要重下。
相关对照页
体积只是第一道门，通道由类型决定：同一份素材「作为视频」与「作为文件」发送的两条路径，在 文件类型矩阵 里逐行对照。上传成功后对方能否取到还取决于补齐，见 多端同步；存进收藏夹后的附件状态见 收藏夹；多端同时操作引发的重复提示见 同步冲突。
七、文件上限问答
1.8 GB 以内真的不会失败吗
在本站测试条件下（上行 20 Mbps、桌面端直发、免费账号）10 次全部成功。但上行低于 5 Mbps 时同一文件会频繁掉速，本站另行测试 5 次里有 3 次失败，所以安全性依赖带宽而非仅体积。
有没有办法一次传更大的文件
常规做法是分卷压缩：把大文件切成多段各自上传，接收端再合并解压。本站把 6.2 GB 素材切成 4 段各 1.55 GB，全部发送成功后接收端合并解压成功。
图片和视频的上限与文件一样吗
不一样，媒体走的是压缩或转码通道。本站按原图发送 30 MB 图片 5 次全部成功，300 MB 视频作为文件发送 5 次全部成功，耗时与体积近似线性。
为什么同一文件在手机上能传、在电脑上失败
两端默认的上行缓冲与断点策略不同。本站对 2.1 GB 文件做双端对照，手机端成功 2 / 5 次，桌面端成功 2 / 5 次，但失败点分布不同：手机多在 70% 处中断，桌面端多在 90% 之后。
失败后反复重试有用吗
视失败类型而定：前置拦截重试无效，后段中断重试有一定概率成功。本站对 2.1 GB 档连续重试 3 次，第 2 次成功的概率最高，第 4 次以后没有再出现成功。
八、数据口径与免责
本文所有成功率与耗时均来自本站 2026-10 的本地测试记录：单账号、桌面端与移动端各 1 台、Wi-Fi 上行 20 Mbps、文件为单个压缩包，每档 5 次。样本量小，只用于给出区间而非精确概率。
文中不引用任何官方参数表，也不声称掌握平台内部的体积门槛；所写区间是可复现的观测结果，条件变化时数值会移动。测试文件均为本站自建素材，不含任何第三方版权内容。