tamakyi/tamabox
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
188 Commits 1 Branch 0 Tags
main
Commit Graph
39 Commits
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 937e688cfa 可靠性: 完善 R2 备份恢复与对象生命周期 2026-11-05 08:41:55 +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 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 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 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 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 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 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 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 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
tamakyi 72f08cd7c9 perf(share): 用「同画布放大二维码」替代 2x 渲染，模块 4px → 5px 
960×540 的卡被聊天软件缩到 480 宽时，二维码每模块只剩 2px，解码器读不出。
2x 渲染能解决，但实测成本不低（见下），先用零代价的办法把模块做大。

实测矩阵（go-qrcode 纠错 Q / 真实 55 字符链接 / 37 模块，含内嵌头像）：
  尺寸 148px = 4.0px/模块 -> 960 o 720 o 480 x 320 x
  尺寸 190px = 5.0px/模块 -> 960 o 720 o 480 o 320 o 240 x
纠错降到 M（33 模块）只省 11% 模块数，容错却从 25% 掉到 15%，不划算；
PNG 只能保住原图，缩到 480 一样解不出，体积还是 JPEG 的 5 倍。

- QRCodeSize 165 → 190（37 模块取整为 5px/模块；生产短域名 33 模块为 165px）
- QRCardH 315 → 335 容纳变高的二维码，卡片整体仍垂直居中
- 新增 TestGenerateQRModuleSizeAtLeast5：三种常见链接长度下模块必须 ≥5px，
  把 QRCodeSize 改回 165 立刻 FAIL

渲染成本基准（1x vs 2x）：JPEG 编码 12 → 48ms、背景 Lanczos 缩放 25 → 41ms、
画布分配 3 → 13ms，二维码生成本身 0.8ms —— 2x 的代价主要在编码与缩放，
与二维码尺寸无关，所以放大二维码不增加任何 CPU。
 2026-10-22 23:36:02 +08:00
tamakyi b35c2a8f45 fix(share): 二维码不再被静默区吃掉三分之一尺寸；卡内间距收到 4px 栅格 
上一版改成按模块整数倍出图时，静默区仍然画在图像里：49 个模块（41 + 4×2）
挤进 165px 只剩 3px/模块、符号 111px，比改造前的 135px 还小 —— 这是自己引入的
回归。测试卡上验证时才发现：二维码在 960 宽的卡里只占 111px，微信/QQ 二次
压缩到 480 宽后模块不足 1.5px，gozxing 直接解不出来。

- generateQR 改 qr.DisableBorder：图像只输出符号，静默区交给承载它的白色卡片
  （四周留白 30px 以上，远超 4 模块）。符号尺寸按 size/modules 取整，最多
  浪费一个模块宽度
- 调用方按实际符号尺寸居中与排版，不再假设等于目标尺寸
- 单题卡 QQRSize 128 → 150：37 模块的题目链接因此拿到 4px/模块（原 3px）
- 卡内垂直间距 26/21/21/15 → 24/20/20/16，落在 4px 栅格上

验证：profile 卡二维码 111px → 148px（37 模块 × 4px，用满 90%），单题卡
111px → 148px；gozxing 解码 960 原图、75% 缩放图均能读出正确 URL（含内嵌
头像）。守门测试加了两条：符号宽度必须等于 modules×perModule 且吃掉目标尺寸
≥80%（变异成「含静默区」立刻 FAIL），头像测试改判四角必须是定位图案而非
白色（防止符号被裁切）。
 2026-10-22 23:22:34 +08:00
tamakyi d51629ef2f fix(share): 字体缺失不再永久失败；二维码按模块整数倍绘制 
测试环境部署后分享卡整站 500「字体文件未配置或无法加载」。根因不是代码
回退，而是字体从来就不在仓库里：static/fonts/ 既没有入库（git 历史为空），
也没有 embed，凡是按仓库新建的环境都缺这个文件，只有手工补过字体的老环境
才正常。

- getFont 不再用 sync.Once 永久缓存失败：补上字体文件即生效，无需重启；
  失败时错误信息带上「已尝试的路径」，排障不用再猜是配置还是文件
- 候选路径：font_path → static/fonts/*.{otf,ttf,ttc} → 常见系统 CJK 字体，
  换过字体文件名也能用
- app.sample.ini 注明字体必须自备、缺失的后果

顺带做 P1 的第一项：generateQR 改为按模块整数倍出图（41 模块 @165px →
每模块 4px、符号 164px 居中）。原先是 256px 生成后最近邻缩到 165px，
每模块 4.02px，模块宽窄相差 1px，小尺寸二次压缩后更容易扫不动。
内嵌头像改为按目标尺寸等比（size*48/256）+ 2px 白边，静默区不受影响。

守门测试新增两条：TestGenerateQRIsModuleAligned（扫描线游程必须是模块
宽度的整数倍，变异成等比缩放后立刻 FAIL）、TestGenerateQRWithLogo
（中心是头像、四角静默区纯白）。
 2026-10-22 22:33:22 +08:00
tamakyi 0054e508b7 fix(share): 分享卡链接按真实字宽居中，长链接按 host/path 收敛 
原实现用字符宽度系数估算文本宽度，把标点/符号一律按 1em 计，
而 URL 里的 : / . _ - 实际只有 0.25~0.35em，整句高估 55%：
15px 的 box.shiroko.one/_/tamakyi 估算 352.5px、真实 227.9px，
越过卡片可用宽 230px 后触发等比缩字号，最终只画到 9.6px 且左偏 40px；
链接越长字号越小（长域名实测 5.3px），整段挤在卡片左侧。

- measureTextWidth 改为逐字累加 HMetric.AdvanceWidth + Kern，
  scale = fontSize*64 与 freetype 在 72 DPI 下的换算一致，测量结果与
  DrawString 返回笔位逐位相等；字体不可用时回退估算
- drawTextCentered 随之修正，底部水印原本偏 9.8px 一并归位
- 新增 displayURL（去协议前缀）/ layoutLink / ellipsizeMiddle：
  单行 15→13px；放不下按 host/path 拆两行 13→11px；host 超宽才中间省略；
  字号下限 11px，行长恒定不超过 QRCardW-40
- 卡片内容高度按链接行数计算，两行时整体重新居中

守门测试见 route/question/share_layout_test.go（测量=笔位、限宽、按着墨
边界判定居中 ±3px、TEST_PREVIEW=1 出图）。
 2026-10-22 21:42:50 +08:00
tamakyi 0181fc5c66 fix templates v3 2026-10-22 18:26:30 +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 3202ef9821 theme v2 2026-10-19 16:16:07 +08:00
tamakyi e9fba8b9ed theme v1 2026-10-19 15:23:11 +08:00
tamakyi 12a37e726f fix v14 2026-10-19 02:25:19 +08:00
tamakyi 4592b6ef24 fix v13 2026-10-19 01:58:00 +08:00
tamakyi bd613a6f5a fix v12 2026-10-19 01:11:28 +08:00
tamakyi 7a6417c33d restrict v8 2026-10-18 23:32:38 +08:00
tamakyi 317c96ca17 restrict v7 2026-10-18 23:04:50 +08:00
tamakyi bd81398a06 restrict v6 2026-10-18 22:18:21 +08:00
tamakyi d14d26df17 restrict v5 2026-10-18 21:59:12 +08:00
tamakyi 52f0712eda restrict v4 2026-10-18 21:50:58 +08:00
tamakyi efb19606a7 restrict v3 2026-10-18 21:36:03 +08:00
tamakyi 6bd90779f8 restrict v1 2026-10-18 21:14:59 +08:00
tamakyi da7e76a7db webp fix v2 2026-10-16 09:39:30 +08:00
tamakyi e4457e3da4 webp fix v1 2026-10-15 11:41:19 +08:00
tamakyi adcc42cc8c fix anwser token and database issus 2026-09-15 11:06:09 +08:00
tamakyi 8e2325eda5 aliyun sensor server 2026-09-10 18:04:19 +08:00
tamakyi e3e59e7c69 chore: baseline snapshot before moderation-strictness feature 
Repo .git was damaged (refs/ missing, index truncated, object store near-empty).
Repaired via git init (rebuilt refs), stale index preserved as .git/index.corrupt-20260910.bak,
then full worktree committed as a rollback baseline.
 2026-09-10 10:56:27 +08:00