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

2026-10-22 23:37:04 +08:00
parent 72f08cd7c9
commit d0a1bb8435
2 changed files with 33 additions and 4 deletions
@@ -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。