没有预览需求
照片通道压缩，是为了让图能在气泡里直接显示、快速加载。文档不需要在聊天里渲染，自然没有压缩的动机。
TYPE 02 / 05 · 文档
WhatsApp 网页版文档是唯一一条几乎不改内容的通道
同样一个附件按钮，选「照片」会被压，选「文档」就原样传。这个差别值得记住，因为它是保住原件的唯一入口。
WHY
为什么它不压缩
三个原因叠在一起。理解了这三点，就不会再问「为什么照片不能像文档那样发」。
内容类型未知
压缩需要知道内容是什么——是一张图、一段音频还是一份表格。文档通道不知道也不关心，只能当字节流搬过去。
用途是「拿走」
发文档的人，目的是让对方拿到一个能用的文件。改动内容等于破坏用途，所以设计上就不做。
代价是直观性。原样送达换来了一个文件图标。对方看不到缩略图，必须点下载。这个交换在「要保原件」的场景里是划算的，在「让对方看一眼」的场景里就多余。
LIMITS
四种限制，第一条最常见
具体数值会随版本调整，所以这里只给判断方法，不给死数字。
| 限制 | 表现 | 怎么判断 |
|---|---|---|
| 单文件大小 | 超过上限直接传不上去，或一直停在进度条 | 换一个小文件试，能过就是超限了 |
| 总存储 | 长期不下载的记录会被清理 | 往回翻很久以前的消息，看文件还在不在 |
| 格式兼容 | 能传但对方打不开 | 看对方设备有没有对应软件，不是看能不能发 |
| 网络稳定性 | 大文件上传中断后要重来 | 网页版没有断点续传，中断即失败 |
网页版传大文件比手机端更容易失败，因为它依赖浏览器这条长连接。传的过程中切标签页、休眠、断网，都会让上传从头开始。
FALLBACK
传不上去的时候，三个办法
按「保住内容」的优先级排。第一个最无损，第三个最省事但不是每条路都该走。
-
01
先压缩文件本身，而不是让它被系统压
用压缩软件打包成 zip 或 7z，通常能小一半以上，而且解压后内容一字不差。
这是唯一既减小体积又不损失内容的办法。缺点是对方得会解压。
-
02
拆成几个包分批发
一个大文件夹拆成三份，分三条消息发。对方收齐后一起解压，结果和一次发完一样。
适合内部协作，不适合发给客户——没人愿意收三个包再拼起来。
-
03
换成链接，不走附件
文件放到网盘，聊天里只发一条链接。这样没有大小限制，也不会因为过期被清掉。
代价是对方要点两次，而且链接本身可能失效。重要文件最好两个方式都做。
MISREAD
能传，不等于能看
这是文档通道最容易被忽略的一点，也是收到文件之后最常见的麻烦。
发送成功 ≠ 对方可用
文件确实送到了，但对方设备上没有能打开它的软件。比如发了一个专业格式的设计源文件，对方点开只会看到「无法打开」。
顺手补一句说明
发完加一句「这个是 X 格式，需要装 Y 才能开」。一句话省掉对方半小时的查找。
压缩包里的文件名乱码
跨系统传 zip 时，中文文件名可能变成乱码。这是编码问题，不是文件坏了。用 7z 格式或者重新打包通常能解决。
重要文件给两个版本
一份原件走文档通道，一份 PDF 或截图放在正文里让对方先看一眼。既保住原件，又不用对方先下载才知道是什么。
在 WhatsApp 网页版里，文档只有一个统一的文件图标，不同格式看起来几乎一样。所以「发完补一句说明」这件事，在网页版上比在手机端更重要。