diff --git a/.workbuddy/memory/2026-10-22.md b/.workbuddy/memory/2026-10-22.md
index f7fe8c4..37d41b6 100644
--- a/.workbuddy/memory/2026-10-22.md
+++ b/.workbuddy/memory/2026-10-22.md
@@ -413,3 +413,15 @@
 - `dev/overlay.json` 原来指向 /tmp 的桩文件（早已失效），改成指向仓库内 `dev/s3stub/s3_stub.go`。
 
 
+
+**第二轮复验（用户重新部署后）+ 换 2x 的替代方案**
+- 部署确认：箱子卡 200，二维码 148px、左右留白 61/61、三处居中偏差 −0.5/0.0/−0.5px。
+- 延迟别拿 HTTP 测：这台机器 **静态 CSS 的 TTFB 就 2.7s**（TLS+代理），分享卡 TTFB 2.4s
+  比静态资源还快，测不出服务端渲染耗时。要测就在本地跑基准。
+- 本地基准（1C1G 上大约 ×3~5）：1x 像素工作 ≈ 40ms（JPEG 12 + 背景缩放 25 + 画布 3），
+  2x ≈ 103ms；**二维码生成只有 0.8ms**，与尺寸无关 → 放大二维码不花 CPU，2x 贵在编码与缩放。
+- 实验（37 模块 / 真实 55 字符链接 / 含头像，gozxing 逐宽度解码）：4px/模块 480 宽就挂，
+  5px 能撑到 320。降纠错 Q→M 只省 11% 模块且容错 25%→15%，不划算；PNG 救不了缩放。
+- 落地 `72f08cd`：`QRCodeSize` 165→190（→185px / 5px 模块）、`QRCardH` 315→335，
+  新增 `TestGenerateQRModuleSizeAtLeast5`（改回 165 立刻 FAIL）。单题卡仍是 150（4px），未动。
+- 比 2x 更值得做的：进程内缓存只有 16 条 + TTL 1h，箱子多时冷渲染频繁 → 结果落盘/R2。
diff --git a/.workbuddy/memory/topics/share.md b/.workbuddy/memory/topics/share.md
index 83135e3..5ee4bbd 100644
--- a/.workbuddy/memory/topics/share.md
+++ b/.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 更实在的优化方向。
 
 ## 验证手法