tamakyi/tamabox
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
164 Commits 1 Branch 0 Tags
5def41d0f8601a5c475e6bf01709cdba605887ad
Commit Graph
28 Commits
Author SHA1 Message Date
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 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 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 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 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 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 7225f680d4 docs(memory): 记录蜜罐家族伪装的实现取舍与预览工具的用途 2026-10-23 12:38:43 +08:00
tamakyi 29ddee07db docs(memory): 记录封禁键/取证地址分离的根因、测试与变异验证经验 2026-10-23 10:53:13 +08:00
tamakyi d5398f9c2f docs(memory): 单题卡二维码 5px 与不落盘的决定 2026-10-23 00:27:27 +08:00
tamakyi d0a1bb8435 docs(memory): 分享卡模块像素实验矩阵与 2x 成本基准 2026-10-22 23:37:04 +08:00
tamakyi 9fb003cc39 docs(memory): 分享卡复验结论（着墨偏差实测、二维码静默区回归、4px/模块上限） 2026-10-22 23:24:32 +08:00
tamakyi a215c2ba2b docs(memory): dev 分享卡 500 的根因（字体从未入库）与二维码模块对齐 2026-10-22 22:33:53 +08:00
tamakyi 8fcb23f7b1 记忆：生成器顶栏面板 2026-10-22 16:16:05 +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 12c4f3e1be 生成器可检测与管理远端主题素材（列表 / 差异 / 覆盖 / 删除） 
「传上去」之后还得知道「传得对不对」：同一 slug 传过三次、换过 slug 旧图还在、
重新导出后远端仍是旧版，这些在页面上都看不出来。

- serve.py：s3_request 支持 query；新增 ListObjectsV2（含分页）与 DeleteObject，
  端点 /api/s3/list、/api/s3/delete。
- index.html：远端素材清单按对象键名跟本地比 —— 一致 / 旧图（同名但大小不同）/
  多余（当前主题已不引用）/ 缺失。「补齐差异」只传缺的与旧图，「删除多余」批量删，
  单行可 ↻ 覆盖或 ✕ 删除；删除走 confirm 二次确认。改过 slug 会提示重新检测。
- 修：list 返回完整键而 upload/delete 收相对键，不剥前缀会删到不存在的键
  （S3 回 204，看起来删成功其实没删）。加 relKey() 统一。
- check_sigv4.py 补带 query 的用例（ListObjectsV2 三参数、乱序 token）→ 8/8；
  selftest_upload.py 补列表/分页/幂等删除 → 20 项全过。
 2026-10-21 21:29:35 +08:00
tamakyi 6c21184733 主题生成器支持素材前缀（主题素材可放 R2/OSS） 
主题素材只有一处引用：主题 css 的 url()（分享卡是 Go 用 imaging 画的，不读素材），
所以只要让 CSS 里的地址指向对象存储即可。

- 导出面板新增「素材前缀」：空 = /static/images/themes/<slug>/（图片随二进制发布，与以前一致）；
  填 https://cdn.example.com/themes = CSS 写绝对 URL，zip 里的图片改为「上传用」
- 地址统一由 urlOf() 决定。修了一个重复实现：layerCSS 里复制过一份路径拼接，
  只改 urlOf 会出现「背景走 CDN、装饰还指本地」
- 前缀随意切换不影响预览（预览恒用内联 dataURL）；存进工程 json；?assetbase= 可自检
- INSTALL 文案按是否托管分叉，写清图片传到哪、换域名要重新导出
- 新增 docs/theme-assets-cdn.md：三种做法（生成器前缀 / 应用内 301 / 边缘改写）、
  缓存与 ?v=、CORS 不需要、深色无素材、迁移用的 sed 命令
- README 更新；UI 修正：240px 面板里 4 字标签会被 flex 压窄，需 flex:0 0 auto + 84px
 2026-10-21 19:32:55 +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 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 dc90d96bde 删除生成参考图 shiroko-cutout.png，文档改为「参考图不入库」 
- docs/theme-shiroko.md 三处引用不再指向具体文件（它只是 image-to-image 的 image1，从不进 embed）
- 顺手修过时说明：--tb-deco 是 10 个槽位，不是 6 个
 2026-10-21 18:24:16 +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 bfdc5089c5 docs(memory): 记录 ini 键名静默失效的根因与配置约定 2026-10-21 13:41:49 +08:00
tamakyi cbb0c51a14 docs(memory): 记录蜜罐表体积实测数据与 PostgreSQL 死元组/VACUUM 语义 2026-10-21 13:17:06 +08:00
tamakyi 7d52155411 fix(honeypot): 蜜罐封禁与 enable_auto_ban 解耦 + 泄露扫描后缀匹配 
- autoban: 新增 RecordHoneypot 独立通道（不受 enabled 约束）+ 独立阈值/时长；
  IsBanned 不再因 enable_auto_ban=false 而忽略已有封禁
- honeypot: 新增 honeypotSuffixes 后缀匹配，覆盖 /backup.zip、/db.sql、/id_rsa.pem
- 新增配置 honeypot_threshold / honeypot_ban_minutes
- 补测试：autoban/honeypot_test.go、route 侧禁用自动封禁仍封禁
 2026-10-21 12:36:33 +08:00
tamakyi 79051acae8 miguan v1 2026-10-21 12:09:28 +08:00