这篇解决什么问题

场景:你在公众号后台传了一张 2.35:1 的头图,会话列表里看着没问题,文章顶部也挺好,结果同事转发到群里,卡片上的标题只剩半截,主体还跑没了。

交付物:一张十行症状对照表,一张三个展示位的要求对照表,一套能同时满足三处的构图与文字区参数,以及一条上传前的自检清单。

这篇不解决什么:不讲头图的标题文案怎么写,不讲配图选型和插画风格,不涉及视频号和小程序封面。另外,本文引用的尺寸全部来自公开分享文章而非微信官方规格文档,后台界面可能已经调整,请以你后台当前的实际裁切框为准。

症状对照表

头图的问题几乎全部来自同一件事:一张图要在三个比例完全不同的地方被看,而这三个地方没有“兼顾”这一说,只有“先满足最苛刻的那一处,再回头补另外两处”。对公众号头图来说最苛刻的是分享卡片——它是方形、尺寸最小,而且你完全无法预测读者在什么光线下、用什么手机看。下表左列是现象,中列是根因,右列是改法。

症状为什么会这样怎么改
转发到群里,标题只剩半截分享卡片按 1:1 从画面中间裁,标题排在左右两侧核心标题整体锁进画面中央的方形安全区
分享卡片里主体直接消失主体放在画面一侧,被方形裁切切掉主体的视觉中心也进中央方形,只让背景纹理向两侧延伸
头图在列表里发虚原图分辨率不足,或被平台压成小缩略图(第三方引述社区文章提到可能压到 640px 宽,非官方文档)按不低于 900×383 出图;导出 JPG 质量 90% 以上或直接给 PNG
文章顶部横图两侧空得突兀只对中央方形区做了设计,两侧没铺内容左右两侧铺满背景纹理或渐变,不留死白
主页小图里字号太小读不出字号是按 2.35:1 大画布的观感定的字号按分享卡片的方形宽度反推,不按大画布定
上传后颜色发灰发暗色彩空间或二次压缩导出为 sRGB,控制文件大小;具体阈值以微信当前说明为准
后台框选时方形框跑偏组合图左右两块没分块对齐按 1283×383 组合图制作:左 900 宽做头条,右 383 宽做分享
文字压住人物脸部先出图后找地方加字出图阶段就指定留白区,文字区不参与生成
同一个号头图风格飘忽每篇都重新想构图固定一套模板:同构图、同字号档位、同色板
缩略图里小字糊成黑点日期、栏目名这类小字在方形尺寸下必然糊缩略尺寸下只保留主标题,小字要么删掉要么接受它糊

把上面十行收敛成一句话就是:中央方形是“必须活下来”的区域,左右两侧是“只在文章顶部才被看到”的加分区域。据此可以把构图参数直接写死:

头条画布:900 × 383 px(2.35:1)
中央安全区:383 × 383 px,水平居中(左右各余约 258px)
必活内容:主标题、主体视觉中心 —— 只放进中央安全区
加分内容:背景纹理、渐变、装饰 —— 铺满左右两侧,可延伸出画布
字号参考:主标题在 900 宽画布上不低于 64px
         (按方形 383/900≈0.43 折算后约 27px,为本人推导值,非规定)
字数参考:主标题 ≤10 字,这条没有官方口径,是我按方形可读性取的值

验收:把成品裁成中央 383×383 单独存一份,主标题完整、主体可辨、没有糊成黑点的小字;再放回 900×383 看,两侧不空、不突兀。

三类典型情况怎么套

三个展示位的要求并不一致,优先级也不同。下面这张表是本文的核心,做图时按最苛刻的那一列倒推。

展示位看到的形态尺寸口径约束重点
文章顶部与订阅号列表2.35:1 横幅推荐 900×383(微信开放社区开发者分享文章,2025-04-09)两侧要有内容,构图要撑得住宽屏,避免中央一块图两侧死白
分享卡片(转发到聊天、朋友圈)1:1 方形,从画面中间裁推荐 383×383(同上)最苛刻的一处:标题和主体必须在中央方形内,且字号按方形定
公众号主页1:1 方形小图与分享卡片同一张(同上)和分享卡片共用一套安全区,不需要单独做,但要在主页列表里和相邻文章并排看一遍

组合做法:做一张 1283×383 的图,左边 900×383 是头条横幅,右边 383×383 是分享方形,上传后在后台拖动裁切框分别框选两块。这个做法来自开发者社区的分享文章,不是官方功能说明,后台界面可能已变,以你实际操作为准。

顺序也要注意:先按分享卡片的方形把中央安全区做完,再把两侧补成完整的 2.35:1,最后在手机上把三个展示位各看一遍。反过来做几乎一定会返工,因为在宽画布上排得越顺手,方形里越容易废。

自检清单

下面这份清单按“从最苛刻倒推”的顺序排,跑完一遍大约两三分钟。前两项最常被跳过,而它们恰好对应最常翻车的两条。

□ 成品已按中央 383×383 裁出一份,主标题完整、主体可辨
□ 主标题字号在 900 宽画布上 ≥64px,且方形版本里读得清
□ 主标题 ≤10 字,无栏目名、日期等小字出现在中央方形内
□ 文字未压住主体,文字区在出图阶段就已预留
□ 左右两侧铺满背景或纹理,无死白
□ 导出为 sRGB,JPG 90%+ 或 PNG,文件不超过后台限制
□ 组合图(如使用)左 900 右 383 分块对齐,无错位
□ 已在手机上实际预览三个展示位,不只在电脑上看

翻车与补救

最常见的翻车是“只按 2.35:1 设计”。你在宽画布上排得很舒服,一进方形就废。补救办法不是重做,而是先裁出中央方形,把标题在方形里重排一次,再回填到横幅;如果方形里排不下,说明标题太长,删字。

第二个是“分享封面和头条封面各做一张,风格对不上”。两张图用了不同的配色或字体,主页点进去会有割裂感。补救办法是做成组合图,或者至少锁定同一套色板和字体。

第三个是“后台裁切框位置变了”。分享封面的框选位置在不同时期、不同账号类型上存在差异,社区里也有相关反馈。补救只有一条:每次发布前在后台预览一遍,并真的转发到群里看一眼卡片,别假设上次对这次也对。

下一步

把中央方形安全区的参考线、主标题字号档位和两侧纹理的做法存成模板,之后每篇只换标题文字和主视觉。跑十篇之后头图的耗时主要就剩选图和改字,三个展示位的适配会成为默认动作而不是每次重想的难题。

资料来源与整理日期(2026-10-04):头条封面 2.35:1 / 900×383、分享封面 1:1 / 383×383、1283×383 组合图做法,来自微信开放社区开发者分享文章(2025-04-09)及二手转述博客,均非微信官方规格文档;封面小于 10MB、大图可能压至 640px 宽缩略图为第三方转述,未找到官方原文,未核实;主标题字号与字数为本人按方形比例推导的建议值,非任何平台规定。全文未做本人实测。

声明:1.本站所有文章,如无特殊说明或标注,均为本站原创发布。本网站中【文本生成/文生图】使用了DeeSseek人工智能生成内容技术, 算法来源说明:本网站未自行开发、训练或部署深度合成算法,所使用的人工智能算法来自:DeepSeek、Chatgpt、Google Gemini。 2.为了网站加载速度优化,本站预览图片进行压缩处理,所以有些不是太清晰,并不影响AI提示词生图、AI设计等内容。3.任何个人或组织,在未征得本站同意时,禁止复制、盗用、采集、发布本站内容到任何网站、书籍等各类媒体平台。如若本站内容侵犯了原著者的合法权益,可联系我们进行处理。--GUUNN.COM