方案报告 v5 · TTL 可见化 / 元数据永久保留 / 全平台统计

现状

• 服务端字段 transfers.expires_at timestamptz NOT NULL（migrations/0001_init.sql:41），创建时写 now + ttl_seconds；ttl_seconds 默认与上限都是 86400，客户端不可改。
• 过期后：内容/状态端点返回 410 TRANSFER_EXPIRED；终结态另有 410 TRANSFER_CONSUMED / 410 TRANSFER_REVOKED；tombstone 被清理后变 404 TRANSFER_NOT_FOUND。
• 用户完全看不到这些：列表里只有发送方/大小/块数，过期与否要等点下载才知道。

改成什么

• 发送列表与接收列表每项右侧加一枚 TTL 胶囊：23 小时后过期 / 42 分钟后过期 / 已过期。
• 已过期项：整行灰化 + 文件名删除线 + 胶囊 已过期，无法取回，下载按钮置灰（不可点）。
• 文案统一成「N 小时后过期」/「N 分钟后过期」；≥1 天用「N 天后过期」（例：2 天后过期）。不写「剩 N 小时」——那个说法与上传下载的「预计剩余时间」混淆。
• 临近过期（≤1 小时）：胶囊转警示色 + 图标由时钟换成沙漏；不闪烁、不做循环动画、不加进度条（进度条会让人误以为是传输进度）。
• 倒计时口径（唯一正确做法）：

// 用服务端时间基准算一次 offset，再用单调时钟推进
const serverNow = Date.parse(resp.headers.get('Date')) // 或 /v1/config 的 server_time
const offset = serverNow - performance.now()
const remaining = Date.parse(item.expires_at) - (performance.now() + offset)
// ❌ 禁止：Date.parse(expires_at) - Date.now()  —— 设备时间可能差几分钟到几小时
// 不轮询：本地每 30s 用 performance.now() 重算一次显示即可

界面 mock

代价与风险

• 纯前端 + 已有字段，不需要改协议；列表项多一个 expires_at 字段的读取（服务端列表接口已返回）。
• 时钟漂移已用服务端基准 + 单调时钟规避；断网/后台休眠后回来重算一次，不累积误差。
• 风险：用户可能把「23 小时后过期」当承诺——文案只写事实（服务端到期时间），不写「保证可下载」。
• 工作量估计：列表三态 + 倒计时 hook + 测试，0.5 天。

现状

• spec.TombstoneTTL = 7 天（server/internal/spec/api.go:202）：终结态行 7 天后被 DeleteTerminal 清掉，于是「历史传输记录」最多只能看到 7 天。
• tombstone 里没有 filename / MIME / 明文 / 密钥 / 密文块（表里没有任何文件名或 MIME 列；密文只在 blob 目录且终结即删）。

改成什么

• tombstone 永久保留（不再按时间删行）——「永久保留不泄露内容」成立，因为存的只有时间、大小、状态、码与计数。
• 但三个关联性字段在终结后 +30 天置 NULL（保留行，不删行）：

清理挂在现有 sweeper：redactAfter = terminal_at + 30d，按批 LIMIT 200，WHERE ... IS NOT NULL 幂等。

存储增长（实测整行 255 B，含 4 个索引约 0.5 KB/行）：

界面 mock（记录永久保留 → 列表能看到「更早的记录」）

代价与风险

• 改动小：去掉按时间删行 + 新增一档 redact 任务（复用 sweeper）。0.5 天（含迁移与测试）。
• 风险 1：永久保留让「传输社交图」（谁给谁发过）长期可查——即便 redact 了 IP，sender_code/recipient_code 仍在；建议在报告里明确「码会轮换，历史码不指向具体人」，若仍担心可加「列表只展示 90 天，统计永久」。
• 风险 2：表会一直长——建议明细转 transfers_archive 轻表（只留时间/大小/状态），主表保持可查；聚合另存计数器（见 ③）。

现状

• 进度区只有百分比与「上传块 3/12」这类句子，没有速度、没有剩余时间。
• 取回 1 GiB 实测约 458 秒，其中大部分时间花在端侧解密（顺序逐块喂内核），网络并不慢——但界面没区分，用户会以为是“网慢”。

改成什么

• 位置：传输卡片上沿数字行——12.4 MB/s · 剩 1 分 20 秒（速度在左、ETA 在右），紧跟 已传 320 MB / 1.02 GB。
• 口径分开：上传 = 已加密并发出的字节/秒；下载 = 已接收并解密的字节/秒。
• 下载必须显示两段状态：下载中 62% 与 解密中 18% 分开（本项目解密是瓶颈，不能把慢算成网络慢）。
• 平滑算法：≥2 秒采样窗口 + EWMA（α≈0.3），或 4 秒滑动中位数；刷新 ≤2 次/秒；ETA = 剩余字节 / 平滑速度，floor 到秒。
• 显示规则：<10 秒 → 「即将完成」；<60 秒 → 「剩 45 秒」；<1 小时 → 「剩 12 分」；≥1 小时 → 「剩 1 小时以上」。
• 异常：速度 <10 KB/s 持续 3 秒 → 「网络较慢」；3 秒无字节进展 → 「连接停滞，重试中」，ETA 暂时隐藏（不许数字乱跳）。
• 不许出现：假的匀速动画；每次刷新重排宽度的数字（等宽字体 + 固定宽度）；用 setInterval 堆定时器（用 rAF 节流）。
• 移动端：同一套数字，但只保留「速度 · 剩 X」一行，字号 ≥14px。

// 平滑 + 节流（示意）
let ewma = 0, last = performance.now(), lastBytes = 0, lastPaint = 0
function onTick(bytes) {                      // 由 rAF 驱动
  const now = performance.now()
  const dt = (now - last) / 1000
  if (dt < 0.5) return                        // ≤2 次/秒
  const inst = (bytes - lastBytes) / dt       // B/s
  ewma = ewma ? ewma * 0.7 + inst * 0.3 : inst
  last = now; lastBytes = bytes
  const eta = ewma > 0 ? Math.floor((total - bytes) / ewma) : null
  paint(formatSpeed(ewma), formatEta(eta))    // 等宽数字，固定宽度
}

界面 mock

代价与风险

• 纯前端：采样 + EWMA + rAF 节流，0.5 天（含单测：平滑、四档文案、停滞隐藏 ETA）。
• 风险 1：速度会“看起来不涨”——因为解密是瓶颈；两段状态分开显示正是为了避免这个误解。
• 风险 2：后台标签页 rAF 被暂停 → 回到前台先丢弃过期样本，避免一次巨大瞬时速度。

现状

• 首页只有本机本次会话的三个数字（发送/接收/成功率），关掉页面就归零。
• 没有全平台口径：/v1/stats 不存在，数据库也没有计数器表。

改成什么

• 口径：只统计 state='CONSUMED'（接收方 ack 完成，即真的送达）；EXPIRED/REVOKED 不计入。若产品想展示「创建量」，另给 created 计数，不与「传输数」混成一个数。
• 实现：stats_counters(day date, transfers bigint, bytes bigint)，ack 成功时同事务 INSERT ... ON CONFLICT (day) DO UPDATE；/v1/stats 只读当日行 + 汇总行（O(1)），进程内再缓存 60s。
• 为什么不能首页实时全表扫：10 万/日 → 一年 3650 万终态行，count(*) + sum() 即使走索引也要扫全量，单次数百 ms 且随年限线性变差；首页按 10 QPS 估算就是每秒 10 次大范围扫描。
• 缓存头（必须排除 CDN/反代，否则数字被冻住）：Cache-Control: no-store + CDN-Cache-Control: no-store + Surrogate-Control: no-store；若要省源站可改 public, max-age=30, s-maxage=30，但「今日」会有 30s 滞后，需产品确认。
• 可见性两档（我们没有登录体系）：A 全匿名（推荐）：公开 /v1/stats，返回累计 + 今日，代价半天；B 匿名只给今日、累计需管理凭据：要新开管理员凭据面 + 契约新增 ADMIN_* 错误码，1–2 天且多一个长期密钥，v1 不建议。
• 防爬取舍：累计值可四舍五入到千/万再展示（如 1.28M / 42.8 TB），既做社交证明又不暴露精确量。

界面 mock（首页用 v4 翻牌器：等宽数字、360ms 翻转、不抖动）

代价与风险

• A 方案：1 个 handler + 1 张计数器表 + 4 个断言，半天；读 O(1)，1 万 QPS 无压力；写与 ack 同频（10 万/日 ≈ 1.2 QPS）。
• 风险 1：数字被抓取（无个人信息，仅聚合值）——用「四舍五入到千/万」缓解。
• 风险 2：计数器与真实行可能漂移（漏加/重放）——ack 事务内累加 + 每日对账任务（count(*) 与计数器差 > 0.1% 报警）。
• 风险 3：CDN 缓存把数字冻住——三个 no-store 头 + 部署文档写明「/v1/stats 排除缓存」。