logo科技微讯

微信公众号图片上传 API 压缩规则调查报告

作者:科技微讯
日期:2026-08-01
📝 笔记

1. 结论摘要

格式 像素尺寸规则 文件内容规则
JPEG 等比缩放,使宽 ≤ 1280 且 高 ≤ 16383(= 2¹⁴−1);未超限则尺寸完全不变 总是被重新编码,有质量损失(文件约减半)
PNG 任何尺寸都完全不变(宽、高均不限) 原样直存,字节数与上传前逐字节相同,透明通道保留

额外硬性限制:图片高度 ≤ 29999px,否则上传直接失败(两种格式、两个接口一致,报 system error / invalid image format)。

两个接口(uploadimgadd_material)在全部测试中行为完全一致,无差异。

2. 测试方法

  1. 用 PIL 生成测试图,每组同时输出 JPEG(质量 90)和 PNG(RGBA,含半透明色块 + 红色边框用于检测裁剪和格式转换):
    • 常规尺寸:3000×20002000×16002400×2400600×400
    • 超宽矮图:3000×200
    • 窄高图:800×2000(宽 < 1280、高 > 1280,用于判别压缩规则)
    • 极窄超高:300×3000
    • 宽度恰为 1280:1280×2000
    • 宽度边界:1280×8541281×855
    • 极端宽高比:1200×200001200×260001200×290001200×290011200×299991200×30000600×5000020000×20
  2. 每张图分别通过 media/uploadimgmaterial/add_material 上传。
  3. 下载返回的 URL,用 PIL 核对实际像素尺寸、文件格式、文件大小、边角像素、透明通道。
  4. 对高度上限用二分法精确定位(29000 成功 / 30000 失败 → 补测 29001、29999)。

3. 实测原始数据(节选)

原图尺寸 格式 uploadimg 返回 add_material 返回
3000×2000 JPG 1280×853 1280×853
3000×2000 PNG 3000×2000 3000×2000
3000×200 JPG 1280×85 1280×85
3000×200 PNG 3000×200 3000×200
800×2000 JPG 800×2000(不变) 800×2000(不变)
800×2000 PNG 800×2000 800×2000
300×3000 JPG 300×3000(不变) 300×3000(不变)
300×3000 PNG 300×3000 300×3000
1280×2000 JPG 1280×2000(不变) 1280×2000(不变)
1280×2000 PNG 1280×2000 1280×2000
1280×854 JPG 1280×854(不变) 1280×854(不变)
1281×855 JPG 1280×854 1280×854
2400×2400 JPG 1280×1280 1280×1280
2000×1600 JPG 1280×1024 1280×1024
600×400 JPG 600×400(不变) 600×400(不变)
1200×20000 JPG 983×16383 983×16383
1200×20000 PNG 1200×20000(不变) 1200×20000(不变)
1200×29999 JPG 655×16383 655×16383
1200×29999 PNG 1200×29999(不变) 1200×29999(不变)
1200×30000 JPG/PNG 上传失败 上传失败
600×50000 JPG/PNG 上传失败 上传失败
20000×20 JPG 1280×1 1280×1
20000×20 PNG 20000×20(不变) 20000×20(不变)

(所有 PNG 测试均为原样返回,未逐一列出;JPEG 与 PNG 在两个接口下结果完全相同。)

4. 规则详解

4.1 JPEG 尺寸规则

JPEG 按等比缩放,使图片同时满足两个约束:宽 ≤ 1280、高 ≤ 16383(= 2¹⁴−1)。

scale = min(1, 1280 / 原宽, 16383 / 原高)
输出宽 = round(原宽 × scale)
输出高 = round(原高 × scale)
约束 触发条件 例证
宽 ≤ 1280 宽 > 1280 时等比缩到宽 = 1280 3000×20001280×8533000×2001280×85
高 ≤ 16383 高 > 16383 时等比缩到高 = 16383 1200×20000983×163831200×29999655×16383
两者都超 取更小的缩放比例 20000×201280×1(宽触发)

要点:

  • 16383 = 2¹⁴ − 1,是典型的 16K 限制,说明压缩是平台 CDN 的统一图像处理。
  • 宽度边界严格为 1280:1280×854 原样返回,1281×855 被压为 1280×854
  • 缩放为等比缩放,长宽比保持不变(极端比例下受像素取整影响,如 20000×20 缩为 1280×1——高度 1.28 取整为 1;一般比例下误差 ≤ 1px)。
  • 超高图(高 > 16383)即使宽度没超 1280 也会被压缩,这是初始调查未发现、经补测确认的规则。

4.2 JPEG 质量规则

  • 无论尺寸是否被压缩,JPEG 总是会被重新编码,存在二次质量损失。
    • 例证:600×400(尺寸不变)文件从 11,039 字节变为 5,086 字节;纯色红边 (255,0,0) 变为 (247,0,0)

4.3 PNG

  • 任何尺寸(包括 3000×20001200×2000020000×20)像素尺寸完全不变。
  • 文件与原图逐字节相同(如 28,438 字节 = 28,438 字节),即原图直存,零处理。
  • 透明通道(RGBA)完整保留,不会被转成 JPEG。

4.4 上传高度硬上限

  • 图片高度 > 29999px 时上传直接失败system error / invalid image format),两种格式、两个接口一致。
  • 边界:1200×29999 成功,1200×30000 失败。
  • 注意:这与"高 > 16383 被压缩"是两回事——16383 是压缩处理阈值(图片仍能上传,只是被等比缩小),29999 是上传硬性上限(直接失败,无任何返回 URL)。
  • 该上限与像素总量无关:1200×29000(3480 万像素)成功,600×50000(3000 万像素)失败——判定只看高度。

5. 关于"600 万像素会被压缩"的说法

证伪。 3000×2000 的 PNG 恰好是 600 万像素,上传后既没有变尺寸、也没有变文件字节。该说法与实测结果矛盾,不应作为设计依据。

6. 实践建议

6.1 判断是否会被压尺寸(JPEG)

scale = min(1, 1280 / 原宽, 16383 / 原高)
if scale >= 1  → 尺寸不变
else           → 等比缩小,输出宽高按 scale 缩放(向上取整误差 ≤ 1px)

6.2 上传策略

  1. JPEG 且宽 ≤ 1280、高 ≤ 16383:尺寸不会被压,但仍有质量二次压缩,如对清晰度敏感需提高原图质量或换 PNG。
  2. JPEG 且宽 > 1280 或高 > 16383:会被等比压缩。想保留原分辨率 → 先转成 PNG 再上传(实测 100% 保留尺寸与画质)。
  3. PNG:任何尺寸直接传,无压缩顾虑。
  4. 任何格式高度 > 29999:无法上传,必须先本地等比缩小到 29999 以内(转 PNG 也救不了)。

6.3 注意事项

  • 上传大小限制:uploadimg ≤ 1MB;add_material ≤ 10MB。
  • 真实照片转 PNG 后体积会暴涨(3000×2000 照片可能达 8~15MB),可能超 10MB 上限导致上传失败。需要先用 pngquant 等工具做无损优化(转为 8-bit 调色板),必要时轻微降分辨率。
  • JPEG 转 PNG 后 CDN 加载变慢,需权衡清晰度与加载速度。
  • 检查图片是否被压缩:上传后下载返回的 URL,用 sips -g pixelWidth -g pixelHeight(macOS)或 PIL 核对像素尺寸。

7. 局限性

  • 实测基于单个公众号账号;规则为平台级 CDN 处理(mmecoa.qpic.cn),大概率全平台一致,但未在多账号验证。
  • 未覆盖 GIF、BMP、WEBP 等格式(本次调查范围仅 JPEG / PNG)。
  • 微信后台编辑器、群发流程中的压缩不在本次调查范围内(可能另有处理)。