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