docs(memory): 分享卡模块像素实验矩阵与 2x 成本基准

.workbuddy/memory/topics/share.md

@@ -17,13 +17,30 @@
   把 4 模块静默区画进图里 + 再居中留白，会让 165px 目标只剩 111px（3px/模块）——这是曾经的回归。
 - `perModule = size / modules` 向下取整，符号 = `modules*perModule`；**调用方必须用 `qr.Bounds().Dx()`
   排版与居中**，不能假设等于传入的 size。
-- 单题卡 `QQRSize = 150`（37 模块 → 4px）；箱子卡 `QRCodeSize = 165`（37 模块 → 148px）。
+- 单题卡 `QQRSize = 150`（37 模块 → 4px）；箱子卡 `QRCodeSize = 190`（37 模块 → 185px = 5px）。
 - 卡内垂直间距在 4px 栅格上：`24 / 17 / 20 / 1 / 20 / 16`，总高按链接行数算，整块垂直居中。
 
-## 实测上限
+## 模块像素：唯一的硬指标
 
-960 宽下 4px/模块是当前结构的上限；缩到 480 宽（微信/QQ 常见展示尺寸）模块只剩 2px，
-gozxing 解不出。要真正抗二次压缩只能 2x 渲染（1920×1080），1C1G 要先测 CPU。
+| 模块 | 960 | 720 | 480 | 320 | 240 |
+|---|---|---|---|---|---|
+| 4px（148px，37 模块） | o | o | **x** | x | x |
+| 5px（185px，37 模块） | o | o | o | o | x |
+
+（go-qrcode 纠错 Q、真实 55 字符链接、含内嵌头像；用 gozxing 解码，它比手机严格，可当保守下限。）
+→ **目标 5px/模块**；`TestGenerateQRModuleSizeAtLeast5` 锁住三种常见链接长度，改小 QRCodeSize 立刻 FAIL。
+
+改大模块的路线排序（成本从低到高）：
+1. 同画布放大二维码（已做，0 CPU）——`generateQR` 只 0.8ms，与尺寸几乎无关。
+2. 降纠错 Q→M：模块 37→33 只省 11%，容错 25%→15%，不划算，别单独用。
+3. 换 PNG：只保住原图，缩到 480 一样解不出，体积还是 JPEG 的 5 倍。
+4. 2x 渲染：+60~100ms（本地基准：JPEG 编码 12→48ms、背景 Lanczos 25→41ms、画布 3→13ms）。
+   只在「原图本身也要更精细（背景/文字抗锯齿）」时值得。
+
+## 缓存命中率才是 2x 之外更值得看的地方
+
+进程内 LRU 只有 16 条 + TTL 1h，站点箱子多时冷渲染频繁；把生成结果落盘 / 上 R2
+能让「贵」只付一次。这是比 2x 更实在的优化方向。
 
 ## 验证手法