tamakyi/tamabox
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
170 Commits 1 Branch 0 Tags
87176516f3d69f3aac2ebd532eb6b3a73dc5174b
Commit Graph
170 Commits
This Branch
This Branch
All Branches
Author SHA1 Message Date
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
tamakyi 86ea96e5ca feat(autoban): 封禁响应图改为 ban_image_path 配置，默认仍是纯文字 
上一版把 403 图 //go:embed 进了二进制。实际部署里图会集中放在 R2 统一管理、
由运维分发到各机器，进仓库反而成了负担：换一张图就要重新编译。

改为配置驱动：
- 新增 [security] ban_image_path（相对路径以进程工作目录为基准）；
- 留空 / 文件读不到 / 是目录 / 不是图片 / 超过 2 MB → 一律回退为纯文字
  "403 Forbidden"，即改造前的老行为。封禁响应是最后一道兜底，不能因为
  一张图缺失就变成 500，更不能把站点拦在启动阶段（失败只 Warn）；
- 启动时读一次装进 atomic.Pointer，热路径零磁盘 IO；换图 = 换文件 + 重启。

安全细节：按内容嗅探（http.DetectContentType）而不是扩展名，必须是 image/*。
把 ban_image_path 配成 app.ini / .env 会被拒绝并告警 —— 否则等于把配置文件
原样吐给每一个被封的攻击者。这条有专门的用例与变异验证。

顺带删掉 internal/route/assets（webp + embed），已无引用。

测试：
- TestWriteBannedTextFallback：未配图 → 403 + text/plain + 13 字节明文；
- TestWriteBannedServesConfiguredImage：配了 1×1 PNG → image/png（按内容嗅探）、
  Content-Length 与文件一致、body 与文件逐字节相同；
- TestLoadBanImageRejectsBadInput：不存在 / 是目录 / 非图片 / 空文件四种配置错误
  都不得装载，且**不得把文件内容当响应体吐出去**；
- TestLoadBanImageTooLarge：超 2 MB 拒绝；
- TestWriteBannedHead：两条分支的 HEAD 都只回头不给 body。
变异验证：去掉 image/* 校验 → 用例报「把文件内容当响应体吐了出去：
"[server]\nsalt = secret"」；强制走纯文字分支 → 配图用例按预期变红。

实测：真 webp 嗅探为 image/webp；app.sample.ini 嗅探为 text/plain 被拒。
 2026-10-23 15:25:07 +08:00
tamakyi 6fad0cbe50 docs: 说明封禁响应的图片体与替换方式 2026-10-23 15:04:14 +08:00
tamakyi 0318ba81b4 feat(autoban): 封禁响应体改成一张 403 图片 
被封禁来源访问任何路径时，原来只回 13 字节的 "403 Forbidden"：既没有信息量，
人肉访问（尤其是共享出口被连累的误封）时看着像站点挂了；扫描/爆破脚本也常靠
读这行明文确认「自己已被拦」。

改为返回一张 256×256 的 webp（约 8.6 KB，画面写着 403 Forbidden），状态码不变：
- 图片用 //go:embed 编进二进制，不依赖外部 URL、不占公开路径；
- 显式给 Content-Length（8 KB 超过 Go 的 2 KB 写缓冲，不设会退回 chunked）；
- Cache-Control: no-store —— 中间层缓存 403 没有意义，还会让解封后的响应继续命中；
- HEAD 只回头不写 body；
- 放在 internal/route/assets/ 而不是 static/：static 下的东西有可公开访问的 URL，
  等于多一个指纹入口。

注意链接：给的 R2 预签名地址 X-Amz-Expires=604800（7 天），热链到期就会挂，
所以是把字节取回来打包，而不是重定向或代理。

测试：
- TestWriteBanned：状态码 403、image/webp、Content-Length 与内嵌字节数一致、
  body 前 12 字节是 RIFF/WEBP（防止被换成 HTML 或明文这类回归）；
- TestWriteBannedHead：HEAD 无 body 但有 Content-Length；
- 原 TestHoneypotBansEvenWhenAutoBanDisabled 里断言 "403 Forbidden" 明文的用例
  改为断言 image/webp 与体积。
变异验证：把 writeBanned 改回写明文 + text/plain，两条用例均按预期变红。
 2026-10-23 15:04:13 +08:00
tamakyi 9d3f5a72fa docs: 补 XML-RPC 端点行为、动态 token 与 .php 变体说明，记实现取舍 2026-10-23 12:58:49 +08:00
tamakyi 307bd94ed1 feat(honeypot): /xmlrpc.php 走真实 XML-RPC，动态 token 不再恒定 
线上验收发现两个「能被指纹识别」的破绽，都不影响原有功能但削弱伪装：

一、/xmlrpc.php 回的是 HTML 登录页（P1）
我们自己发的响应头里就有 X-Pingback: /xmlrpc.php —— 扫描器顺着跟过来，
一看是 HTML 就知道整站是假的（真实 WordPress 在这里回 text/xml）。
更可惜的是 system.multicall 这条通道被浪费：一次请求能带上千组用户名/密码、
且绕开登录页限速插件，是 WP 爆破里产出最高的入口。

新增 xmlrpc.go：
- 非 POST → 405 + fault「XML-RPC services are disabled on this site.」（与真实 WP 一致）
- POST methodCall → 200 + fault「Incorrect username or password.」（不区分用户是否存在）
- POST system.listMethods → 200 + 方法列表（枚举类工具靠它确认对面是真 WP）
- 凭据提取刻意不上 encoding/xml（蜜罐被高频命中）：抓所有 <string>、剔除
  methodName 与站点 URL 后两两配对。wp.getUsersBlogs 的 blog_id 若是短数字会让
  配对错位一位，故「奇数长度 + 首项短数字」时丢首项；另外原始串全量写进
  fields（xmlrpc.0/1/…），配对失败也不丢原文。
  multicall 的第一组进标准字段，其余进 cred2/cred3… —— 一个用户名配一长串
  密码是常见字典形态，只留第一组等于丢掉整份字典。
- 封禁与表单提交同规则：带凭据走 RecordHoneypot（立即封），否则走常规阈值。

二、进入页面的隐藏值每次请求都一样（P2）
两次请求拿到同一个 pma token / csrf_token / X-Jenkins-Session，任何脚本都能
判定对面是伪造的。改为按请求生成 32 位 hex（math/rand/v2 —— 这些是假 token，
不需要不可预测，只需要每次不同；crypto/rand 在 Windows 要走系统调用，贵一个量级），
页头、hidden 与 Set-Cookie 共用同一套。

顺带：
- X-Pingback 改绝对地址（$base/xmlrpc.php）。真实 WP 给绝对 URL，相对路径本身
  就是破绽；没配 external_url 时干脆不发这个头。
- Cache-Control 从 no-store 改 no-cache, must-revalidate, max-age=0
  （no-store 更像安全设备/代理加的，不像登录页）。
- Grafana / GitLab 补上真实产品会种的会话 cookie（grafana_sess、_gitlab_session）。
- Match 增加 .php 变体兜底：清单里是 /phpinfo，扫描器打 /phpinfo.php，
  原来漏掉 → 302 回首页，等于明确告诉对方「这个文件不存在」。

测试：xmlrpc_test（IsXMLRPCPath / getUsersBlogs / multicall / 数字 blog_id /
非 XML-RPC body / fault 与 listMethods 输出）、family_test（动态 token 两次不同且
是合法 hex、X-Jenkins-Session 与 correlation_id 动态、Pingback 绝对地址与缺省不发、
所有家族渲染后不残留 $ 占位符）、route 层（POST multicall 捕获凭据 + 立即封 +
回 text/xml；GET 回 405 fault 而非登录页）、honeypot（.php 变体命中且不牵连业务路径）。
四处变异验证均按预期变红：固定 token、xmlrpc 分支失效、Pingback 退化成相对路径、
.php 兜底失效。

性能：RenderFamily 3.7µs→4.18µs、2→3 allocs（多的一次是 hex 编码），
AssetFor 仍 0 分配。
 2026-10-23 12:58:48 +08:00
tamakyi 7225f680d4 docs(memory): 记录蜜罐家族伪装的实现取舍与预览工具的用途 2026-10-23 12:38:43 +08:00
tamakyi db97ac13ed docs: 蜜罐文档补家族伪装与资源开销 
honeypot.md：
- 开篇从「一个假 WordPress 后台」改为「按扫描目标伪装成对应后台」，列出 9 个家族
  与各自触发路径；
- §1 补静态资源的处理（回占位内容、不落库、插件 .php 回 404 的理由）；
- §3 封禁路径表补一行「Tomcat Basic 认证」的归属，说明 401 也走凭据通道；
- 补资源开销的实际数字，便于运维判断这功能值不值。

cli.md：paths 说明补家族汇总。
 2026-10-23 12:38:42 +08:00
tamakyi 811578dcf1 feat(honeypot): 按扫描目标伪装成 9 类后台，静态资源不落库 
原来所有诱饵路径都回同一个 WordPress 登录页。爆破工具的标准流程是
「先按路径判断这是什么后台，再拿它认识的字段名填表」——在 /phpmyadmin/index.php
上回 WP 表单，等于告诉对方「这里没有 PMA」，对方直接换目标，既拿不到凭据
也没有取证价值。

新增 family.go（皮肤表）+ asset.go（静态资源占位），page.go 改为按家族渲染：

  wordpress   /wp-login.php /wp-admin /wp-json    log/pwd、wordpress_test_cookie
  phpmyadmin  /phpmyadmin /pma /adminer.php       pma_username/pma_password、hidden token
  tomcat      /manager/html /host-manager         401 + WWW-Authenticate: Basic（无表单）
  jenkins     /jenkins /jnlpJars                  j_username/j_password、X-Jenkins
  grafana     /grafana                            user/password、深色主题
  gitlab      /users/sign_in                      user[login]/user[password]
  luci        /cgi-bin/luci /luci                 luci_username/luci_password
  joomla      /administrator                      username/passwd、hidden option=com_login
  generic     /admin /console /zabbix /jira…      username/password

Tomcat 刻意不给 HTML 表单：真实 Manager 未认证就是 401 + Basic 弹框，给表单
反而更假；Authorization: Basic 本就在 ExtractCredentials 覆盖范围内，捕获能力不减。

凭据字段：
- credentialKeys 扩 pma_* / j_* / luci_* / user[login] / user[password]；
- token 只用于判 HadFields，**移出 isPasswordKey** —— PMA/GitLab 的登录表单带
  hidden CSRF token，而 Fields 是 map、遍历无序，原来的实现会让 token 随机
  顶掉真密码，记录下来的「密码」时对时错。

资源占用（这是本次主要约束）：
- 渲染一页 3.7µs / 2 次分配 / 5.2KB（改前 12µs / 22 次 / 19.5KB）：
  不用 html/template（每次 ParseFS 是毫秒级 IO+编译），改单次 strings.Builder
  并避免 "a"+b+"c" 反复分配，Replacer 提到包级；
- 静态资源请求 55ns / 0 分配：CSS/JS 回常量片段、图片回真 1×1 PNG，
  **不解析 IP、不判封禁、不写库**——真实后台页一次加载 5–10 个资源请求，
  否则等于把页面浏览放大成十几条 INSERT。插件目录下的 .php 回 404（webshell 探测）。

honeypot paths 增加家族汇总，便于确认实际生效的分布。
新增 dev/preview-honeypot：把 9 个家族渲染到 outputs/honeypot-preview/index.html
再配 headless 截图核对外观——本轮两个「源码看不出、截图一眼假」的问题
（Tomcat 忘配 css 导致按钮白字无底色、WP 登录页底部挂着 404 文案）都是它发现的。

测试：TestFamilyOf / TestEveryFamilyRendersItsOwnFields / TestTomcatUses401Basic /
TestAssetFor / TestRenderIsCheap（4KB 上限）/ BenchmarkRenderFamily /
BenchmarkAssetFor，route 层 TestHoneypotServesFamilySpecificPage /
TestHoneypotCapturesFamilyFields / TestHoneypotAssetRequestsAreNotRecorded。
变异验证：资源短路失效 → 3 个资源全变 text/html 且落库；FamilyOf 恒返回
Generic → 页面缺特征字段。两项均按预期变红。
 2026-10-23 12:38:35 +08:00
tamakyi edde075406 update workbuddy file 2026-10-23 11:14:27 +08:00
tamakyi 29ddee07db docs(memory): 记录封禁键/取证地址分离的根因、测试与变异验证经验 2026-10-23 10:53:13 +08:00
tamakyi 90a284a3dd docs: 写清「封的是一把键」与取证地址的区别 
honeypot.md：
- §3 新增小节：LimitKey 折叠规则（IPv4 原样 / IPv6 折 /64）、邮件里两个地址
  各自含义、封禁只在内存里、建封 WARN 的字段与 grep 方法；
- §4 注明取证存的是精确地址，不是 /64 聚合键；
- §8 排障首行补「邮件说封了但还能访问」的三种原因与判定路径，
  并提醒「邮件里的来源 IP 不是封禁键，拿它对 ban_key 永远对不上」。
cli.md：stats 说明改为「来源排行（IPv6 按 /64 聚合）」，补 ip 语义。
 2026-10-23 10:53:12 +08:00
tamakyi 818fa74160 fix(honeypot): 取证记精确地址、封禁用 /64 键，并补建封与拦截日志 
线上实测：IPv6 访问蜜罐后收到「你的 IP 已被封禁」，邮件里却是
`2408:…::/64` —— 既不像自己的地址，也说不清封了多大范围；同时用户自己
仍能正常访问，看日志也无从判断到底有没有封。

根因是「取证地址」与「封禁键」混用同一个变量（都取 LimitKey 的折叠值）：
- 取证丢掉精确 IPv6 后 64 位，事后无法定位到具体主机、没法和其他日志对账；
- 邮件只给聚合键，运维第一反应是「不是我」，排查方向直接被带偏。

改动：
- Serve 拆 clientIP（ResolveClientIP，精确）与 banKey（LimitKey，/64）：
  DB / 凭据文件 / 告警邮件用前者，封禁 / 探测采样 / 告警去重用后者；
- autoban.Options 新增 OnBan 回调（保持纯标准库、不引入 logrus），
  route.newBanner 注入后每次建封打 WARN：ban_key / reason / duration / expires_at；
  中间件 403 分支加 Debug 日志（被封者会持续请求，Info 会被刷屏）；
- 告警邮件新增「封禁范围」行，仅 ip != ban_key 时渲染（IPv4 不重复显示），
  顺带把过时的「已入库」改为「写入取证文件」——凭据早就外置了；
- honeypot stats 的来源排行改按 LimitKey 合并，否则 IPv6 轮换地址会把
  排行碎成几十条各 1 次的记录；合并口径与封禁完全一致。

测试（每项都做了变异验证：改坏→确认变红→恢复）：
- TestHoneypotRecordsExactIPv6ButBansByPrefix：精确地址进 DB 与凭据文件、
  /64 才是封禁键、同 /64 换地址仍 403；
- TestOnBanCallback：建封回调带键/时长/原因，封禁期内重复命中不重复回调；
- TestHoneypotAlertTemplateRenders：IPv6 渲染封禁范围、IPv4 不重复；
- TestMergeSourcesByKey：同 /64 合并、IPv4 原样、limit 与空输入。
 2026-10-23 10:53:03 +08:00
tamakyi aa758884f9 docs(memory): 分享卡缓存 key 排查结论 2026-10-23 00:58:43 +08:00
tamakyi 675cecb21d fix(share): 单题卡缓存 key 补 user.Domain；纠正过期的 TTL 注释 
先查了「缓存 key 漏项」到底有没有实际影响，结论是**当前没有**：

- 用户域名只在注册时写入（register.go / CreateUser），没有改域名的入口，
  所以两张卡的二维码内容不会在运行期变化
- ExternalURL / ShareBackground 来自配置，改了必须重启，而缓存是进程内的，
  重启即清空 —— 不存在「配置变了缓存还在」的窗口
- 头像、背景上传走 R2 随机 key（picture/日期/随机 hex，内容不可变），
  换图必然换 URL，key 随之变化，不会出现「同名不同图」

只有一条理论缺口：域名要是将来能被修改，单题卡 key 没算 user.Domain，
会出现最长一小时的「二维码指向旧域名」。补上这一项成本为零，先按事实算进去。
shareCardCacheKey 本来就含 Domain，两张卡现在一致。

顺带把两处「TTL 30 分钟」的注释改成 1 小时（代码一直是 time.Hour）。
新增 TestShareCardCacheKeysCoverDrawnFields：逐个改动画进图里的字段，
断言 key 必须随之变化；去掉 user.Domain 后立刻报
"user.Domain is drawn on the question card but not in questionShareCardCacheKey"。
 2026-10-23 00:58:31 +08:00
tamakyi 8f849123f7 docs(memory): 两张分享卡部署复验（几何 + 四档宽度解码） 2026-10-23 00:38:53 +08:00
tamakyi d5398f9c2f docs(memory): 单题卡二维码 5px 与不落盘的决定 2026-10-23 00:27:27 +08:00
tamakyi 310f85156a perf(share): 单题卡二维码同样提到 5px/模块 
单题卡右侧卡片只有 210×255，二维码最大只能到 148px（37 模块 = 4px/模块），
缩到 480 宽照样解不出。

- QQRCardW 210 → 236、QQRCardH 255 → 300、QQRSize 150 → 190（37 模块 → 185px）
  卡片仍居中对齐（x 679、y 120），左侧文字区随 QQRCardX 派生，自动收窄 26px
- 二维码卡片绘制抽成 drawQuestionQRCard，可在测试里直接调用出图
- 新增 TestQuestionQRCardLayout：二维码必须正方形、模块 ≥5px、四边留白 ≥20px、
  居中偏差 ≤1px，TEST_PREVIEW=1 输出整卡 PNG；把 QQRSize 改回 150 立刻 FAIL

实测：二维码 185px（5px/模块）、居中偏差 0.5px、上下留白 34px；
gozxing 在 960 / 720 / 480 / 320 宽下都能解出正确链接。
 2026-10-23 00:27:07 +08:00