主题
你的 PPT 为什么有 80MB
一份三十页的演示文稿动辄七八十兆，发邮件被退回、上传被拒。体积几乎全部来自图片，而且多半是你以为已经处理掉的那些。
三个隐形的体积来源
裁剪不等于删除。 在 PPT 里裁剪图片，默认只是隐藏了裁掉的部分，原始像素仍然存在文件里。你把一张 4000 像素宽的图裁到只显示中间一小块，文件里存的还是完整那张。
删除不等于清除。 从页面上删掉的图片，可能仍留在文件的媒体资源里——尤其是曾经出现在母版、备注页或被复制粘贴过的图。
尺寸远超显示需要。 一张手机拍的 4000×3000 照片，放进幻灯片里显示宽度可能只有 10 厘米。按投影和屏幕的实际像素密度，1600 像素宽已经绰绰有余，多出来的部分纯属浪费。
这三条叠加起来，就是几张图撑出几十兆的原因。
先确认体积到底在哪
动手压之前值得花一分钟定位。PPTX 文件本质上是个 zip 压缩包，把扩展名改成 .zip 解开，里面的 ppt/media/ 目录装着所有图片和视频，按大小排一下就能看到是哪几个文件占了大头。
这一步经常会有意外发现：占掉四十兆的可能是某页里一段忘了删的视频，或者是一张被缩到角落当装饰用的高清背景图。找到这一个文件替换掉，比对全部三十页做一遍压缩更省事，也不会牺牲其他图片的质量。
压缩的正确顺序
先按显示尺寸重采样，把每张图缩到实际需要的分辨率。这一步收益最大。
再清理未引用的资源，把留在文件里但页面上看不到的媒体删干净。
最后才考虑降低图片质量。前两步做完通常已经够了；如果还不够，再动质量参数，此时降幅也有限。
顺序反过来做——先狂降质量——的结果是图片糊了，体积却只降了两三成，因为大头在尺寸和冗余资源上。
什么时候该转成图片
有些场景与其发 PPT，不如发图片或 PDF：
- 对方只是要看，不需要编辑；
- 你用了特殊字体，担心对方机器上没有导致版式错乱；
- 需要发到微信、社交平台这类不方便打开 PPT 的地方。
每页导出成图片，版式就被固定下来了，不会因为对方的软件版本或字体环境而变形。代价是对方改不了——这在很多场景里恰恰是优点。
字体是另一个变量
体积之外，PPT 最常见的事故是换台电脑打开就版式全乱。原因通常是字体：你用的字体对方机器上没有，软件自动替换成默认字体，而中文字体的字宽差异会让每一行的换行位置全变。
三种应对方式，可靠性递增：
- 只用系统自带字体（微软雅黑、宋体等），最省事但设计受限；
- 把字体嵌入文件，可靠但会显著增大体积，且部分字体授权不允许嵌入；
- 导出成图片或 PDF，版式彻底固定，代价是不可编辑。
要发给不确定环境的对方时，第三种最稳妥。
SVG 也需要清理
矢量图形是另一个容易被忽略的体积来源。设计软件导出的 SVG 往往带着大量冗余：编辑器的私有属性、无用的元数据、精度过高的坐标（小数点后十几位）、以及从来没被引用过的定义块。
清理掉这些，体积常常能降到原来的三分之一甚至更低，而渲染结果完全一致。用在网页上时这个差别很直接——SVG 通常是内联在 HTML 里的，它的体积会直接计入首屏。
封面尺寸不要靠猜
每个平台对封面图的尺寸和比例都有自己的要求，不合规的结果是被自动裁切——而自动裁切几乎总是从中间裁，你精心放在左下角的标题就没了。
做封面时按目标平台的规格出图，比出一张再各处适配省事得多。
顺带一提：CSS 效果不必手写
做网页版的展示物料时，渐变、阴影、圆角、滤镜这些效果的参数很难凭想象写对——阴影的四个数值分别控制什么、渐变的角度怎么算，手写往往要反复刷新调试。
可视化调参再复制代码，比对着文档试快得多，尤其是多层阴影这种参数一多就绕的情况。