From c19e475e856297c469fbdf10dd073aefa1fa49a8 Mon Sep 17 00:00:00 2001 From: Yongquan Date: Sun, 1 Nov 2026 15:26:08 +0800 Subject: [PATCH] =?UTF-8?q?=E4=BF=AE=E5=A4=8D=EF=BC=9A=E9=99=84=E4=BB=B6?= =?UTF-8?q?=E6=80=BB=E9=87=8F=E4=B8=8A=E9=99=90=E5=A1=AB=2010240=20?= =?UTF-8?q?=E8=A2=AB=E6=B5=8F=E8=A7=88=E5=99=A8=E6=8B=A6=E4=BD=8F=EF=BC=88?= =?UTF-8?q?step=20=E4=B8=8E=20min=20=E5=86=B2=E7=AA=81=EF=BC=89=20(#1)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 用户反馈「全站附件总量上限填 10240 不行」。 根因：input 写成 step="16" min="10"。 HTML 的 step 是从 min 起算的 —— 合法值只有 10、26、42、58…（10 + 16n）。 10240 不在这个序列里，浏览器直接判为非法值、拒绝提交。 更糟的是这不是个例：1024（1G）、2048、4096、8192 全都不合法， 只有 10/26/42 这种怪数字能填进去。这个 bug 从该字段上线就存在。 修法： - step="16" → step="any"，允许任意数值 - 补 max="100000"，与服务端 [10, 100000] 区间对齐， 避免用户填 999999 被服务端静默截断成 100000 顺带排查另外两个容量字段，确认没事： - 图片单张上限 min=0.2 step=0.1 → 0.2 起步正好对齐，0.5/1/5/10 都合法 - 视频单个上限 min=1 step=1 → 整数都对 只有总量那一个字段踩了坑。 新增 tools 级检查脚本（_tooling 侧 fb_input_constraint_check.py）： 按 HTML 规范逐条验算每个 number 输入框的 min/max/step 是否放行 「默认值」与「常见取值」，并核对前后端区间是否一致。19/19 通过。 这类错误肉眼看不出来，必须用规则算。 验证：约束一致性检查 19/19；服务端 MB↔字节往返一致（含 10240）。 --- admin.php | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/admin.php b/admin.php index 0846083..4bd206e 100644 --- a/admin.php +++ b/admin.php @@ -675,7 +675,7 @@ fb_layout_head('管理后台', ['robots' => 'noindex,nofollow']); +