|
|
ef08ebb7d3
|
chore(mascot): 立绘 v2 —— 真 alpha 素材 + 头部裁切头像 + 素材判据
老大给的 4 张新立绘里有 3 张是「棋盘格假透明」JPEG（像素是灰白格子，
不是 alpha）。直接进仓库会在深色面板上露出格子，所以先抠成真 alpha 再落盘。
## 为什么主图与头像要分两个文件
现役 mascot.webp 唯一的消费点是**聊天消息的 30px 圆形头像**
（dashboard.js 4 处 aiAvatar + GUI app.js 2 处），概览页并没有放立绘。
主图是坐姿全身，按现有 CSS（object-fit:cover + scale(1.5)）裁成圆后
只剩裙子、看不到脸 —— 只换图不做头像版，等于把头像换成一张看不懂的图。
- assets/branding/mascot-xiaozhai.webp 1024² 主立绘（官方展示）
- assets/branding/mascot-xiaozhai-avatar.webp 512² 头部方裁（运行期源）
- internal/plugins/webui/mascot.webp 256² 头像版（原 133KB→24KB）
- cmd/gui/renderer/mascot.webp 128² 头像版（原 133KB→9KB）
参考稿另存三张（不参与运行）：sheet（设定总图）/ portrait（半身）/
turnaround（三视图）。
## 抠图怎么做的（可复现，不是手搓）
背景是 20.45px 周期的棋盘格（237/254 两色）。判据取「中性灰 且 灰度≥228」
的像素做候选，再从图像边界做连通域传播 —— 这样白裙子/白围裙因为不中性
（带蓝调）不会被误判，避免了当年 site/README 记录的 flood-fill 渗色问题。
边界再内缩 1px 抹白边，0.7px 高斯羽化去锯齿。抠完透明占比 55.8%，
深/浅两种背景上目检均无残留格子与白边。
## CSS：scale(1.5) → 1.25
原来的 1.5 是为「全身图裁圆」补的放大。换成头部方裁后，1.5 会切掉两侧
发绳与呆毛 —— 按真实 30px 渲染放大对照看过 1.0/1.15/1.25/1.4 四档。
## 新增判据（含反向验证）
internal/plugins/webui/mascot_asset_test.go 直接读 WebP 容器头，
断言 VP8X 的 Alpha 标志位与 ALPH chunk **同时存在**，外加正方形/≥128px/
≤128KB。理由：这类退化在肉眼 review 里抓不住（缩到 30px 就是一团浅色），
而用户每天都在看；且 site/README.md 记着当年正因为「白底图没法抠」
干脆不放立绘，这个坑值得一个自动化判据。
反向验证（已实跑，非声称）：把素材换成 HEAD 旧图，判据报红并准确指出
「Alpha 标志位未置位 / 缺 ALPH chunk / 体积超限」；换回新图转绿。
另有一条独立用例构造「带 VP8X 但不置 Alpha 位」的最小容器，
确认解析器不会对退化素材误判为绿。
## 顺带修的两处
1. assets/docs/{zh,en}/PLUGIN_DEV.md 的 mascot 引用路径是坏的：
`../../assets/branding/...` 从 assets/docs/zh/ 出发解析成
`assets/assets/branding/...`，文件不存在（旧版一直是坏的）。
已改为 `../../branding/...` 并逐条验证路径可解析。
同时指向新的头像版（那处是 20px 圆形内联小图标）。
2. gzip.go / gzip_test.go 注释里的「mascot.webp（133KB）」改为不带死数字
的说法 —— 体积会随素材变，注释写死数字只会变成误导。
## 验证
go build ./... → 0
go vet ./internal/plugins/webui/ ./cmd/gui/ → 干净
gofmt -l → 空
go test ./internal/plugins/webui/ -count=1 → ok（15.1s，含新增 2 个用例）
## 没做的事
- 没碰 main、没开 PR、没部署、没重启服务。
- **概览页仍未放立绘**。site/README 里「素材不可用」这条已不成立（素材有
alpha 了），但版面是否该放图属于设计取舍，不在本次范围 —— 文档已相应改写，
不再用「素材不行」当理由。
- 抠图对发丝边缘是「够用」不是「完美」：0.7px 羽化在 1024 下看不出来，
但若将来要印物料级大图，需要重出带原生 alpha 的源图。
|
2026-10-18 07:38:10 +08:00 |
|
|
|
e57adb5978
|
perf(webui): 服务端 gzip —— 首屏 wire 字节 -70%
生产实测：首屏 API 合计 792,933 B，而服务端此前**完全没有** Content-Encoding
（直连 127.0.0.1:8080 与经 nginx 的公网入口两条路径都验过：响应头里没有
该字段，wire 尺寸 == 原始尺寸）。同一份数据 gzip 后：
/api/v1/kernel 152,667 → 37,697 (-75%)
/api/v1/chat/history?limit=40 554,764 → 174,594 (-69%)
这些是高度重复的 JSON（同批 key 名反复出现、中文实体名、时间戳），
压缩比自然地高。真实实例上实测首屏 wire 字节 77,943 → 23,339（-70%）。
位置：链改为 proxyDispatch → gzip → logged → mux。夹在 proxyDispatch
与 logged 之间，是因为 proxyDispatch 命中时直接 return、响应来自上游
（其 Content-Encoding 由 httputil 处理），我们不插手；门户自身的全部
响应（requireAPI 的 401/503、requireWeb 的 302、HTML/CSS/JS、全部
JSON API）都压。
### 三个必须显式处理的坑
1. **SSE 不能压。** text/event-stream 进 gzip 缓冲后 flush 语义就废了
（前端收不到流式，要等缓冲攒够）。对 SSE 请求直接透传。
2. **必须透传 http.Flusher。** handleChatEvents / streamOpenAI 里是
`w.(http.Flusher)` 类型断言；包装 ResponseWriter 会让断言失败 ⇒
flusher 为 nil ⇒ 走降级分支 ⇒ SSE **静默**坏掉（不报错，只是收不到
流式）。这不是「顺手加一下」能过的改动，有专门的判据守着。
3. **204/304/HEAD 没有 body**，压它们只浪费 CPU 并加坏头。
另外 webp/png/zip/gzip 等已压缩类型也跳过（mascot.webp 133KB 就在内）。
### 小于 1KB 的响应不压
gzip 头 23 字节，几百字节的 JSON 压完反而更大。与 nginx 的
gzip_min_length 1000 对齐。实测 /api/v1/status（197B）不带
Content-Encoding。
### 状态机写成枚举而非多个 bool
第一版用 passthrough/decided/buffering/allowBuf 四个 bool 交叉表示，
结果出两个 bug：小响应内容被写成空、已压缩类型仍被压。根因是
「该不该压」在 Write / WriteHeader / 收尾三处各判一次且判据不一致。
改成单一 mode 枚举（undecided/passThrough/buffering/streaming）、
判据只在 WriteHeader 与 Write 各求值一次后，两个 bug 同时消失。
### ★ 一条判据我自己写错了，值得记下来
TestGzipDropsContentLength 初版断言「压缩响应不应带 Content-Length」，
实测失败。追查后证明**判据错了、代码是对的**：
Go 在 Del("Content-Length") 之后，若响应体小到能被一次性缓冲（<2048B），
net/http 会**自动重算**并补上压缩后的真实长度（实测 14000B → 119B →
响应头 Content-Length: 119，正确）。真正要防的是**陈旧长度**：留着
14000 而实发 119 时，客户端按 Content-Length 读满会先拿到 119 字节再吃
unexpected EOF（已用对照探针实测复现）。判据改成两条：①声明长度 ==
实际读到字节数 ②该值 == 压缩后长度而非压缩前长度。另加一条对照判据
TestGzipStaleContentLengthWouldBreak，把危害钉成可执行断言。
### 验证（不是「应该能跑」）
- go vet 干净；全量测试通过；新增 12 条 gzip 判据；覆盖率 66.5% → 67.0%
- 真实实例（独立数据目录 + 18081 端口）实测：
· SSE：无 Content-Encoding，2 次独立 TCP 读（逐帧下发，未被缓冲）
· /api/v1/status（197B）：不带 Content-Encoding
· /api/v1/kernel -69%、/api/v1/settings -73%、/api/v1/plugins -63%
· 首屏 wire 字节 77,943 → 23,339（-70%）
· 内容完整性：gzip 解压后与明文逐字段相等（plugins/tools/build/
channels 名称集合与顺序均一致）
- ★ 途中被一个「MISMATCH」误导过一轮：/api/v1/kernel 两次请求字节不同。
追查发现是 IOManager.ListChannels 遍历 **map**（Go 每次迭代随机化），
**在本次改动之前就已不确定**，与 gzip 无关。差点被我误报成压缩 bug。
附：dashboard.js 被自动格式化器整体重排（6783 增 / 6293 删，纯空白与
引号风格）。已用 prettier 归一化后逐字节比对确认**零语义差异**。
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
2026-09-27 00:02:28 +08:00 |
|
