直接结论
截图尺寸规划首先是个覆盖度问题，其次才是设计问题：先决定 listing 必须服务哪些设备类别，按每个类别的最大分辨率制作母版，其余尺寸从母版派生——而不是每次改文案就手工导出全部尺寸。App Store 侧实际的锚点是大屏 iPhone 类别（6.9 英寸档，竖屏 1320 × 2868），以及在支持 iPad 时的 13 英寸 iPad Pro 档（2064 × 2752）；同类别的小尺寸设备 Apple 可以从大图缩放。Google Play 的尺寸更宽松（最小 320 px、最大 3840 px，长宽比不超过 2:1），但奖励一致的构图。由于 Apple 会随新硬件调整接受的尺寸，定稿母版前应在 App Store Connect 核对当前清单。真正昂贵的错误不是像素数写错——上传校验会拦住——而是到提审当天才发现某个语言、某个设备类别或某个商店从来没被规划进去。
先有覆盖矩阵，再谈像素
| 表面 | 母版锚点尺寸 | 派生覆盖 |
|---|---|---|
| iPhone | 6.9 英寸档，竖屏 1320 × 2868 | 更小的 iPhone 档从母版缩放 |
| iPad（如支持） | 13 英寸档，2064 × 2752 | 更小的 iPad 档从母版缩放 |
| Google Play 手机 | 1080 × 1920 或更高（限制内） | 平板和 Chromebook 视需要派生 |
| 每个语言 | 同一套母版，替换文字图层 | listing 上线的每个 locale |
设备类别 × 语言 × 商店相乘：一个双语、支持 iPhone + iPad、双商店上架的应用，从几张母版出发就是几十张最终图。这个乘法就是「母版 + 派生」值得坚持的原因。
推荐流程
1. 设备类别从实际支持范围推导
如果应用没有 iPad 版本，iPad 截图不是「锦上添花可以不做」，而是根本不在矩阵里。覆盖度从二进制包出发，不从野心出发。
2. 母版按类别内最大尺寸设计
按大屏画布排的文字，缩小后依然可读；反过来把小母版放大，得到的是发虚的文字，过不了视觉 QA。
3. 文字图层和产品画面分层管理
本地化改的是文字，不是产品截图。分层意味着换语言只是一轮文字替换而不是重新设计，溢出检查也能聚焦在真正会变的那一层。
4. 导出前核对商店当前要求
Apple 随新设备上市更新接受尺寸，Play 政策也在演进。最终导出前花五分钟在 App Store Connect 和 Play Console 里确认，比被打回一整批便宜得多。
5. 提审日之前验证完整矩阵
每个格子——设备类别 × 语言 × 商店——都应该在提审窗口打开前完成命名、尺寸和评审。提审当天才发现的空格子,就是发布延期。
常见失败模式
母版按最小尺寸设计
放大会让文字和边缘发虚。永远按类别内最大尺寸设计，向下缩放。
本地化截图是事后补救
文字被拍平进图片后，每个语言都变成一次重新设计。团队于是悄悄在非英语商店挂英文截图——恰恰在 listing 最没有根基的市场削弱转化。
矩阵只存在于某个人的脑子里
覆盖情况只靠设计师记忆维持的话，人员变动和赶工发布都会把缺口暴露出来。矩阵应该是一份成文的、每次发布都过一遍的清单。
截图尺寸清单
- 设备类别从二进制包实际支持范围推导。
- 母版按类别内最大尺寸设计，按需覆盖竖屏横屏。
- 文字图层与产品画面分层，方便换语言。
- 已在 App Store Connect 和 Play Console 核对当前尺寸要求。
- 提审日前验证完整矩阵（类别 × 语言 × 商店）。
- 导出文件命名规范，评审者一眼能审计覆盖度。
执行原则
如果你没法把覆盖矩阵列成一张表——每个设备类别、每个语言、每个商店、每格有状态——那截图生产就是在靠运气运转。
为什么这件事适合放进 App Store Helper
App Store Helper 把截图集当作结构化的项目资产：screenshot recipe 只定义一次信息和顺序，各语言变体挂在同一份 recipe 下，而不是散落在设计文件里。覆盖缺口在评审时就显示为可见的空位，而不是提审当天的惊吓。