为什么「MOV 明明只有二十兆」却仍被 Exchange 退回，还提示附件过大或扫描超时？
用户常搜「mov 太大 发邮件」「outlook 附件 限制」「企业邮箱 退回」「iphone 录屏 mov 体积」「smtp base64 膨胀」——真正卡人的往往不是 Finder 里看到的整数兆字节，而是传输编码、网关二次压缩与杀毒排队。MOV 容器里若是 HEVC 或高帧率 H.264，Windows 侧解码与硬件白名单也可能让「能发」不等于「能开」。邮件场景下更理性的策略是：把宽度锁在对方显示器可读的 720p 或 1080p 档，压峰值码率让 scrub 不卡，再刻意留百分之二十以上余量应对 Base64 与策略扫描；超过一分钟的培训录屏默认不该硬塞进附件。另，压缩是有损的：合同若要求与送审母带一致，应在文件名写「派生审阅版」并保留原始哈希，而不是把工程唯一源覆盖成「能发出去的那版」。
邮件场景：把 MOV 压到「网关放行 + 对方笔记本可播」的推荐顺序
- 在剪辑或相册先裁到真正需要签字的段落，关掉无关音轨与画中画小窗，再导出短 MOV；避免把整场全员大会一次性丢进浏览器，既省内存也减少误发敏感画面。
- 在压缩页选择邮件向档位，优先下调宽度与峰值码率而不是盲目拉到极低帧率；若正文含小字 KPI，请在本地全屏暂停核对可读性后再生成附件。
- 发信前用对方同类操作系统试开一遍，并在邮件正文写明分辨率、编码与「非母带」声明；原母带走网盘对象存储互链校验和，附件只承载审阅代际。
压缩 MOV · 邮件网关常见问答
我把 Finder 显示二十三兆的 MOV 作为 Outlook 附件发出，仍被退回提示超过二十五兆限制，这是否通常与 Base64 传输编码膨胀或网关按传输字节计数有关，而不是 Finder 骗我？
很常见：MIME 传输层会显著放大字节；不同网关还会在扫描缓存里暂存多副本。应把目标体积压在阈值下方留出安全余量，长素材改外链，而不是反复在同一阈值上赌博。
收件人使用受管控的 Windows 笔记本双击 MOV 只有声音没有画面，我是否应该在邮件里同时附一份同内容的 MP4 作为兜底，还是坚持只发 MOV？
应以对方 IT 白名单为准：若政策明确优先 H.264-in-MP4，应准备双格式并在正文写清默认打开哪一个；仅改扩展名或只压体积而不改编码族，往往解决不了黑屏问题。
法务要求对外邮件附件必须可审计哈希，我在浏览器压缩后是否可以直接覆盖网盘里的旧 MOV 而不更新工单附件表？
不应：每次派生都应写入新对象键、哈希与操作者时间戳；覆盖旧对象会导致审计链断裂，尤其在争议交付或劳动仲裁举证场景。
同一封邮件需要抄送五位领导，我是否可以把五份相同 MOV 作为五个附件分别挂上以「确保每个人都下载到」？
这通常成倍放大网关压力并可能触发重复病毒扫描超时；应使用单一外链加权限控制，或在正文放一次附件并说明其余人从内网盘自取。
客户口头说「糊一点没关系只要小」，我是否可以在未留书面确认的情况下把码率砍到文字完全不可读以硬凑邮箱限制？
口头免责不等于合同变更；应保留小样截图与邮件确认，或在参数表上让客户勾选可接受的最小可读宽度，避免事后以「看不清数据」拒收。