那天检查一张书单视频封面时，原图看起来没有任何问题。画布是常见的 9:16，标题完整地放在画面里，导出预览也没有被边框遮住。可一发布到另一个平台，打开个人页的九宫格，标题的上半截不见了。
第一反应很容易落到字体、字号或文案上：是不是字太大了？是不是行距不够？是不是导出时压缩出了问题？但重新看原图以后，这些猜测都站不住。标题不是没有渲染出来，而是在平台展示封面时，被另一套裁切规则切掉了。
这次问题最后落在一个很小、但很关键的差别上：原来的渲染器沿用了视频号的安全区，关键信息靠近顶部；而目标平台会把 9:16 封面在个人页九宫格里居中裁成大约 3:4。原图里属于“画布范围”的顶部，在九宫格里并不一定属于“可见范围”。
原图完整，不等于发布后完整
我一开始把“文字没有超出 9:16 画布”当成了验收标准。这个标准在单个平台、单种展示方式下或许够用，但一旦同一张图要进入不同平台，它就只验证了最表面的一层：文件有没有生成，元素有没有落在原始画布内。
平台展示的过程还会继续改变这张图。目标平台对 9:16 封面做居中约 3:4 裁切，意味着上下各有一部分区域可能被隐藏。根据这次已经核对过的规格，顶部 y<288 的文字存在被裁掉的风险。原先把标题放在 y=216 附近，在视频号安全区里是合理的，在九宫格里却已经落进了危险带。
封面设计的安全边界，不是原始画布的边界，而是目标平台最终展示出来的可见边界。
如果不处理这个差异，后果不只是某一张图难看。标题可能只剩半行，读者在缩略图里无法理解主题，后续再去检查字体、重新导出、反复改文案，都会变成围绕错误原因打转。更麻烦的是，原图和视频播放页看起来都正常，问题只在个人页或列表页出现，人工验收很容易漏掉。
真正的问题是安全区错配
把现象说成“平台把封面裁了”还不够。平台裁切本身并不是异常，它只是按照自己的展示比例工作。真正需要修复的是渲染器没有把平台作为输入条件，因此默认所有 9:16 封面都共享同一套安全区。
原先的逻辑更像是：先做一张标准竖图，再把它交给不同平台。这个顺序隐藏了一个假设——不同平台会以相同方式展示这张图。只要这个假设成立，统一模板确实省事；一旦不成立，模板越稳定，错误反而越容易批量复制。
这件事让我重新意识到，尺寸不是规则，尺寸只是规则的一个表面结果。两个平台都接受 9:16，不代表它们会保留同样的顶部和底部区域。真正应该被保存的，是“这个平台会怎样看这张图”这一层判断。
最容易误判的错误捷径，就是只在原始 9:16 画布上看一眼，确认标题没有被画布边缘遮住，就默认所有平台都安全。这个捷径看起来很高效，因为它确实能快速筛掉明显越界的图片；但它完全没有验证平台裁切后的状态。
先把裁切模型写出来
我选择先定义平台裁切模型，再调整文字位置，是因为只有先知道“最终会看到哪里”，安全区才不是凭经验画出来的框。对于这次的目标平台，9:16 画布会在九宫格中居中展示为约 3:4，因此顶部一段区域不能继续承担标题信息。
接着，把文字块当成一个有边界的矩形，而不是只检查文字中心点。参考已经验证过的规格，目标平台的文字安全交集约为 x∈[180,900]、y∈[300,1440]。标题、书名和必要说明都必须落在这个交集里，只有中心点在里面而文字边缘越界，仍然算失败。
另一个平台仍然保留原有的视频号安全区。它的行为不能因为修复另一个平台而被顺手改掉，所以渲染器需要支持 douyin 和 shipinhao 两套平台参数，并默认使用项目配置指定的平台。这样做的理由很实际：平台差异被显式写进输入，渲染过程才不会靠操作者记忆某个模板到底适用于哪里。
表面上我是在给渲染器加一个参数，其实是在把过去藏在代码里的设计判断拿出来。参数并不只是切换按钮，它还让每一次输出都能回答一个问题：这张图究竟是按照谁的展示规则验收的？
让越界在生成时就失败
安全区定义好以后，还需要一个明确的失败方式。若文字越界时只是打印一行提醒，批量产线很可能继续生成文件，操作者也可能因为赶进度而忽略提示。最后留下的不是一个待修复的错误，而是一批已经流向发布环节的风险素材。
所以这次的验收要求是 fail-loud：渲染前计算每个文字块与当前平台安全区的交集，只要有文字块超出边界，就直接失败，不生成看似可用的成品。失败信息要说明目标平台和越界方向，让人知道是顶部、底部还是左右边界出了问题，而不是只得到一个模糊的“渲染失败”。
一个可靠的产线，不应该把明显不安全的图片交给人去碰运气；它应该在越界发生时主动停下来。
这里有一个容易被忽略的边界：文字不是唯一需要检查的对象，但这次先守住文字块是合理的最小修复。标题是这次实际被裁掉的信息，也是平台安全区最直接的承载物。把图片中所有装饰元素都纳入同一套限制，会扩大改动范围，却不一定改善当前问题。
我没有直接把所有内容都强行缩小或整体下移，是因为那会把一个平台的修复变成所有平台的视觉变化。更稳妥的方式是让平台参数决定安全区，在文字放不下时失败并提示，再由排版逻辑根据当前平台重新布局。这样既能保护视频号已有行为，也能让目标平台获得自己的安全版式。
用裁切预览做最后回归
越界检查验证的是几何关系，但人最终看到的是裁切后的画面。因此这次验收还需要额外生成格子裁切预览，把原始封面按目标平台的展示方式实际裁一遍。预览的价值不在于好看，而在于把“平台可能怎么显示”提前变成一张可以直接检查的证据。
回归时，我会用同一份书单文案分别跑两套平台参数。先看视频号结果是否保持原有位置和视觉行为，再看目标平台的九宫格预览中，标题是否完整落在可见区域。两张图使用相同文案，差异只来自平台安全区，这样才容易判断修复到底解决了什么。
如果只生成目标平台的安全图，却不保留裁切预览，仍然可能出现一种假通过：渲染器认为文字在安全区里，但实际展示组件存在不同的缩放或对齐方式。预览不能替代规则检查，却能把规则与最终画面连接起来。一个负责提前阻止错误，一个负责确认用户真正会看到什么。
这件事让我重新意识到，视觉验收也需要像功能验收一样有回归样本。原图是输入，安全区是约束，裁切预览是结果。三者缺一不可，否则我们很容易把“文件生成成功”误认为“发布效果正确”。
下次我会怎么做
下次再做跨平台封面，我会先问展示页面怎么裁，而不是先问画布应该做多大。确定平台和展示位置后，先建立裁切模型，再把标题、人物和其他不可丢失的信息放进安全区，最后才处理字体、颜色和装饰。
我会把平台作为渲染参数保存下来，让默认值来自项目配置，而不是来自某个操作者当时的记忆。对每个文字块做边界交集检查，越界就明确失败；对关键平台生成实际裁切预览，把九宫格、列表页或其他缩略展示纳入回归。
一个流程成熟的标志，不是它能把原图做出来，而是它能在发布前证明不同平台看到的仍然是同一条关键信息。
表面上，这只是一次封面被裁掉的修复；实际上，我是在重新划定“完成”的定义。完成不再是渲染器吐出一张图片，而是这张图片经过目标平台的展示规则之后，标题仍然完整、位置仍然可读、旧平台的行为也没有被无意改变。
我更愿意把它看成一种工作习惯，而不是一个技巧：凡是中间还有展示、缩放、裁切或转码的环节，就不能只验收中间文件。真正需要验收的，是最后一个环节里的用户视野。