From 3e910f1ca05ec9c42aa44644017d741b43821dc1 Mon Sep 17 00:00:00 2001
From: laoyang <i@yangyq.net>
Date: Wed, 28 Oct 2026 10:49:20 +0800
Subject: [PATCH] =?UTF-8?q?docs(card):=20=E5=88=A0=E6=8E=89=E3=80=8C?=
 =?UTF-8?q?=E6=A0=BC=E5=AD=90=E6=95=B0=E4=B8=8E=E5=9B=BE=E6=95=B0=E9=87=8F?=
 =?UTF-8?q?=E6=B0=B8=E8=BF=9C=E7=9B=B8=E7=AD=89=E3=80=8D=E8=BF=99=E5=8F=A5?=
 =?UTF-8?q?=E9=94=99=E8=AF=AF=E6=96=AD=E8=A8=80=20#3?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

上一版（工单 #2）在这里写「这样"格子数"和"图数量"在结构上永远相等」。
这句话是错的，也正是工单 #3「21 格」的思想源头：

  keys 按 poster **去重**收集、还卡 20 张上限
  list 按 **行** 过滤、无上限，还会再裁偶数

两个集合基数不可能恒等，正确的说法只是「≤，不是 ==」。
把错误的断言留在注释里，下一个人会照着它推理，再踩一次同样的坑。

本次只改注释，无逻辑变更（守卫 1324/0、v97 反证 13/0 均通过）。
---
 entry/src/main/ets/data/FbCardMediaData.ets | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/entry/src/main/ets/data/FbCardMediaData.ets b/entry/src/main/ets/data/FbCardMediaData.ets
index 8b6f51c..46b7387 100644
--- a/entry/src/main/ets/data/FbCardMediaData.ets
+++ b/entry/src/main/ets/data/FbCardMediaData.ets
@@ -246,9 +246,12 @@ export async function fbMovieCardBuild(ctx: common.Context): Promise<FbMovieCard
                     纯文本列表，30 条都可以留着，滑得动就行。
        · `list`  → `listJson`，给 **4×4 / 6×4 海报墙**。这是两列大图，
                     **没图的格子就是一块淡紫占位**，等于坏格。
-                    ⇒ 只保留**真的配到图**的行，长度天然 ≤ `CARD_IMG_MAX`。
-                    这样"格子数"和"图数量"在结构上永远相等，
-                    就算某张海报 404、或某条本来就没 `poster_key`，也不会冒出一个空格子。 */
+                    ⇒ 只保留**真的配到图**的行，长度 ≤ `CARD_IMG_MAX`。
+                    ⚠️ 注意是 **≤，不是 ==**：`keys` 按 poster 去重收集，
+                    `list` 这一版也按 poster 去重（工单 #3），两边基数才对齐；
+                    但它们**不是同一个集合**（`keys` 卡 20 张上限、`list` 还会被裁偶数），
+                    别写成"结构上永远相等"——v95 就是这么写的，然后长出了 21 格。
+                    只要保证"每格都有图"即可，具体条数以 `list` 自己的去重+裁剪为准。 */
   const bag: FbImageBag = await fbAttachPosters(ctx, token, rows);
   out.formImages = bag.formImages;
   out.imgFds = bag.imgFds;