tamakyi/tamabox
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
174 Commits 1 Branch 0 Tags
1e9ffc07182b80569a0bb04dc10d630f4d6a7556
Commit Graph
90 Commits
Author SHA1 Message Date
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 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 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 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 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 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 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 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 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 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 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 b939d26ff0 fix templates v2 2026-10-22 17:49:25 +08:00
tamakyi bd02eb7ed2 fix templates v1 2026-10-22 17:04:10 +08:00
tamakyi 8941744621 new-sakura：顶栏改半透明磨砂，并立规矩禁止全透明 
线上（box.shiroko.one/_/tamakyi）两个现象来自同一处：`--tb-navbar` 是实色，
顶栏那条带（y=20..80）把从右上角长出来的花枝齐刷刷切掉一段。

第一版顺手改成 transparent —— 花枝完整了，但顶栏"消失"：导航失去依托，
文字直接压在花纹上。用户当场否掉，要求半透明。

- 顶栏：`rgba(253,246,248,0.72)` / 深色 `rgba(34,26,30,0.72)`，配
  `.uk-navbar-container{backdrop-filter:blur(12px)}`（令牌只能是颜色，模糊写在规则里）。
  0.72 有依据：导航文字 #6d555d 纯底 6.34:1，最坏情况（深花瓣在顶栏后面）压平后 5.08:1。
- 花枝 top -16px → 26px：顶栏半透明后，700~760px 宽度下枝头正好压在「登录」上（截图确认）。
- 手机底栏 #tb-mobile-utils 在 base.css 写死 rgba(255,255,255,.92)，粉底上是一条白杠，
  主题里改成同色系 0.92。
- 新增 TestNavbarNotFullyTransparent：拦 `transparent` / `rgba(...,0)` / `#rrggbb00`，
  并说明"这不是审美偏好，是踩过之后立的规矩"。变异验证过（改回 transparent 立即 FAIL）。
  约定同时写进 static/css/themes/_scaffold.css 的令牌说明。
- StaticVersion 20261022b → 20261022c：css 改了不提版本号，浏览器拿着旧样式，
  现象就是"改了但线上没变"。
 2026-10-22 16:05:37 +08:00
tamakyi 2981731d4f announcement v3 2026-10-22 15:28:04 +08:00
tamakyi e1e840f895 announcement v1 2026-10-22 15:08:24 +08:00
tamakyi c9f22cb81b 修窄屏装饰层压不住作用域块（手机上一直显示桌面版樱花） 
@media 不提升特异性：作用域块 html[data-theme-style][data-page-scope="box"] 是 (0,2,1)，
媒体查询里写的 html[data-theme-style] 只有 (0,1,1)，于是「窄屏装饰层全置 none」这行
从来没生效 —— 手机上照样铺开桌面的花枝与花朵。深色作用域块是 (0,3,1)，更压不住。

- 媒体查询里补三条同特异性的通配规则（作用域 0,2,1 / 深色基础 0,2,1 / 深色+作用域 0,3,1），
  媒体块在文件更后，同特异性即胜出。
- 新增 TestNarrowMediaOverridesScopedDeco：外层每处非 none 的 --tb-deco，都要求窄屏里有
  同属性名、属性数不少于它的声明。变异验证过（删掉深层那条立即 FAIL）。
  它同时报出 shiroko 的 900px 块只覆盖浅色 —— 但深色块本就是 none，不算缺陷，故跳过。
- 窄屏改由加强版底纹承担樱花（透明度 ×1.9、格子 180px）：桌面那套 0.18~0.34 的透明度
  在 390px 上实测接近纯粉。顶栏与卡片之间那条 35px 带子试过放小花，question/admin 页卡片
  从 y=110 起会切掉一半，最终不放装饰层。
 2026-10-22 11:18:29 +08:00
tamakyi 48a1938fb2 新增 new-sakura 主题：纯 CSS 樱花，每个页面位置不同 
樱花不依赖任何图片素材：整朵花、带缺口的花瓣、带枝的花朵树都是内联 SVG 的
data URI，写在主题 CSS 里。好处是零请求、任意缩放不糊、换花色只改一个色值；
代价是 CSS 约 50KB（gzip 约 12KB），走 StaticVersion 缓存。

- 六个页面作用域各一套 --tb-deco 位置（global / box / question / admin /
  profile / vote），10 槽三组等长；位置一律「关键字 + 偏移」两值写法。
- 窄屏（≤640px）装饰层全关、底纹缩到 200px：卡片占满宽度后枝条会糊在字上。
- 深色换亮一档的粉、关掉底纹（浅粉压在深底上会变噪点）、背景用渐变避免死黑。
- 亮色 primary 从候选 #c14a72（4.39:1）压深到 #b8436a（4.87:1），
  muted 5.27:1，都踩住 AA；深色对应 8.17:1 / 5.82:1。
- 生成脚本 dev/theme-tools/gen_new_sakura.py（花形、位置表、配色都在里面），
  CSS 是产物，不手改。
- 四份词典加 theme.name.new-sakura；conf/app.sample.ini 的 available 登记。

为什么不用生成器：生成器的装饰层只认图片素材，没有内联 SVG 图层，
见 docs/theme-new-sakura.md「为什么不用主题生成器出图」。
 2026-10-22 10:45:39 +08:00
tamakyi 34a262091b 修 shiroko 单车/步枪素材「白色没抠」：白上白只能全白转透明 
根因不是抠图参数：素材是白底+白车架，车架涂装与背景白是同一个值（都是 #f9f9f9），
颜色上无法分离。四角 floodfill 只吃掉外圈，轮圈内、车架三角、车筐、枪与车架之间的白整块留着，
量化就是不透明像素里近白(>240) 占 50%。

- 处置：min(r,g,b)≥238 软过渡 + 饱和度>14 保留彩色 → 白全透明。近白降到 0.0%，
  不透明率 19.4%，29KB；轮辐/车架/车筐成为描边，粉轮圈、蓝枪托、接触阴影保留
- 试过「按近白厚度区分白洞与白涂装」（腐蚀测厚度）→ 失败：轮辐间扇形白楔 9~13px 与车架管
  5~10px 重叠，阈值怎么调都会留白楔，比原图更难看
- 画布保持 397×259 不裁：deco-size 是 auto 259px，宽度按比例算，裁了锚点会漂
- css 图片 ?v= → 20261021a；StaticVersion 20261021c → 20261021d（css 内容变了必须换缓存键）
- docs：assets-spec 补「白上白」取舍与验收项「不透明像素近白占比≈0」，theme-shiroko 素材表同步
 2026-10-21 19:18:50 +08:00
tamakyi 1f29d3eb2e 修设置页主题色块被模板过滤器替换成 ZgotmplZ 
html/template 对 style 属性做 CSS 过滤，linear-gradient(...) 未标记安全会被整体替换成
ZgotmplZ —— 线上设置页四个主题色块一直是灰底（既有问题，不是这次配色改动引入）。

- FuncMap 新增 safeCSS（string → template.CSS）；值只来自 internal/theme.swatchOf，
  由两个已校验的色值拼成，不接受用户输入，所以这里放开是安全的
- user/profile.html 的色块改 {{ safeCSS .Swatch }}
- 新增 TestThemeSwatchRenders：渲染 user/profile，断言不含 ZgotmplZ 且含渐变串；
  已做变异验证（去掉 safeCSS 后该用例失败）
 2026-10-21 18:53:10 +08:00
tamakyi 27856dd4a2 字号阶梯收尾 + 主色补到 WCAG AA（新增 --tb-on-primary） 
一号事项（剩余令牌化）：
- templates/user/profile.html 20 处、base.css 9 处 font-size 全部落到 --tb-fs-*
- base.css 导航四档（0.95/0.88/0.82/0.78）合并成「桌面 md → ≤1000 xs」；logo 三档统一 lg
- 有理由保留的：.tb-pin-flag / .md-body code 的 0.9em（相对父级）、验证码 1.4/1.2rem（等宽字形）、
  chat 关闭按钮 40px、password 页 3em、mail/*（邮件客户端不保证 var()）；行内 12px/0.75rem 等值顺手换掉

二号事项（主色对比度）：
- base/default #1e87f0(3.42) → #0e6fd0(4.70)；shiroko #4a7fc1(3.69) → #3b6dac(4.74)；
  sakura #e5678f(2.80) → #ba3e66(4.70，饱和度压到 .5 保持柔和)。同色相只压亮度，目标 4.7 留余量
- 深色块 muted 之前只对 --tb-bg 算（4.7 以为过了），对压平后的卡片其实 4.31/4.17 → 提到 #a18790 / #7f8ea1
- 新增 --tb-on-primary（亮 #ffffff / 暗 #0b1016）：深色模式主色偏亮，白字只有 2.2~3.1:1，
  用同一个令牌兼顾「链接色要深」和「按钮底要深」是矛盾的。.uk-button-primary 与
  .uk-label:not(语义色) 改吃它 → 深色按钮变成浅底深字（6.10 / 8.65 / 7.27）
- 顺手封掉几处主色泄漏：header 验证码 focus、profile .feat-day.is-on、explore 随机投票的 JS outline、
  vote-results 行内色，全部改成令牌（否则换主题时不跟着变）

生成器同步：paletteVars 导出 --tb-on-primary（白字/深字择优）；?dump=palette 增加
onPrimaryCr / onPrimaryPickedBest / warnings —— 主色卡中间调时只警告不判失败；
配色面板给橙色提示。_scaffold 令牌 29 → 30。StaticVersion → 20261021c。

验证：TestSwatch 断言同步为 #ba3e66；8 种组合（base 亮暗 + 三主题亮暗）对比度全部 ≥4.5；
go test internal/{theme,templates,conf,i18n} 全绿；生成器 validate/fit/quality/palette/layers/fx/fxpipe 全过。
 2026-10-21 18:39:08 +08:00
tamakyi db4b3fa095 主题体系跟上设计令牌化：派生文字色按对比度下限、主题 muted 补到 AA 
生成器（dev/theme-builder）：
- paletteVars 的 text-secondary/text-muted 从「往底色混 36%/55%」改成 mixToContrast(5.5/4.5)：二分找最淡且达标的位置，文字本身不达标就原样返回
- 半透明卡片先 flatten 压平到底色再算对比度；参考背景取「页面底色 + 压平后的卡片」中更不利的
- 配色面板加读数（正文/次要/淡文字/主色），低于 4.5 变橙；默认 primary #4a7fc1(3.69) → #3d6fac(4.63)
- 新增 ?dump=palette 四种配色回归；README 补配色一节

主题/base（含用户本轮 base.css 改动）：
- sakura muted #a08c94(2.8:1) → #78696e(4.61)、shiroko #8794a7(2.76:1) → #656e7a(4.63)：主题覆盖令牌，基座的 AA 修复到不了主题页
- 深色顶栏链接补 secondary 覆盖：亮色块已是次要文字色，深色块原来 !important 定成正文色，同一顶栏权重跳一档
- _scaffold.css 令牌清单 23 → 29（补 fs 阶梯与 page-position），muted 说明 AA 下限
- StaticVersion 20261021a → 20261021b
 2026-10-21 17:42:43 +08:00
tamakyi 74312fba58 fix(honeypot): cleanPath 处理零宽字符，并在清洗生效时打诊断日志 
上一版只用 strings.TrimSpace，实测漏掉「看不见但不算 White_Space」的字符：
  cleanPath("\u200b/wp-login.php") = "/\u200b/wp-login.php"
（零宽没被删，还因为首字符不是 '/' 多补了一个斜杠，拼出更怪的路径）

改为 TrimFunc 同时匹配 unicode.IsSpace 与 U+200B/200C/200D/FEFF，且只处理首尾
—— 中间的零宽字符可能是攻击 payload，取证要保留原样。

另加诊断日志：清洗前后不一致时 WARN，用 %q 打出原始值。
测试环境出现过「记录里 path 带前导空白、本地链路却复现不出来」的情况，
不可见字符必须转义输出才定位得到。

测试：TestCleanPath 补零宽空格 / BOM / 中间零宽字符保留三个用例。
 2026-10-21 16:18:25 +08:00
tamakyi 846bb8a3d9 fix(honeypot): 清洗反代链路的脏路径，回环来源 IP 打配置告警 
测试环境实测（Cloudflare → nginx → 源站）发现两处：
1. 凭据文件里记录的 path 是 " /wp-login.php"（前导空格）；
2. 来源 IP 记成 127.0.0.1。

path：Match 内部会 TrimSpace 所以仍能命中，但落库与假表单 action 用的是原始
req.URL.Path —— 取证数据带脏字符，爆破脚本还可能把表单提交到错误路径。
新增 cleanPath(trim + 补前导斜杠，不改大小写) 在 Serve 入口清洗一次。

IP：记录到回环地址说明站点在反代后面但 [security] trust_proxy 未开启。
此时所有访客在源站眼里是同一个 IP：取证数据失去意义，且一次蜜罐封禁会
连带封掉整站（含普通访客）。新增一次性 WARN（24h 冷却），只提示不改行为 ——
本地直连调试时回环 IP 属正常。sample.ini 的 trust_proxy 段补对应说明。

测试：TestCleanPath / TestIsLoopbackIP 覆盖前导空格、制表符、空串、
无前导斜杠、大小写保持，以及 shared.LimitKey 折叠后的 "::/64" 形式。
 2026-10-21 15:54:39 +08:00
tamakyi c29e1d071f fix(honeypot): 补齐封禁装配与诱捕语义，凭据外置为文件不再入库 
一、封禁链路整条没接上（P0，已实测复现）
route.New 的 autoban.New 漏传 HoneypotEnabled/Threshold/Duration，而
RecordHoneypot 首行就是 `if !b.honeypotEnabled { return false }`
→ 蜜罐命中从不封禁、落库 banned 恒 false、IsBanned 永不为真。
同一批改动又把中间件里蜜罐路径的常规计数也跳过了，净效果是蜜罐路径
从「10 次封禁」退化为零计数零封禁 —— 是 regression 不是修复。
处理：抽 newBanner() 作为唯一装配入口并补齐参数；新增 banner_config_test
四个用例（全部经由 newBanner，不再自建 Banner）。变异验证：分别把
HoneypotEnabled 置 false、HoneypotThreshold 置 0，对应用例按预期失败。

二、诱捕语义（审计时漏掉，比上面更影响功能价值）
原实现对**所有方法**计数且阈值 1 → 扫描器 GET 一次假登录页就吃 403，
永远走不到「POST 提交账号密码」那一步，蜜罐的核心价值（拿到字典）归零。
处理：提交凭据 → RecordHoneypot（不受 enable_auto_ban 约束，立即封）；
纯探测 → 常规 Record（阈值 10）。新增 TestHoneypotProbeDoesNotBanImmediately，
变异验证：把 GET 也塞进 RecordHoneypot，测试按预期失败。

三、落库边界（实测取证，非推断）
- Path 原样落库而列宽 512 → PG `SQLSTATE 22001 值太长了(512)`，整条证据丢失；
  实测 600 字符失败、500 字符成功；
- 三处按字节截断 → `SQLSTATE 22021 无效的 "UTF8" 编码字节顺序`（中文密码/URL
  可稳定触发）。统一改 rune 截断并按列宽逐项对齐。

四、资源与噪音
- alerted 无界 map → 带 TTL 的 deduper（上限 2 万，过期清理 + 超限硬裁），
  同时承担告警 24h 冷却与纯探测落库采样（每 IP 每分钟一条）——
  GET 洪泛不再变成等量 INSERT；
- credentialKeys 去掉 id/name，普通 JSON 探测不再被误判为凭据提交并触发假告警；
- canary 从 meta generator 移到 HTML 注释，generator 伪装成 WordPress，
  不再同时向扫描器自曝「这是蜜罐」和「这站是 TamaBox」；
- serveLoginFailure 复用 WriteLoginPage，不再手抄响应头（已开始漂移）；
- Describer 死代码 → Prefixes()，接到新命令 honeypot paths；
- honeypot_paths 解析挪到 honeypot.SplitPaths（CLI 与 route 共用），
  补前导斜杠、拒绝 "/"（会让所有 404 变假登录页）。

五、凭据外置：数据库不再存用户名/密码
明文账号密码一旦入库就会跟着进备份、主从复制与任何能连库的报表工具，
事后无法彻底清除。改为：
- 新增 honeypot.CredRecord/CredStore：按天文件 creds-YYYY-MM-DD.jsonl，
  目录 0700、文件 0600、坏行跳过、PurgeBefore 只删整天过期的文件；
- db.HoneypotHit 删掉 Username/Password/Fields/RawBody，只留 HadFields 元数据；
- HoneypotStore 删掉 TopCredentials/ListSinceByIP（CLI 改读文件后零调用）；
- 新增 LegacyCredentialColumns/PurgeLegacyCredentialColumns：AutoMigrate 不删
  既有列，老库升级后历史明文仍在 → 启动 WARN + `honeypot purge-creds` 显式 DROP；
- 清理器 HoneypotRetention 增加 CredPurgeable 参数，与 DB 记录共用保留期；
  honeypot prune 也一并删过期凭据文件；
- CLI：hits 不再连库（DB 挂了也能查），stats 的凭据排行读文件；
- 配置 honeypot_cred_dir（缺省 data/honeypot-creds），.gitignore 加 /data/。

验证：go build ./... / go vet ./internal/... / go test ./...（含 PostgreSQL）全绿；
新增 credstore_test（追加/倒序/IP 过滤/坏行/Top/Purge/权限）、
TestHoneypotLegacyCredentialColumns（ADD COLUMN 模拟老库 → 检测 → DROP）、
TestHoneypotWritesCredentialsToFile；CLI 端到端手动验证 hits/--ip/--show-password。
 2026-10-21 15:43:25 +08:00
tamakyi 566b13eedd fix(conf): 样例配置去掉行尾注释（会被并入值导致静默失效） 
conf.Init 用 ini.LoadOptions{IgnoreInlineComment: true}，该选项的语义是
**不剥离**行尾注释：`port = 1440 ; 注释` 解析出来的值是 "1440 ; 注释"，
int 解析失败，而 MapTo 仍然返回 nil error —— 配置项静默回退零值。

实测照抄 app.sample.ini 的后果：
- text_censor_source 的值带注释，被 validateTextCensorSource 拒绝，直接起不来；
- ip_blacklist / security_alert_email 变成带注释的垃圾字符串；
- honeypot_max_rows / honeypot_auto_clean 静默失效（后者靠 sanitize 兜底才没出事）。

改动：
- 17 处 `key = value ; 注释` 改成「注释独占一行 + 裸值」，保留 CRLF；
- 蜜罐段补 honeypot_cred_dir，以及「提交凭据才封禁」的语义说明；
- 新增 TestSampleIniValuesHaveNoInlineComment：遍历所有段的键，断言值不含 ';'
  （比逐字段断言彻底，新增配置项自动纳入）。
  变异验证：给 ban_window_seconds 加回行尾注释，测试按预期失败；
- keynorm_test 补 HoneypotBanMinutes 的缺省值断言（缺省 1440 / 显式 0 交给 autoban 回退）。
 2026-10-21 15:43:13 +08:00
tamakyi d300167a30 fix(conf): 配置键名容错 + 未知键告警 + 蜜罐保留期缺省值修正 
现场故障：配置写 `honeypot_retention_days <= 30`，日志却报
「蜜罐自动清理未启用：honeypot_retention_days <= 0」。

根因（实测 ini v1.67.0 行为确认）：
1. 键名多一个 t（retention vs retain）→ ini 对未知键**静默忽略**，保留期成 0；
2. `<= 30` 这种写法让 ini 把键名解析成 "honeypot_retention_days <"
   （带尾随比较符），更加匹配不上；
3. 警告文案里写的也是错键名，等于在误导运维往错的键上配。

修复（三层）：
- 键名归一化（internal/conf/keynorm.go）：修剪首尾空白、剥掉尾随 `<` `>`
  `=` 等比较符残留，并按别名表纠正常见误拼。归一化结果必须命中该段
  合法键名白名单才会被采用 —— 不认识的键不猜，交给未知键告警。
- 未知键告警（internal/conf/unknown.go）：启动时逐段比对键名，无法识别的
  键 WARN 出来并给出最接近的合法键名建议。合法键名由反射从结构体 ini tag
  得出（单一事实来源，新增配置项自动纳入，不会脱节）。
- 缺省值语义修正（internal/conf/honeypot_defaults.go）：
  * 保留期缺省 30 天（原先零值 0 = 永不清理）；显式 <= 0 也回退 30。
    要关闭自动清理请用 honeypot_auto_clean = false。
  * honeypot_auto_clean 缺省 true。原先靠 bool 零值，ini 的 bool 解析是
    「有键才赋值」，未配置与显式关闭无法区分 → 老配置升级上来自动清理
    实际是关着的。现改用 HasKey 判定。
  * honeypot_max_rows 缺省 200000；显式 0 = 不限（会告警提醒只增不减）。
  * honeypot_threshold 缺省 1。

实测 ini 行为（探针程序，已删）：
- 键缺失或值非法时 MapTo **不覆盖**预置默认值 → 可安全预置缺省值；
- 键名大小写敏感（Honeypot_Auto_Clean 不生效）；
- HasKey 能区分「缺失」与「显式 0」；
- 段不存在时 MapTo 返回 nil 且不修改目标。

顺带清理 app.sample.ini 里的两条死配置（app.title / server.xsrf_expire）：
代码中从未读取（站点标题走 i18n），留着会让新检测对官方模板误报。

验证：
- 用现场原始配置端到端复现 → 归一化后保留期 30 天、自动清理开启、上限 20 万，
  日志明确说明「配置键名已自动纠正」；
- 误拼键（honeypot_autoclean / honeypot_max_row）自动纠正；未知键（totally_bogus）
  WARN 告警；
- 显式 honeypot_auto_clean = false 被尊重为关闭；完全未配置时缺省开启；
- 新增 TestSampleIniHasNoUnknownKeys 回归检测：官方样例配置零误报；
- go build ./... + go test -timeout 600s ./... 全绿，go vet 无输出。
 2026-10-21 13:41:19 +08:00