tamakyi/tamabox
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
187 Commits 1 Branch 0 Tags
7ffab240259872c9eda98b066f10cebc767793d1
Commit Graph
187 Commits
This Branch
This Branch
All Branches
Author SHA1 Message Date
tamakyi 7ffab24025 安全: 修复页面密码零值绕过，导出不再泄露投票者 IP 
页面密码（P0，2026-11-05 复核发现）
- 旧实现 `ver, _ := Session.Get(key).(uint); if ver != user.PagePasswordVer`
  把「session 里没有授权记录」（断言失败得 0）与「新增列默认值 0」判成相等，
  升级瞬间所有存量页面密码静默失效：匿名访客不带 cookie 即可读箱主页。
- 收口为 pagePasswordAuthorized：缺 key 一律视为未授权，
  key 名由 pagePassKey 统一生成，Pager / ListAPI / AskStatusAPI 三处共用。
- 新增迁移 v6 回填 page_password_ver / ask_password_ver（仅仍为 0 且已设密码的行，
  幂等），让模型语义与「改过一次密码」一致，并作废升级前的布尔授权。
- AskStatusAPI 的 L4 查询补日志（保持与 Pager 一致的 fail-open 口径）。

导出（P1）
- JSON 导出的投票提交不再输出 voter_ip。库里照常保留，
  防刷、取证与站方 CLI 处置不受影响，只是不进箱主的自助导出文件。

测试
- route/question/page_password_test.go：8 个用例钉住零值/类型不符/轮换失效等边界。
- internal/db/page_password_migration_test.go：回填只碰该碰的行且幂等。

验证：WSL2 Debian + PostgreSQL 全量测试通过；隔离实例实测
ver=0 匿名访问返回密码页、API 401，输对密码后放行、改密后旧会话立即失效，
删除迁移账本后重启可正确回填。
 2026-11-05 16:31:54 +08:00
tamakyi 25aee35030 安全与可靠性: 修复配额并发、投票事务、密码授权与导出完整性 2026-11-05 12:17:05 +08:00
tamakyi 7636456d4e 可靠性: PostgreSQL 无 Redis 时 session 不再误用 MySQL 存储 2026-11-05 12:16:46 +08:00
tamakyi 937e688cfa 可靠性: 完善 R2 备份恢复与对象生命周期 2026-11-05 08:41:55 +08:00
tamakyi 3e7719f200 安全: 修复凭据、遥测与账号数据清理风险 2026-11-04 14:38:19 +08:00
tamakyi c633789a92 fix footer 2026-11-02 17:17:06 +08:00
tamakyi ea9ba3e8fc 首页: 修复功能卡下方各卡片之间缺少间距 
tb-grid 之后的三张独立卡片（域名迁移/一点提醒/近期更新）彼此相邻
却没有垂直间距，挤成一整块。用 .tb-grid ~ .uk-card 统一加 16px 上边距。
 2026-10-30 17:56:21 +08:00
tamakyi 036156b6fb 蜜罐告警: 修复去重口径与空收件人短路 
审阅蜜罐邮件提醒功能发现的问题，三项一并修：

1. autoban.alerted 从 map[string]bool（永不过期）改为带时间戳的
   map[string]time.Time，冷却期 24h 与蜜罐侧对齐。cleanup 里清理过期项，
   长期盯防同一来源不再漏掉后续攻击活动（此前一生只报一次）。
2. 蜜罐告警在 security_alert_email 为空时短路：route.go 注入 sendAlert
   前判空，收件人缺失置 nil，避免每次凭据提交白做 SMTP 拨号 + 刷 Warn。
3. 强化 security_alert_email 的配置警示（蜜罐邮件含明文密码，
   必须是个人邮箱、禁群组/分发列表）。
 2026-10-30 17:17:25 +08:00
tamakyi 48eea98a27 docs(memory): 记录安全汇总批次的关键教训（ipinfo 维度差异 / 缓存毒化 / 地图合规） 2026-10-30 16:41:29 +08:00
tamakyi d690355cdc feat(honeypot): 蜜罐安全状况周期汇总（周报/月报 + 地图 + 邮件） 
以周/月为单位汇总蜜罐命中，把来源 IP 通过公共服务查地理位置，画到地图上，
生成 HTML 报告并发邮件。同时补齐 ipinfo 无法回答「这个 IP 在哪儿」的问题。

新增 IP 地理定位层 internal/security/geoip：
- 与 internal/security/ipinfo 正交。ipinfo 走 cdncheck 离线指纹，只认云厂商/CDN/WAF，
  答的是「是不是代理」；肉鸡（家宽、企业宽带、移动网络）必然被判为
  「未识别（普通网络）」，所以「在哪儿」必须另建一套。
- ip-api.com 批量打底（100 个/请求、1.4s 节流）+ 腾讯位置服务精修国内
  （一 IP 一请求，只精修命中数最高的前 N 个，受 ip_geo_tencent_key 控制）。
- Result{Geo, Unresolved, Requests, Failures} 三态。服务明确回答「没有这个地址」
  才允许写失败缓存；请求超时/限流/5xx 一律不写 —— 否则一次抖动会把整批 IP
  钉成「查不到」三天，此后每份报告的定位覆盖率都莫名变成 0。
- addrs 按调用方给的顺序构建（不是 map 遍历）：腾讯精修只取前 N 个，乱序会让
  每次运行精修到不同 IP，配额花在长尾上。

报告生成 internal/security/report：
- period：PreviousWeek / PreviousMonth，窗口一律 [start, end) 左闭右开，
  相邻两期不重叠也不漏边界整点；period_key（week:2026-W44）做幂等。
- aggregate：按 shared.LimitKey 合并（IPv4 精确 / IPv6 折 /64）；国家、城市、
  路径、每日趋势；显式统计未定位命中数（覆盖率 60% 的图看起来和 100% 一样）。
- mapdraw：自绘等距圆柱投影气泡图。零海岸线零国界 —— 国界/台湾/南海诸岛绘制
  必须符合国家标准，自绘极易画错，真实底图交给腾讯。经纬网 + 度数刻度 +
  标签防重叠（同一都市圈两城市坐标差 0.01°，曾把「AU 55」和「AU 30」叠成
  看起来像 AU 305 的假数字）。
- html：自包含报告页，内嵌 SVG + 腾讯交互地图（无 key 时给申请指引，
  代码里不预置任何 key）。
- countryname：港澳台统一显示「中国香港/中国澳门/中国台湾」，常见国家用中文名。

存储与调度：
- ip_geo_cache（主键 = LimitKey，成功 TTL 90 天 / 明确无数据 TTL 3 天）
- security_report_logs（period_key 唯一索引 → 重启、错过时间窗都能正确补发，
  失败重试上限 5 次后停止）
- honeypot report --period week|month [--to] [--dir] [--no-email]
- web 启动时按配置挂 30 分钟一轮的调度器（与保留期清理共用停止信号，
  defer 移出 if 外，避免「清理关掉、报告开着」时 goroutine 泄漏）

配置（[security]）：ip_geo_provider=auto|ipapi|tencent|none、ip_geo_tencent_key、
honeypot_report_enabled / _weekly / _monthly / _email / _dir。

顺带修复：
- route/honeypot_test.go 的 captureStore 缺 AggregateSources/AggregatePaths/
  TimestampsBetween，整个 route 包编译不过。
- templates/render_test.go 的 mockLoggedUser 缺 TelegramChatID，3 个渲染测试失败。
 2026-10-30 16:40:44 +08:00
tamakyi 08bbd17751 storage: 对齐图片对象 key 到生产口径 
生产真实 key 为 `YYYY/MM/<UnixNano>.<ext>`（无前缀、无 day 层），
与 route/question/page.go:uploadImage 一致；internal/storage 里三个
上传函数仍用旧的 `picture/ 前缀 + YYYY/MM/DD + 15hex + 无扩展名`，从未上线。

- PictureKeyPrefix 置空，统一由 uploadKey 生成 key
- 扩展名跟随最终 ContentType（webp 转成功用 .webp，回退原图用原格式）
- OSS 原图直传通道取原文件名扩展名
- 新增 picture_test.go 锁定 key 格式，防回归
 2026-10-29 20:04:31 +08:00
tamakyi c6966138b4 docs(memory): 记录迁移系统/备份脚本/通知的实现与 R2 存储结构 2026-10-29 19:27:29 +08:00
tamakyi b9060c982b feat(notify): 新增站级 Webhook 与用户级 Telegram 通知通道 
在现有邮件通知之外补两条广播/点对点通道：

- 站级 Webhook（[notify] webhook_url）：新提问 / 新回答 / 新追问 / 新私聊 /
  新投票回复统一 POST JSON 到通用 Webhook（Discord / Slack / 企业微信机器人等）。
  消息体同时带 content（Discord 直接可用）与结构化 event/title/body/link 字段。
- 用户级 Telegram（[notify] telegram_bot_token + users.telegram_chat_id）：箱主
  自填 Chat ID，新提问 / 新投票回复点对点推送。

设计约束：通知是「尽力而为」旁路 —— 任一通道发送失败只记日志、不向上抛错，
绝不影响提问/回答的主流程；通道未配置时静默跳过。发送放在 shared.SafeGo 异步
执行，与现有邮件通知同一条路径。

6 处业务触发点接入 notify；私聊消息保留仅邮件（已有 5 分钟节流，避免广播刷屏）。
profile 页新增 Telegram Chat ID 输入框 + 四语言字典。app.sample.ini 加 [notify] 段。

测试覆盖 webhook 的 JSON 结构与未配置时的静默跳过。
 2026-10-29 19:27:23 +08:00
tamakyi 1e9ffc0718 feat(ops): 新增 TamaBox backup 命令，同时备份数据库与 R2 图片 
此前没有任何备份手段，而站点的图片全在 Cloudflare R2、数据库只存 key/URL ——
只备份 DB 的话，恢复后 key 指向的图片若已不在 R2（bucket 误删 / 账号丢失 /
图片被清理），页面就全是裂图。

新增 TamaBox backup --output <dir>：
- 数据库：pg_dump 全量导出（schema + data，标准恢复格式），密码经 PGPASSWORD
  环境变量传递避免出现在 ps 进程参数里
- 图片：从 R2 下载 tamabox 站全部图片，保持原 key 路径，并写 images-manifest.json
  （key → size → md5）用于恢复后完整性校验
- --db-only / --images-only 分开关

R2 访问方式的坑：storage.GetS3Client 的 endpoint 带 /<bucket> 后缀，对
GetObject/PutObject 恰好可用，但 ListObjectsV2 会把 URL 拼成 /<bucket>/<bucket>
而 404 NoSuchKey。备份脚本独立构造客户端（剥离 endpoint 的 bucket 后缀 +
UsePathStyle），List prefix="tamabox/" 后用完整 key 下载 —— 这是 R2 上 List
唯一稳定可用的姿势。

实测：db-only 导出 46KB（21 表全含 schema_migrations）；images-only 下载的文件
大小与 R2 List 返回完全一致，路径保持 tamabox/ 结构。
 2026-10-29 19:27:13 +08:00
tamakyi 62edf88029 feat(db): 版本化数据库迁移，改列名/删列不再静默丢数据 
GORM 的 AutoMigrate 只会加表/加列/加索引，从不改列名/删列/改约束。此前这类
破坏性变更靠「HasColumn 判断 + 幂等补丁」硬撑，既没有账本记录「跑过什么」，
也把 5 个一次性回填（backfillAnsweredAt / backfillFeatureControls /
reconcileLegacyChatEnabled / normalizeChatQuota / normalizeHarassmentSetting）
留成了每次启动都全表扫一遍。

新增 schema_migrations 账本表 + runMigrations：
- 迁移按版本号升序执行，每个迁移在事务里「跑 up + 记版本」，任一失败阻断启动
- 那 5 个幂等补丁收编为 v1~v5，收编后只跑一次，之后启动直接跳过
- AutoMigrate 仍负责声明式的加表/加列/加索引，版本迁移负责它做不了的破坏性变更
  与一次性回填，两者分工互不替代

测试覆盖：幂等（跑两遍不重复）、失败阻断后续、清单严格升序。实测真实库首次
启动建账本 + v1~v5 落库，二次重启账本不变。
 2026-10-29 19:27:03 +08:00
tamakyi 693b1102c2 fix: 封堵 ask-status domain 枚举、私聊写路径 fail-open、压缩兜底重复提交 
三处小修 + 两个格式清理，均来自全盘复查：

1. ask-status domain 枚举：ErrUserNotExists 分支原返回空数组、正常分支返回带元素
   数组，凭空/非空可枚举 domain 是否存在（含被 L1 隐藏或设了页面密码的半公开箱）。
   改为箱主不存在时也回显 ok:false，四种失败响应完全同形。

2. 私聊 SendMessage 写路径用 FeatureStateOf（fail-open 变体）：读配置失败会回退默认值，
   与「写路径必须 FeatureStateOfStrict（失败即拒）」的约定不符。此前靠 chat 默认关闭
   的巧合侥幸安全，现统一改 Strict。

3. 图片压缩 submit 兜底可重复提交：capture 监听器里 tbBeginSubmit 从 Promise 回调提前
   到 preventDefault 同步栈，物理阻止压缩窗口内双击重复提交。

顺带：box_views.go / message_image.go / insights 两个文件补末尾换行与 struct 字段对齐
（gofmt 干净）。
 2026-10-29 18:52:38 +08:00
tamakyi c9b426acbb fix(insights): 数据面板「每日回答数」按 answered_at 分组，而非 created_at 
BoxTrend 的回答那条 SQL 复用了 d.day（基于 created_at 的日期表达式）做 GROUP BY，
但 WHERE 过滤用的是 answered_at。于是「40 天前创建、昨天才回答」的提问被排除在
窗口外（created_at < from），昨天的回答数里不出现；「今天创建、明天回答」的又
被记到今天。趋势图里的「每日回答数」根本不是「某天被回答了多少」。

单独构造 answerDay（基于 COALESCE(answered_at, updated_at)），WHERE / GROUP BY /
SELECT 三者口径一致。PG 用 to_char(... AT TIME ZONE INTERVAL ...)，MySQL 用
CONVERT_TZ，与 analyticsDialectFor 对 created_at 的处理对称。

新增 box_analytics_test.go：构造「40 天前创建、昨天回答」的提问，断言计入昨天，
并做变异验证（改回 d.day → 测试失败）。
 2026-10-29 18:52:29 +08:00
tamakyi 87176516f3 fix(data): 删除提问时追问与图片一并真删，不再软删残留 
questions.DeleteByID 对主表用 Unscoped 真删，但级联清理的两个子 store 仍用软删：
FollowUp（内嵌 dbutil.Model）与 UploadImage（内嵌 gorm.Model）都带 DeletedAt，
裸 Delete 是软删。于是提问正文（含 FromIP、邮箱）删干净了，追问文本与图片元数据
（name/md5/key）却带着 deleted_at 永久残留，孤儿行的 question_id 指向已不存在的提问
—— 正是「真删以免个人数据删不干净」想消灭的问题，却在子表漏改。

两个 DeleteByQuestionID 改为 Unscoped 真删。关联表 UploadImageQuestion 无 DeletedAt，
本来就真删，无需 Unscoped（已注释）。

新增 question_delete_hard_test.go：用 Unscoped 计数断言删除后追问/图片/关联行物理上=0，
并做变异验证（改回软删 → 测试失败）证明测试真的能抓住这个回归。
 2026-10-29 18:52:19 +08:00
tamakyi 7f86db8937 docs(memory): 记录数据面板与图片压缩的实现、验证与踩坑 2026-10-29 18:26:12 +08:00
tamakyi f9aaef17e5 feat(ux): 图片选图即压缩，上传体积从 MB 级降到 KB 级 
服务端早已把静态图转 WebP、长边限 1600（storage.GeneralEncodeSpec），但上传这一跳
发生在压缩之前：手机拍的 4~8MB 照片要先原样传完才能被缩小，移动网络 1~2 Mbps 下
要等几十秒，超过 5MB 校验的直接被拒、连写好的正文一起丢。

现在选图后先在浏览器内压缩，再随表单上传：
- canvas → WebP，长边 1600、质量 0.8（与服务端同档），一张照片通常降到 200~400KB
- createImageBitmap + imageOrientation:from-image 摆正 EXIF，老浏览器回退不带选项
- submit capture 兜底：选图立刻提交时先等压缩完成再真正 submit

三条安全边界（缺一不可，否则会「压出比原图更差的结果」）：
- GIF/SVG 跳过：canvas 会把 GIF 画成静止首帧、SVG 栅格化
- 压完不到原体积 85% 退回原图：已优化小图重编码反而更大
- 透明 PNG 优先 WebP（支持 alpha），不支持 WebP 编码时退回 PNG 而非 JPEG（否则透明变黑）

实测（WSL headless Chromium + CDP）：4.6MB PNG → 11.7KB WebP（0.3%），
小图原样保留、GIF 跳过。

顺带加 dev/sync-wsl.sh：把同步脚本里 rsync --delete 误删目标机 conf/app.ini 的坑
固化掉（该文件含 DB 密码与对象存储密钥，不在源目录里，必须 exclude）。
 2026-10-29 18:26:04 +08:00
tamakyi 4e574ac64a feat(insights): 箱主数据面板——访问量、提问趋势、处理漏斗 
新增 /user/insights，让箱主第一次能看到「有多少人来过我的箱、提问处理得怎么样」。

数据来源：
- 新表 box_views：一行 = 一访客×一天×一箱，views 累加，唯一索引
  (user_id, viewed_on, visitor)。刻意不内嵌 dbutil.Model —— 软删除 + 唯一索引
  会让被删行永久占槽，且删过的槽位再也插不进去。
- 访客标识 = HMAC(日盐, IP) 前 32 hex：同日可去重（UV 准）、跨日不可关联（隐私）。
  代价是近 7/30 天 UV = 各日 UV 之和，页面上已写明口径。

写入是异步的：buffered channel 512 + 2s 批量 flush，队列满即丢（统计尽力而为，
不该因为记一笔访问就拖慢页面）。过滤箱主本人、空 UA、爬虫 UA、预取请求。
密钥复用 server.xsrf_key；每日清理 400 天前的明细。

页面（纯 CSS 画图，不引图表库）：
- 今日/近 7 天/近 30 天 KPI + 上周对比
- 30 天 PV/UV 双柱趋势、24 小时时段分布
- 提问处理漏斗 + 回答率进度条 + 自动结论

聚合层 internal/db/box_analytics.go 复用 analyticsDialectFor 的时区处理，
与全站 stats 分开（那个不含单箱维度、按自然日缓存）。

测试：box_views 4 项（含「同批同键先内存合并」——PG 的 ON CONFLICT 不允许
同条 INSERT 二次命中同一行）、insights 的 pct/窗口切分/visitorID/爬虫过滤。
 2026-10-29 18:25:53 +08:00
tamakyi 5a05a61647 docs(api): 说明 ask-status 的 Method 检查是防御而非主路径 
路由只注册了 POST（token 不能进 URL），所以 GET 会落到 NotFound 返回 404，
handler 里的 405 分支实际走不到。留着是为了将来路由若改成 f.Any 时仍然安全，
加上说明避免被当成死代码删掉。
 2026-10-29 17:19:26 +08:00
tamakyi 4fcaa197cf docs(memory): 第三批修复与三个新踩到的坑 
- 2026-10-29.md：第三批 7 项改动与验证数据
- MEMORY.md：三条长期结论 ——
  「用户主动删除 = 真删」（模型全带 DeletedAt，默认 Delete 是软删）、
  「配额必须与内容同事务」（incrementQuotaTx 是唯一实现，且投票口径是票数不是个数）、
  「错误页不套模板」（f.NotFound 不经过组级中间件，注入 template.Data 会 panic）
- topics/quality.md：标注第三批范围

新踩到的三个坑：
1. gofmt 会把注释列表 `// 1) ...` 改写成 `//  1. ...`，被标为未格式化时先排除这个
2. Select(...) 漏列 = 字段静默为空（摘要永远是空串，只有一项测试红）
3. CDP 验证纯前端：chrome 必须作为独立后台进程启动，跟在别的命令后面 `&`
   会随 shell 退出被回收；headless=new 的空标签页 type 常是 other
 2026-10-29 17:18:47 +08:00
tamakyi 5def41d0f8 feat(ux): 真 404 / HTML 500 页，以及「提问者找回自己的提问」 
一、错误页

原来未知路径一律 302 到首页：用户点了个失效链接，地址栏莫名跳到首页却什么
提示都没有，分不清是链接坏了还是自己点错了；对搜索引擎是软 404，失效链接会
被当成有效页面一直占抓取预算。500 则是 flamego.Recovery() 的纯文本
"Internal Server Error"，白底黑字两行英文，没有返回入口，也没法报编号。

现在是 internal/route/errorpage.go 里的 writeErrorPage：
- 404 保留状态码 + 一页能看懂的说明 + 返回首页按钮 + noindex
- panic 由自写的 recoveryMiddleware 兜住，渲染同样的 HTML 500 页，
  并带上 trace id（用户反馈时报这个号就能定位日志），日志里也带完整栈
- 响应已写出时不再写头（否则 net/http 会忽略状态码并打 superfluous 警告）

为什么不套模板：f.NotFound 不经过组级中间件 —— template.Templater 与
Contexter（连同 session、CSRF）都挂在 f.Group 上，在 NotFound 里注入
template.Data 会直接 panic（实测："value not found for type template.Data"）。
而 recovery 是最外层，那时模板还没装配。错误页恰恰最不该依赖可能出错的链路，
所以用内联 HTML + i18n.T，语言从 Accept-Language 猜（拿不到 session）。

蜜罐分流仍在 NotFound 最前面：临时打开 enable_honeypot 实测 /wp-admin
仍返回假 WordPress 登录页（200），普通未知路径返回 404。

二、提问者找回自己的提问

不填邮箱时，唯一能追踪这条提问的东西是提问成功页上那条链接 —— 关掉页面、
链接冲掉了就永久失联。箱主认真答了，提问者永远不知道。这是这类产品最核心的
体验断点，而它不需要账号体系就能解决：

- 成功页把 {domain, id, token} 写进本机 localStorage（最多 30 条，按 domain+id 去重）
- 再访该箱时显示一条不打扰的横条：「这台设备上有 N 条提问记录，其中 M 条已有回答」，
  点「查看」展开列表，每条可直接打开
- 新增 POST /api/v1/ask-status 批量回答「哪些已被回答」：一次 IN 查询，不逐条 N+1

它不能用来枚举：必须同时给出正确 token 才返回 ok=true，而「token 错」「id 不存在」
「不属于该箱主」三种情况的响应完全相同（ok=false / answered=false / excerpt 为空），
无法区分。token 比较走常数时间，单次最多 20 条，限流 30/分钟。用 POST 不用 GET，
因为 token 不能进 URL（会留在浏览器历史、代理日志、Referer 里）。

列表摘要先过 MarkdownPlainText 再按 rune 截断：直接截原文会露出 ![图片](https://...)
这种噪音，一条带图的提问几乎只剩链接。

验证：
- verify_ask_history.py 12/12（含「错误 token / 不存在的 id / 别人的提问」三者
  响应完全一致、缺 CSRF 被拒、超 20 条截断）
- verify_ask_history_ui.mjs 用 CDP 在真实 Chrome 里跑：无记录时提示条隐藏；
  注入记录后显示「1 条，其中 1 条已有回答」；列表渲染、链接带 token、点击展开正常
- 错误页单测 6 项（HTML/不泄露 panic 内容/已写出时不重复写头/语言选择/状态码/转义）
 2026-10-29 17:18:39 +08:00
tamakyi d5d25c804b fix(data): 删除改成一个事务且真删、配额与内容同事务 
四类问题都出在「多次独立写入 + 失败只打日志」这个模式上。

1) 删除投票的级联没有事务（route/user/vote.go）
   选项 / 表单字段 / 提交记录 / 投票本体是 4 次独立写入，前 3 步失败只 Warn。
   中途失败会留下「选项没了但票还在」这种界面无法修复的状态 —— 重试删除时
   投票已不存在，只能报 not exist，脏数据永远留着。
   → db.Votes.DeleteWithCascade：四张表在同一事务里删完。

2) 删除其实是软删除，个人数据没真删掉
   模型都嵌了 dbutil.Model（含 DeletedAt），原来所有 Delete 都是软删：
   提交记录里参与者填写的文本、voter_ip、voter_token，以及提问里的 FromIP，
   只是「界面上看不见」，库里永久留着。用户点删除的预期不是这样。
   软删还会占住 link_token 唯一索引，删过的链接永远不能复用。
   → 删除投票与删除提问统一 Unscoped 真删；提问的追问/图片关联/配额回退
     原来也是三个独立写入（失败只 Warn），一并收进事务。

3) 配额计数会永久偏低
   「创建内容」与「quota_count+1」是两次写入，后者失败只 Warn：
   箱主看到的「已收集 7/10」偏小，达到上限后因为计数偏小实际还能继续收，
   等于定量收集被静默绕过；重置计数也校准不回来（重置是把计数清零，更脱节）。
   → 抽出 incrementQuotaTx(tx, userID, feature, delta) 作为唯一实现，
     提问 Questions.Create、私聊 CreateWithFirstMessage、投票提交
     VoteSubmissions.Create（新增 QuotaUserID）都在自己的事务里完成 +1。
   注意口径：投票的定量收集是「累计收到的票数」（提交成功时 +1），
   不是「创建了几个投票」—— 所以删除投票不回退这个计数。

4) 改写追问回答每次都发通知邮件
   箱主改措辞、补一句、修错别字都会重新保存，每次都发的话提问者会连着收到
   好几封一模一样的「您的提问有回复」。主回答那边早有 question.Answer == ""
   的判定，追问这里补齐：UpdateAnswerByID 在事务内读旧值返回 wasFirst。

顺带：
- isQuestioner 的 token 比较从 == 改为 subtle.ConstantTimeCompare，
  与 Pager 中间件里的校验同口径（== 按字节短路，可用响应时间逐字节试探）。
- CSV 导出的表头（字段名）与选项内容列补 sanitizeCSVCell。原来只有数据列走它，
  而选项名同样可能是 =HYPERLINK(...) 形式；判断也改成看 trim 后的首字符。
- 写路径的功能开关改 fail-closed：新增 db.FeatureStateOfStrict，读配置失败时
  拒绝而不是回退默认配置 —— 提问/投票的默认值是「开启」，fail-open 等于让一次
  数据库抖动绕过箱主设的关闭与定量上限。读展示仍用宽松版。

验证：全量单测（带 DB）与 go build ./... 通过；verify_round3 6/6（私聊
message_count 与实际消息数一致）、verify_p1 4/4、verify_round2 19/19、
verify_page_next 6/6、verify_chat_owner 3/3。
 2026-10-29 17:18:28 +08:00
tamakyi 89e263cbd4 docs(memory): 记录第二批修复与「Python write_text 会改行尾」这个坑 
- 2026-10-29.md：第二批 9 项改动与验证数据（含投票结果 2 万条 0.211s→0.023s），
  以及剩余待办清单（级联删除事务、配额漂移、JSON-LD/RSS、箱主数据面板等）
- MEMORY.md：构建测试段补 write_text 行尾陷阱与排查手法（看 git diff --stat / git show），
  其它约定段补 /healthz 与 /readyz 的语义边界（存活探针不查依赖）
- topics/quality.md：标注第二批已完成的范围

附带说明：本轮我自己也踩了 write_text 的坑，把 14 个 LF 文件写成了 CRLF，
靠 git diff --stat 的「整文件重写」发现、再用 git show HEAD:<file> 的行尾比对恢复。
 2026-10-29 16:29:02 +08:00
tamakyi 03cb5ddcf0 fix(ui): 提交防重复覆盖验证码路径、waline 按页加载、懒加载、safe-area、硬编码文案接字典 
1) 防重复点击原来漏了最主要的一条路径
   footer 的全局 submit 监听会禁用按钮，但**程序化 form.submit() 不触发 submit 事件** ——
   走 reCAPTCHA / Turnstile 的流程是在回调里调 form.submit() 的，而默认配置
   captcha_type = recaptcha，也就是主提问流一直没有防重复。登录、注册、找回密码、
   投票、注销账号同样走这个回调。
   → 把「切提交中状态」抽成 tbBeginSubmit(form, trigger) 挂到 window，
     验证码回调先调它再 submit。7 个 data-callback="onSubmit" 的模板全部受益。
     顺带加了 data-tb-restore 的重复覆盖保护，避免 bfcache 复位后按钮卡在转圈。

2) waline.js / waline.css 从全站改按页加载
   只有 home.html 与 item.html 用评论区，但此前挂在 header 里 —— 登录、后台、投票、
   私聊每页都下载解析 waline.js（2.15 未压缩约 200KB）。实测 /login 已无引用。

3) 图片懒加载：explore 列表头像与题目配图加 loading="lazy"（首屏推荐位不加，避免影响 LCP）。

4) 移动端底栏：body 只预留固定 56px，而底栏 padding 含 safe-area-inset-bottom。
   带 Home Indicator 的 iPhone 上 inset 约 34px、底栏实际约 88px，最后约 32px
   （页脚备案、存活计时）被压在栏下，滚到底也看不到。改成 calc(56px + env(...))。

5) 硬编码中文接字典（en/ja 用户此前直接看到中文）：
   history-template 的「查看回答 / 加载更多 / 加载中... / 无更多留言」、
   单题页「@xxx 以前回答过的问题」（字典里本来就有 ask.history）、
   投票页「（最多 N 项）」改为带参数的整句（原先前半走字典、后半手写中文）。
   新增 4 个 key × 4 语言。

实测：箱主语言设为 en 后箱主页显示 View answer ×2 / Load more / No more posts，中文零残留。
 2026-10-29 16:28:53 +08:00
tamakyi f2e0c43083 feat(ops): 健康检查端点，并把上传超时与服务端读超时对齐 
1) /healthz 与 /readyz
   改动前站内唯一的「探活」手段是 curl /，而首页只渲染模板、不查数据库：
   DB 挂了首页照样 200（漏报），Redis 挂了首页又可能 500（误报）。
   监控、CDN 源站健康检查、滚动重启的摘流判定都没有可靠依据。
   → /healthz 永远 200，刻意不碰任何依赖：进程活着 ≠ 能对外服务，
     把 DB 检查塞进存活探针会导致数据库抖动时进程被反复重启，对恢复毫无帮助；
   → /readyz 查 DB（2s 超时），失败 503；响应体只回组件状态，
     绝不回错误详情 —— 这是公开端点，DB 报错常带库名/主机名/账号。
   实测：停掉 PostgreSQL 后 /healthz 仍 200、/readyz 503，恢复后 200。

2) ReadTimeout 30s → 120s
   站内允许单图 8MB、请求体上限 12MB。30s 传完 8MB 需要 ≥273 KB/s 上行，
   而手机 4G 上行常在 1–2 Mbps（125–250 KB/s）—— 一张 8MB 图必然超时，
   且用户已写好的正文会一起丢（POST 失败不回填）。120s 对应约 68 KB/s，
   偏远地区 3G 也能过。
   放宽它不会让 slowloris 重新可行：那类攻击卡在「发不完 header」，
   由 10s 的 ReadHeaderTimeout 拦住，ReadTimeout 只影响读完 header 之后传 body 的时长。
 2026-10-29 16:28:44 +08:00
tamakyi 0124e392c7 fix(correctness): 三处幂等缺陷、私聊首条事务化、验证码失败不再丢正文 
四处都属于「并发/失败路径下状态不一致」，用户侧表现为「点了没反应」「发了没收到」。

1) 删除会话重复回退配额
   MarkDeletedByOwner 是 check-then-act：双击时两个请求都读到 is_deleted_by_owner=false，
   都执行 UPDATE、都执行一次 IncrementQuota(-1)。计数不会变负，但会白吃掉其他会话的额度，
   表现为定量收集提前关闭，箱主重置计数也校准不回来。
   → 改条件更新 + RowsAffected 决定是否回退。

2) 双击产生两条重复追问
   「上一条追问必须先被回复」原来只在 handler 里判断（事务外）：两个请求都能通过那次检查，
   随后被 CreateIfBelowLimit 的问题行锁串行化，各自 count 都 < 3 —— 两条相同追问都建成，
   吃掉 2/3 名额，箱主还收两封邮件。
   → 判定挪进事务，新增 ErrFollowUpAwaitingReply；handler 的预检查保留作为快速失败。

3) 双击置顶结果与预期相反
   SetPinned(id, !question.IsPinned) 是 read-modify-write：两个请求都读到 false 都写 true，
   用户点两次期望「置顶后取消」，实际仍是「置顶」。
   → 新增 SetPinnedIfCurrent(current, next)，第二次因状态已变而 0 行，语义是「只切换一次」。

4) 私聊首条三步写入无事务
   建会话 → 写首条消息 → 计数是三次独立写入，第二步失败会留下 message_count=0 的空会话，
   箱主列表里能点进去却什么都没有；而 BeforeCreate 已占掉一个 6 字符 token（唯一索引），
   孤儿会话永久占用它。
   → 新增 CreateWithFirstMessage，三步收进一个事务。

5) 验证码失败丢正文
   该分支原来走 SetErrorFlash + Redirect，而其它失败分支都是 SetError + Success 回填表单。
   验证码失败恰恰是最常见的失败（token 过期、网络抖动），结果用户写好的正文整段丢失。
   → 改为同请求渲染并回填；错误文案不再透传 err.Error()（可能含上游原始信息）。

6) 5 处裸类型断言改带 ok（share.go ×3 / context.go ×1 / user/vote.go ×1），
   断言失败时丢弃脏缓存并走重建，而不是 panic 掉整个请求。share.go 的 ttlCache 补 Delete。

验证：内部 DB 测试 3 项（并发删除只回退一次配额 5→4、双击只产生一条追问、
双击只切换一次置顶）；verify_round3.py 6/6（验证码失败 200+正文回填+不建提问、
私聊首条 message_count 与实际消息数一致）。
 2026-10-29 16:28:34 +08:00
tamakyi 0041cc51f8 perf(vote): 结果聚合改 stale-while-revalidate，消除持续投票时的 O(N²) 
多选 / 评分 / 排序 / 表单的统计必须在 Go 层逐条 json.Unmarshal 全部提交记录
（ListByVoteID 传 nil 不设 LIMIT），而 Submit 每来一票就 InvalidateResultsCache
删掉缓存 —— 于是第 k 票触发一次 O(k) 重算，持续有人投票时稳态是 O(N²)。
一万票的投票在投票期间每次刷新都要扫一万行 JSON。

现在：
- LoadResults 用 GetWithExpiry 读到「已过期但仍在」的旧值，先返回给调用方，
  再在后台按投票去重重算（sync.Map 占位 + shared.SafeGo，60s 超时）
- 后台只拷贝 ID/Type/AllowCustom 三个字段，不把 handler 正在用的 *db.Vote 带进 goroutine
- Submit 从 InvalidateResultsCache（删缓存）改为 ExpireResultsCache（标记过期保留旧值），
  否则每次提交都会让下一次读退化成同步全量重算
- 选项变更 / 删除投票仍走 InvalidateResultsCache（结构性变化，旧值已无意义）
- TTLCache 新增 GetWithExpiry / Expire：Get 遇到过期项直接删除并返回 false，
  「过期」与「不存在」分不开，正是无法做 SWR 的原因

实测（2 万条多选提交）：冷启动 0.211s → 过期首读 0.023s（快 9.2x），
后台刷新后 0.009s。缓存单测 3 项覆盖 GetWithExpiry 不删条目 / Expire 保留值。

顺带把 7 处裸类型断言改成带 ok（其中 results.go 的是新代码）。
 2026-10-29 16:28:23 +08:00
tamakyi d4e6da76f1 docs(memory): 记录第二轮复查结论与六项修复的验证方式 
- 新增 topics/quality.md：业务正确性 / 运维 / 前端体验四类结论，含
  「私聊取最早 50 条」「Classic() 的 Logger 记 RequestURI」这两个坑的成因，
  以及处置覆盖面、Redis 两种故障模式、产品缺口（无 page view / 提问者找不回自己的提问）
- 2026-10-29.md：本轮六项修复的改动与验证结果，另记两个实现坑
  （limit 兜底不该抬大用户配置；Python bytes 字面量不支持 \uXXXX）
- topics/sec.md / 2026-10-27.md：补上一轮遗漏的字体自动发现与 CSP enforce 结论
- MEMORY.md：索引加 quality，处置覆盖面一条标注投票链路已补齐
 2026-10-29 15:53:57 +08:00
tamakyi c971d99bdb fix(vote): 站方处置覆盖投票链路 
提问链路上 ActiveLevel 有 7 处调用，投票链路 0 处。于是 L4（整页停用）处置某人后：
/_/domain 已经 302 到 /restricted，但 /vote/{token} 照常渲染、照常收票；被处置者
还能发新投票；探索页的「热门/全部投票」也不做处置过滤 —— 同一张页面里
「箱主消失了、他的投票还在曝光」。这是运营口径不一致，不是越权。

补齐三处，与提问链路对齐：
- vote.Page      L4 → 302 /restricted（同箱主页；查询失败 fail-open，与 Pager 一致）
- vote.Submit    L4 → 拒绝（页面进不去不代表直接构造 POST 也拦得住）
- VotePublish    L2 起拒绝（L2 已是「收窄公开」，不该再新增公开内容）
- 探索页投票列表改用 Restrictions.ActiveLevels 批量过滤（与 GetShowInHome 同口径，
  一次查询避免 N+1），功能开关过滤逻辑保持不变

新增字典 key vote.err.restrictedPublish（四语言）。

验证（本地实例）：
- L4 后 /vote/{token} 302 → /restricted；撤销后恢复 200
- 探索页该投票出现次数 0（处置中）→ 2（撤销后）
- 草稿投票在 L2 下发布后状态停留 draft，撤销后同一请求变为 published
 2026-10-29 15:53:49 +08:00
tamakyi ced4c1635c fix(question): 图片上传失败时回滚已创建的提问 
Questions.Create 在图片处理之前就提交了，失败分支只渲染错误页、不回滚。于是：
箱主收到一条无图提问，提问者只看到「图片过大 / 上传失败」以为没发出去；再想重发
又会被 DuplicateGuard 按「同 IP + 同内容 5 分钟内重复」拦住 —— 既没发成功也重发不了。

现在失败分支先 Questions.DeleteByID 回滚（连带清理追问与图片关联，并回退前面
那次提问配额 +1），再做提示。顺带把不需要的 else 去掉（两个分支都以 return 结束）。

验证：6MB 图提交后提问数增量 0、该行 deleted_at 非空（回滚走的是软删）；
无图对照增量 1。两条路径均返回 200，正常流程未受影响。
 2026-10-29 15:53:39 +08:00
tamakyi 11d6e701ee fix(ops): 访问日志脱敏、优雅关闭、Redis 可降级并启动即探活 
三处都属于「故障时才发现」的运维缺口，一起改。

1) 访问日志泄露凭证
   flamego.Classic() 内部 Use(Logger())，而 Logger 记的是 RequestURI —— 含 query。
   实测日志出现 path=/_/tblocal/4?t=SECRETTOKEN123：?t= 是私密提问钥匙，
   ?code= 是一次性改密凭证，?q= 是搜索词，全都会被明文落盘，凡是能看日志的人
   都能直接读私密提问或重置密码。internal/tracing 早就为同一原因只取 URL.Path
   并留了注释，漏的是框架自带那层。
   → 改 flamego.New() + accessLogMiddleware，只记 Method/Path/Status/Duration/IP；
     静态资源成功请求不记（噪音），4xx/5xx 照记（排查裂图靠它）。

2) 没有优雅关闭
   直接 ListenAndServe，Go 对 SIGTERM 是立即退出，每次部署都会把正在写库的 POST
   就地处死，留下「提问已 INSERT、图片没传完」这类半成品。
   → signal.NotifyContext(SIGTERM/SIGINT) + srv.Shutdown(15s)，超时才 Close；
     退出前关连接池。实测 8 个并发分享图请求中发 SIGTERM，8/8 全部成功。

3) Redis 单点
   session 建在 Redis 上，load 失败 flamego/session 会 panic → 每请求 500（含匿名访客）；
   而 cache.Cacher 没判空 Addr，go-redis 会回退 localhost:6379，于是「不配 Redis」
   这种被允许的部署里找回密码整体不可用、私信邮件节流失效，且启动零提示。
   → cache 跟随开关（未配则 MemoryIniter）；启动 PingRedis fail-fast，显式 2s 超时。
     实测停掉 Redis 后启动立即失败并明确指出是 Redis。

验证：单测 2 项（query 永不入日志 / 静态资源过滤口径）；重启日志出现
「收到退出信号」→「HTTP 服务已关闭」；启动打「Redis 连接正常」。
 2026-10-29 15:53:32 +08:00
tamakyi 46932b4c53 fix(chat): 会话消息只取最早 50 条，第 51 条起对双方永久不可见 
GetByConversationID 原来是 Order("created_at ASC") + Limit(50)，而会话上限是
conf.Limits.ChatMaxMessages（默认 200）。唯一调用方 chat_handler 永远传 nil cursor，
于是取到的永远是「最早 50 条」：第 51 条起写库成功、message_count 原子递增、
页面显示 51/200，但列表里没有它 —— 等多久、换设备、重新登录都不会出现。
本地实测 55 条会话只渲染 #1–#50，双方都以为对方没回，直到 200 条被判满自动关闭。

改为：
- Order("id DESC") 取最新 limit 条，再在内存反转成时间正序（气泡从上到下＝旧→新）
- limit 取 conf.Limits.ChatMaxMessages，兜底只处理零值（配置未初始化）；
  不写成 limit<50→50，那样会把箱主显式配的小上限抬大
- 排序键用 id 而非 created_at：同毫秒写入的 created_at 相同，排序不稳定
- 游标 query 去掉 NULL 风险：显式要求 cursor.Value 非空

验证：55 条实测渲染 55 条、范围 #1–#55；单测 3 项（全量可见 / 超限保留最新 /
游标翻页），变异验证把 ORDER 改回 ASC 时「超限保留最新」立刻变红。
 2026-10-29 15:53:22 +08:00
tamakyi 430c6ef6d8 docs(memory): 记录审计结论（CSP 默认 enforce、分享卡字体限制、复查新发现） 
- topics/sec.md：两轮修复的结论、全局复查新发现（私聊 POST 越权、页面密码 next）、
  CSP 白名单口径、字体只能用 glyf 轮廓这条硬限制，以及复现脚本的两种「假红」
- MEMORY.md：安全小节补跳转白名单、GET/POST 校验不对称、CSP/umami、注册防枚举
- 2026-10-27.md / topics/build.md：本地 WSL 部署与验收的具体跑法
 2026-10-27 12:37:55 +08:00
tamakyi e807dea218 feat(share-card): 字体自动发现 + 启动探测，缺字体不再等到第一次请求才 500 
- 系统候选补上 glyf 轮廓的 CJK 字体（文泉驿正黑/微米黑、DroidSansFallback、
  AR PL UMing），并把 Noto Sans CJK 压到最后：它是 CFF/OTTO，freetype 必定解析失败，
  排前面只会白白多读十几 MB
- static/fonts 同时按当前工作目录与可执行文件目录查找，systemd 没配
  WorkingDirectory 时也能找到（原先只按 CWD，文件在却报「没有可用字体」）
- 启动时探一次字体：命中打 Info 带路径，缺失打 WARN 并给出补救命令
  （apt install fonts-wqy-zenhei / 放 static/fonts/ / 配 font_path）
- .ttc 先提取首个字面再用（仅对 glyf 轮廓的集合有效，如文泉驿）；
  失败结果缓存 1 分钟，避免公开端点被「每请求重新解析十几 MB」放大

实测：本地实例 apt install fonts-wqy-zenhei 后无需任何配置，启动即打出
font=/usr/share/fonts/truetype/wqy/wqy-zenhei.ttc，/share-card 与单题分享图
从 500 变为 200 image/jpeg，中文与二维码渲染正常。
 2026-10-27 12:37:48 +08:00
tamakyi 7802bb2078 fix(security): 修复安全审计的 P1/P2/P3 项，含全局复查新发现的两处越权与外跳 
P1：
- 外链图片：markdown 渲染层只放行站内与自有 CDN 图片。配置里的
  image_bucket_cdn_host 常写成 host/path，统一归一化后再比对，避免把自家图一起剥掉
- 密码：页面/提问密码最小 6 位；密码比对挪到验证码之后；页面密码失败锁定 5 次/10 分钟
- 客户端 IP：CF-Connecting-IP / EO-Client-IP 只在 TCP 对端可信（回环或 trusted_proxies）
  时采信，公网对端带来的权威头一律忽略

P2/P3：
- 跳转参数收敛到 shared.SafeRedirectTarget：拒反斜杠与控制字符（url.Parse 会把 %0d%0a
  解成 CRLF，伪造 Location），最后再用 path.Clean 验一次前缀
- 注册不再暴露「邮箱已注册 / 已停用」：与全新注册共用同一个成功出口，只在日志留痕
- CSP：默认 enforce，白名单由配置派生，覆盖 umami（运行时注入）、Turnstile 与
  按 sentry_dsn 条件放行的 Sentry CDN
- /user 与 /_ 下发 no-store；补 X-XSS-Protection、Permissions-Policy，并把安全头前移到
  静态资源中间件之前（原先静态文件拿不到 nosniff/HSTS）
- 封禁事实落库 ban_records；429 统一带 Retry-After 与本地化文案
- token 比较改常量时间；探索页页码上限；JSON 响应显式 Content-Type

全局复查补的两处：
- 私聊 SendMessage 的 POST 缺 conv.OwnerID 校验，被拉黑者可换 domain 继续发消息
- 页面密码 next 与登录 to 同源的反斜杠外跳

验收：verify_p1_fixes 4/4、verify_round2 19/19、verify_page_next 6/6、
verify_chat_owner 3/3（含变异对照）；单测与 go build ./... 全通过。
 2026-10-27 12:37:40 +08:00
tamakyi a3cf99a8da fix(stats): 环比句点明月份与条数，不再写「上月…环比 -75%」 
「上月提问量环比 -75.0%」这句要读者做两次翻译：先把「上月」翻成具体月份，
再把「环比」翻成「比上上月」。两个相对词叠在一起，站长本人看到就以为
是「上月同期 vs 本月同期」—— 而它其实比的是两个完整自然月。

  改前：上月提问量环比 -75.0%。
  改后：9 月收到 5,620 条提问，比 8 月的 4,890 条多了 14.9%。

口径一个字没改（仍是上月 vs 上上月，本月没过完不参与），只是把月份和条数
写进句子：读者不需要知道「环比」的定义也能判断这句话在说什么，还能顺手
核对百分比（5620/4890 确实是 +14.9%）。

实现：
- `monthText` 按语言出月份名 —— CJK 一律「9 月」，英文要 "September"
  （"month 9" 不是英语的说法）。不带年份：相比的两个月相邻。
- 一个词条拆成 momUp / momDown / momFlat：方向词塞不进同一个模板，
  四种语言里「多了 / 少了」的位置和词形都不一样。
- `|pct| < 0.05` 走持平，否则会出现「多了 0.0%」。

测试：`TestInsightMoMNamesBothMonths` 锁住「句子里同时有两个月份名和两个条数」，
覆盖上升/下降/持平；`TestMonthText` 锁语言差异。

顺手修预览数据：`zz_preview_test.go` 的 `GrowthMoM` 原来写死 12.3，和它造的
monthly 对不上。以前句子里只有百分比无所谓，现在会连条数一起印出来，
截图就成了「5,620 比 4,890 多了 12.3%」这种假证据，改成从数据算。
 2026-10-25 09:27:57 +08:00
tamakyi 79199ac3cd fix(stats): 删掉「没有推测」这类对站长说的话，文案统一以访客为读者 
「数据速览」下面那句「下面几句是从上面的数字直接读出来的，没有推测」，
是在向读者解释「我没有编」—— 那是作者视角的免责，不是访客需要的信息。
读者看到「没有推测」只会想：那我该怀疑什么？删掉，卡片留标题 + 结论列表
即可（`stats.insight.title` 已经说明这组是什么）。

顺着把整页 40 余条文案过了一遍，同类的还有页脚：

  「累计数字与图表是当天重算一次的快照（当天第一次访问时算，服务重启也会重算）」
  → 「累计数字与图表每天更新一次」

访客不需要知道缓存是懒重算、更不需要知道重启会触发重算；真要精确的新鲜度，
上一行「快照时间」已经给了到秒的值。这条注的职责只是说清「累计按天、今日实时」。

保留的两处，判断过不属于这个问题：
- `stats.foot.privacy` 与顶部 `stats.lead` 后半句近乎同义 —— 页脚隐私声明是惯例，
  重复一次不算噪音，删了反而有人以为底部没声明。
- 「（实时）」在 60 秒缓存下仍成立。

删掉说明行后标题与列表之间只剩 4px，给 `.tb-insights` 补 `margin: 8px 0 0`
（原来靠 `tb-card-note` 的 16px 撑开）。顺手修掉模板里一条过期注释 ——
它还写着「四条时间」「哪个是基准日」，上一轮已改成三行「快照时间」。

i18n 四语言同步（有词条数量对等测试兜底）；build + i18n/stats/template/templates
测试全绿，中英页脚与数据速览卡片截图确认过间距。
 2026-10-25 09:18:00 +08:00
tamakyi af39651734 fix(stats): 页脚时间标签改成「快照时间」，去掉重复的「数据基准日」 
原来四行时间里，前两行说的是同一件事：
「数据基准日：2026-10-24」+「计算于：2026-10-24 14:05:22」。
`DataDate` 就是 `UpdatedAt` 的日期部分（同一个 now 格式化出来的），
两行并列只是把同一个值拆成粗/细两种粒度。

而且「计算于」没有主语：读者站在页脚最底部看到它，会当成「整页数据
算到这一刻」，可今日两项恰恰不在这份快照里 —— 命中缓存时
`withToday` 会用更新的读数替换它们，页面上就出现「标注 14:05、
今日提问却是 22:35 的数」。

改成三行：
  快照时间：     2026-10-24 14:05:22
  最后一条提问： ...
  最后一条回答： ...
「快照只含累计数字与图表、今日两项实时」由下面那条 cacheNote 说明，
不塞进标签里（标签越短越好扫）。词条同步：快照时间 / 快照時間 /
Snapshot: / 集計時刻。

顺带删掉 `Overview.DataDate` 字段：模板不用它之后就没有读者了，
留着它会诱使以后的人再拼出「基准日 + 计算于」这种重复行。

无 schema/接口变更，纯展示层。i18n 有词条数量对等测试，四个语言已
一起改；`go build ./...` 与 i18n / stats / template / templates /
route 测试全绿。
 2026-10-24 22:39:47 +08:00
tamakyi 219adefc95 fix(stats): 「今日回答」改按 answered_at 计，不再把置顶算成回答 
`TodayCounts` 的今日回答数用 `updated_at >= 0 点` 过滤。GORM 的 Update
一律刷新 updated_at，于是箱主今晚整理一批三个月前的老问题（置顶、
公开/私密切换，一次回答都没发生），/stats 顶部「今日回答」就凭空多出几十条。

实测（临时测试，跑完已删）：一条三天前回答的提问，依次 SetPinned /
SetPrivate / SetPublic 之后，today answers 从 1 变成 2。

改成 `answered_at >= since`（首次回答时间，改写回答不重置）：
口径变成「今天首次被回答的提问数」，与页面文案「今日回答 / Answered
today」和「回答耗时按首次回答算」都对齐。历史行 answered_at 为空时
`>=` 不成立、自然不计数 —— 那些行本来也不可能「今天被回答」。

性能：answered_at 没有索引，这条 COUNT 是全表过滤；但改动前的
updated_at 同样没有索引，本来就全是 Seq Scan。20 万行实测
旧 36.7ms / 新 38.0ms（差 3.5%，噪声级），执行计划都是
Seq Scan + Aggregate。页面另有 60 秒缓存，不需要为它加索引；
注释里写了真慢了再加 idx_questions_answered_at。

新增 TestTodayAnswersIgnoreNonAnswerWrites（改前红：期望 1 得到 2；
改后绿）。
 2026-10-24 10:37:36 +08:00
tamakyi 8380fc9e2b fix(db): 「最后一个回答」不再被置顶/公开切换推到现在 
`QuestionStats` 的 `last_a` 取的是 `MAX(updated_at)`，而 GORM 的 Update
一律刷新 updated_at：置顶、公开/私密切换、标记已读都会走 Update。
后果是箱主整理一下旧问题（一次回答都没发生），公开接口
`/api/v1/site-stats` 就说「刚刚有人回答了」。

实测（真库，临时测试已删）：一条 9 天前回答的提问，置顶/公开切换后
LastAnswerAt 从 `10-15 10:23` 变成 `10-24 10:23`，偏差 216 小时。

改成 `COALESCE(answered_at, updated_at)`：
- 新数据取 answered_at（首次回答时间，改写回答不重置）；
- 加列之前的历史行 answered_at 为空，退回 updated_at —— 与改动前口径
  一致，不会让这些行从统计里消失（有测试锁住这一半）。

同时删掉 `GetHotQuestions`：全仓零调用点（只有接口声明 + 实现，route/
里 Questions 的 15 个调用不含它），且同样按 updated_at 排序 ——
死代码 + 错误排序，留着就是给以后的人埋坑，要用时按 answered_at 重写。

影响面：`/api/v1/site-stats` 的 `last_answer_at` 字段与 `text` 里的
「最后一个回答发生在」，字段名与结构不变，只是值更准（更早）。无 schema
变更、无接口变更。性能：执行计划仍是 Seq Scan + Aggregate，5 万行实测
7.9ms vs 8.0ms，差异在噪声带内（0~1.8ms，折合每行约 30ns），
而该接口有 30 分钟进程内缓存。

新增两个回归测试：
- TestQuestionStatsLastAnswerIgnoresLaterEdits（改前红、改后绿）
- TestQuestionStatsLastAnswerFallsBackToUpdatedAt（历史行回退）
 2026-10-24 10:30:43 +08:00
tamakyi cbb8908275 feat(stats): 近 30 天折线补纵轴刻度 
原来这条折线只有横轴日期，纵轴没有任何参照：读者看到峰谷不知道自己
在看 3 次还是 300 次的起伏。现在补上三条刻度（上限 / 一半 / 0）加对应
的横向虚线。

纵轴上限取 niceMax(峰值)，不是峰值本身。峰值正好压在顶格里时，读者
分不清那到底是确切的数还是被裁掉的数；向上取整到 1/2/1.5/3/4/6/8×10^n
之后顶部留白固定，三条刻度又都是整数和好读的数（1.5 倍只在量级≥100
时参与，否则算出来是 7.5 这种半格）。上限恒为偶数，中间刻度必然是整数。

刻度文字不放进 SVG：viewBox 用 preserveAspectRatio="none" 横向拉伸填满
卡片，里面的文字会跟着被拉扁，窄屏尤其明显。改成左边一列 HTML 标签 +
横向虚线仍在 SVG 里（描边锁 non-scaling-stroke）。列宽靠一份看不见的
「最宽刻度」占位撑开，不写死 em。

同时把 Polyline/AreaPath 收敛成单个 NewLineChart：坐标、面积、刻度必须
共用同一个上限，分两次算就会各按自己看到的峰值归一化，出现刻度和线错开
的图。面积路径改为沿基线闭合，不再漏进轴标签的留白区。

新增 chart_test.go 锁住三条不变式：中间刻度必为整数、上限不离开峰值一倍、
刻度/折线/面积共用上限；另有 0..2000 的穷举检查。
 2026-10-24 01:57:36 +08:00
tamakyi 0226956feb fix(stats): 回答耗时改用 answered_at，修测试环境实测出的三处问题 
在测试环境（box-dev-api）上逐项验算后发现「回答耗时」这一口径是错的。

1. 回答耗时不能用 updated_at - created_at（P0）
   GORM 的 Update 会自动刷新 updated_at，而已读、置顶、公开/私密切换全走 Update。
   实测：一条 10 天前的提问被 SetRead 标记已读后，updated_at 被推到当下（delta=240h）。
   于是「回答耗时」实际测的是「提问到最后一次被碰」：线上那 6 条「超过 7 天」
   和偏低的 24 小时回复占比都是这么来的。
   修法：新增 questions.answered_at（首次回答时间，可空），只在 answer 由空变非空时
   写一次，改写回答不重置；聚合改用 COALESCE(answered_at, updated_at)，
   首次加列时用 updated_at 冻结历史一次（Migrator().HasColumn 判断是否刚加列），
   否则历史值会随着后续的已读/置顶继续变大。

2. 环比句式读不通
   中文「上月提问量比前一个月 -69.6%」、英文「...: -69.6% questions.」都是病句。
   改为「上月提问量环比 %s%%」/「Month-over-month change for last month: %s%%」。

3. 脚注说「当日 0 点的快照」不实
   实际是当天第一次访问时算、服务重启也会重算（实测算出时刻 01:11:50，
   基准日却写 2026-10-24，说明它含了 0 点之后的数据）。改成准确描述。

4. 数据库故障时请求会排成 N×30s
   ovRefresh 串行化 + 30 秒超时意味着数据库挂起时第 N 个请求要等 N×30 秒。
   加 30 秒失败冷却：冷却期内直接降级（有旧快照用旧快照），不再碰数据库。
   todayNumbers 失败也盖时间戳，不再每个请求都打两条 COUNT。

测试：新增 internal/db/answered_at_test.go（5 例：只记一次、私密路径也记、
分桶以 answered_at 为准、历史行回退、回填），并做过变异验证 —— 把口径改回
updated_at 后测试立即失败。internal/stats 补 3 例冷却测试。全量构建与测试通过
（internal/storage 的构建失败是 overlay 桩的既有问题）。
 2026-10-24 01:45:34 +08:00
tamakyi 0c282914c2 fix(stats): 今日计数不再被每日缓存冻结，日期分组不依赖库会话时区 
自查部署结果时发现两处正确性问题，都是本页上线时引入的：

1. 「今日提问 / 今日回答」原本随整页聚合一整天缓存，页面却写着「实时」，
   实际当天第一次访问后数字就冻住到次日。现拆出 TodayCounts 单独取，
   60 秒 TTL、跨日按日期失效；命中整页缓存时返回副本，不原地改缓存指针
   （那会被并发读踩成数据竞争）。

2. 日/月/时分组用 to_char/EXTRACT 直接作用在 timestamptz 上，结果跟着数据库
   会话时区走，而 PG 官方镜像默认 UTC、Go 侧按容器时区(Asia/Shanghai)切今天。
   实测同一条 2026-10-24 01:30+08 的提问，UTC 会话下被算成 10-23 17 点 ——
   日报表整体偏 8 小时、热力图时段错位，且与「今日」对不上。
   现统一经 analyticsLocalize() 加 AT TIME ZONE INTERVAL 换算，偏移取自
   time.Time.Zone()（Go 未设 TZ 时给 "Local"，PG 不认该名，故不用 IANA 名）。
   过滤条件仍是裸列，索引照用。

另外两处顺手修：

- PeakDay 用 >= 比较，并列时会漂到最近的同值日期，与 busiestSlot 的取值规则不一致。
- 聚合改用 context.WithoutCancel + 30s 超时：第一个访客在聚合途中关掉页面时，
  排在后面等锁的请求不会各自重跑一遍全表 GROUP BY。

测试：新增 TestTodayNumbersNotFrozen（缓存命中后今日数仍更新、整页聚合当天只算一次）
与 TestTodayCacheExpiresAcrossMidnight；analytics 连真库通过。
 2026-10-24 01:20:02 +08:00
tamakyi 64436d9d61 fix(stats): 数据速览用完整星期名，脚注时间改逐行对齐 
- 「提问最集中在 三 19 点前后」：洞察复用了热力图列头的短标签
  stats.wd.*（一…日 / Mon…），那是为窄列头设计的单字词条，
  进句子就成了「三」。新增 stats.weekday.1..7 完整名（周一 / Monday /
  月曜日），洞察改用该组，stats.wd.* 只留给列头；补测试断言锁住。
- 页脚入口文案「数据」→「统计数据」（四语言同步）。
- 页面脚注四条时间由「基准日 x · 计算于 y」一行改为两列网格逐行排列，
  标签统一带冒号，下面两段说明保持独立段落。
 2026-10-24 01:08:50 +08:00
tamakyi a5441c99fd feat(stats): 新增公开数据页 /stats，入口收敛到页脚 
首页底部那张「站点统计」卡片下线，完整数据移到公开只读页 /stats：
今日实时数、概览六格、近 30 天折线与 12 个月柱状、三个占比环、
7×24 时段热力图、提问字数与回答耗时分布。

- 聚合在 internal/db/analytics.go（SUM(CASE WHEN)，方言差异收敛在 analyticsDialectFor）
- 结果按自然日缓存，跨日重算一次后全站共用；重算失败降级返回上一份快照
- 图表零前端依赖：服务端算坐标的 SVG + CSS grid，禁用 JS 页面仍完整
- 环比取「上月 vs 上上月」：本月未过完，否则每月 1 号会得出 -95%
- 入口只在页脚「社区规则」与「找站长」之间；route.Home 不再计算统计
- 补 questions(created_at) 索引；启动后异步预热当天快照
- 测试：analytics 连真库验证软删除不计入、分桶下标、DOW 对齐
 2026-10-24 00:57:08 +08:00
tamakyi c680671b7e feat(user/questions): 手机端时间跨年自动补年份，避免省略年份后产生歧义 
DateCompact：与当前同一年的渲染「月-日 时:分」，跨年补回完整「年-月-日 时:分」。
只砍年份会让「去年今天」和「今年今天」显示成同一串，逐条补年份比按年分组便宜得多
（列表带游标分页 + 可切排序/筛选，组标题会跨页重复或错位）。
桌面端不受影响，仍显示 Y-m-d H:i:s。
测试覆盖年份边界（同年 1/1 与 12/31、跨年）；预览数据里放了一条 2025 年的提问用于肉眼核对。
 2026-10-23 21:04:50 +08:00
tamakyi 812b70cb4c fix(user/questions): 筛选标签改为「已读 是/否」，手机端条目标签行不再折行 
- 筛选栏第 5 列标签「阅读状态」四字，在手机约 53px 的窄列里必然折成两行，
  改为「已读」，选项改为 全部/是/否（option value 仍是 read/unread，后端不变）。
  词条 qlist.readStatus 由 qlist.readFilter + qlist.filterYes/filterNo 取代，四语言同步。
- 条目行「时间 + 状态标签 + 标记/置顶」在手机上放不下：实测 360 宽可用 306px，
  完整时间单条就占 127px，2 标签 + 2 按钮需 343px。手机端时间改为「月-日 时:分」
  （tb-short/tb-text 复用状态标签的 640px 断点，桌面端仍显示完整年月日时分秒），
  同时把 .qlist-pill 的基础内边距 40/8 收到 34/6（桌面 @media 仍覆盖回 62/10）。
  结果：2 标签 + 2 按钮在 360 宽即单行；三标签（私密+待答+未读）在 ≤375 仍会折行。
 2026-10-23 21:02:37 +08:00