b0b40aabfc
- xpcool.com 与 admin.xpcool.com 备案号更正为 黔ICP备2026003933号， 两处生效点与 DEPLOY/日志同步记录； - MEMORY.md 索引补一行「站点备案号」常驻信息，便于下次改号时一次找齐； - 遗留：home / tool 两个子站目前完全没有展示备案号，待用户决定是否补。
22 lines
9.7 KiB
Markdown
22 lines
9.7 KiB
Markdown
# 2026-09-14
|
||
|
||
2026-09-14 | REQ | **xpcool.com 方向重定：删掉刚上线的「GPU 实时生成的宇宙」，改为「随机壁纸站」**。用户七项要求：每次进入随机壁纸 / PC 横版手机竖版 / 可下载 / 可刷新 / 页脚显示备案号 / 中英日韩四语言 / 日夜主题切换，另要求 AI 补全未考虑项（已补：收藏与最近看过、分享链接带种子、分享卡片 og.png、快捷键、对比度自适应遮罩、导出多分辨率多维度的「按目标尺寸重绘」）
|
||
2026-09-14 | CHG | web 端架构：**壁纸由浏览器 Canvas 2D 实时算出，零素材请求**。选它的三个理由：①服务器 5M 带宽且同时承载 home/tool/file/git/service 多站，传图片必卡 ②素材版权风险 ③随机性放客户端才能每次进入都不同且不产生请求。产物 gzip 后约 60KB（宇宙方案约 170KB）
|
||
2026-09-14 | FIX | **根治「画面和泥」**：两种种子画出来都是一片发灰的米白。根因①色斑用 `lighter` 叠加，重叠处被加成白色；②配色板是「从 6 个无关色相随机取」，必然互相抵消。改法：**配色板重写为有序色阶 `ramp`（由近底色排到对比最强），风格一律按 0..1 比例取色**（新增 `sampleRamp`），五风格全部迁移；mesh 改回 `source-over`。改后五风格逐一截图确认：warm 渐变 / 粉色地层 / 暖色光带 / 冷色星图 / 蓝色丝理，全部成立
|
||
2026-09-14 | FIX | strata 层交叉会打乱色阶顺序（各层原用独立噪声，fbm 值域 0..1 只会整体上移，交叉条件是 `振幅 > 层间距`，而旧振幅 0.17 倍画高 > 层间距 0.10~0.15 倍画高）。**改为所有层共用同一条波形、只做上下平移**，振幅再大也不交叉，另叠每层独有的小碎边
|
||
2026-09-14 | FIX | 浅色主题遮罩浓度过高把深色壁纸上下糊白：目标合成亮度原取 0.72 ≈ WCAG 13:1（AAA 只需 7:1），属过度设计。**放宽到 0.52**（主文字仍约 9:1），并提高 `--ink-faint/--ink-soft` 补偿页脚。**用像素采样验证**（Node 内置 zlib 手写最小 PNG 解码器读截图像素列）：strata 底部亮度 180 → 127，色阶完整呈现
|
||
2026-09-14 | FIX | 修两处真 bug：①`App.vue` 快捷键守卫 `target?.closest(...)`——从 `document` 派发的按键事件 target 不是元素，抛 `closest is not a function`（CDP 控制台抓到两次）②`scripts/shoot.mjs` 的 `goto` 漏了 seed 形参，五张风格截图全落同一默认种子、看起来「五种风格长得一样」
|
||
2026-09-14 | DOC | 验收脚本升级：真 390px 视口（CDP `Emulation.setDeviceMetricsOverride`）+ **五风格全扫** + `SHOOT_OG=1` 产出 `public/og.png`；另写离线反查脚本复刻 `hashSeed`+`mulberry32` 抽取顺序，用来核对「某种子实际用的风格与配色」——顺带验证了「同一颗种子切主题时风格不变、只换配色」这条设计性质成立
|
||
2026-09-14 | DOC | 补齐 `E:\CentOS\deploy-xpcool\` 缺失的本地脚本：`pack-xpcool.ps1`（清旧产物→铺 dist→打 bundle，assets 带内容哈希必须先清目录）+ `deploy-xpcool.ps1`（上传→远程 deploy.sh→公网验证）；`deploy.sh` 头部一直引用的本地脚本此前从未落盘
|
||
2026-09-14 | DEP | xpcool.com 重新构建并部署上线（含 gzip 配置首次生效）；README、`public/og.png`、`index.html`（OG 标签 + 四语言运行时改写 lang/title/description）一并更新
|
||
2026-09-14 | FIX | **排查「Bark 告警推送没生效」—— 结论：服务端整条链路全部正常，问题不在这侧**。按三段定位法逐层验证：(1) 服务器告警脚本 `server-monitor.sh` cron 每 10 分钟正常执行，`/var/log/server-monitor.log` 通篇 `[OK]`，9-13 00:10 后无推送是因**去重逻辑生效且无新事件**（`/var/lib/server-monitor/` 状态文件持续更新，banned-ips 2 条已记录），不是故障；(2) 手动 POST 自检 `http://127.0.0.1:8081/<key>` 返回 `{"code":200,"message":"success"}`，公网入口 `https://service.xpcool.com/bark/<key>/` 也 200（nginx `/bark/` → `127.0.0.1:8081`，末尾斜杠剥离前缀，配置正确）；(3) 用临时监控（id=11，指向 `127.0.0.1:9`，`maxretries=0`）触发真实 DOWN，**Kuma 00:42:40 成功推送至 bark 且返回 200**，验证后自清理（监控恢复 9 个、关联 9 条）。bark 容器 `finab/bark-server` Up 10 天无 ERROR，`/data/bark/bark.db` 单设备 token 注册于 9-11 22:01。**待用户确认手机是否收到 00:41:30 与 00:42:40 两条测试推送** —— 服务端 200 仅代表已提交 APNs，不代表送达，若未收到则问题在 iOS 侧（通知权限/专注模式/device token 失效）
|
||
2026-09-14 | DOC | 发现 `uptime-kuma` 容器**未挂载 Bark 增强补丁**：`docker inspect` 只有 `/data/uptime-kuma -> /app/data` 一个挂载，且宿主机 `/data/uptime-kuma-patch/` 目录**不存在** —— 即 DEPLOY.md 里记的「补丁已备好待部署」实际从未落地（`deploy-bark-custom.ps1` 未成功执行）。容器 CreatedAt 为 9-13 16:56、19:27 重启过一次。补丁本身非故障项（不影响通知发送），但自定义图标/重要警告/角标这些增强效果目前不生效
|
||
2026-09-14 | DOC | 沉淀经验到 skill `uptime-kuma-sqlite-ops`：新增「告警不生效排查：先分三段」章节（① 有无事件触发 → ② 推送是否发出 → ③ 手机是否收到），新增两条 SSH 踩坑（回传 base64 的那条 ssh 不能夹带 `ls`/`echo`，否则 `base64 -d` 报 invalid input；`scp ... 2>&1 | grep -v 噪音 && ssh ...` 因 grep 无匹配返回 1 而短路），并新增可复用自检脚本 `scripts/kuma-bark-check.sh`（变量化容器名与通知 id，自带备份与自清理）
|
||
2026-09-14 | DEP | **Bark 通知增强补丁正式部署并端到端验证通过**（9-13 备好的补丁因沙箱拦截 SSH 一直未落地）。流程：逐个 scp 7 个文件（icon/down/up.png、bark.js、status.xpcool.com.conf、deploy-bark-custom.sh、kuma-bark-verify.sh）→ 远端执行部署脚本（备份 `docker inspect` 与 nginx conf → 素材落 `/data/www/bark-assets/` → 补丁落 `/data/uptime-kuma-patch/bark.js` 并做 `node --check` 语法门禁 → nginx reload → 重建容器带 `:ro` 挂载 → 校验 md5）。结果：补丁 md5 `98c586f988084b89e1b5452257442b08` 宿主机与容器内一致、挂载在（`RW=false`）、9 处定制标记；端到端验证（临时监控 id=12 触发真实 DOWN）时 Bark 日志收到完整定制参数 `icon=…/bark-assets/icon.png & level=critical & volume=5 & badge=auto & isArchive=1 & image=…/bark-assets/down.png`，对比部署前仅 `icon`(GitHub)+`group`+`sound` 三项；清理后监控恢复 9 个、关联 9 条、面板 302 正常。**部署包归档 `E:\CentOS\deploy-bark-custom\`（含 README）**
|
||
2026-09-14 | FIX | 修 `deploy-bark-custom.sh` 两处隐患：① 补丁语法检查失败原先只打印错误、仍继续重建容器 → 改为 `exit 1` 中止（语法错会让 Kuma 整个通知模块挂掉）；② 取图验证原先只看 HTTP 状态码，会被 Kuma SPA 的 `200 + index.html` 骗过（且 `nginx reload` 后旧 worker 仍在退出，请求会落到 `location /`）→ 改为 `sleep 3` + 校验 `content_type=image/png`。另 `sudo docker cp` 产生的 `/tmp/_bark_check.js` 属 root，`rm` 需加 `sudo`
|
||
2026-09-14 | FIX | **排查并优化 read.xpcool.com 访问慢 —— 根因不在服务器，在前端资源传输**。read 是 **Flutter Web** 应用，首屏需下载 `main.dart.js` 12.75MB + `canvaskit.wasm` 6.76MB 等合计 **20.6MB**，而应用侧（Solon）既未压缩也未设有效缓存（上游仅给 `Cache-Control: max-age=600`）。仅改宿主机 `/data/nginx/conf.d/read.xpcool.com.conf`（**未重启容器、零中断**）：① 开启 gzip（`gzip_types` 含 `application/wasm`、`comp_level 5`、**`gzip_proxied any` 必写**，否则 proxy_pass 的上游响应不压缩）；② 分级缓存（`/canvaskit/*` 30d、构建产物 7d、`/` 不缓存以保换版及时）；③ 静态资源 `proxy_hide_header Set-Cookie`（上游给每张 JS/WASM/图片都塞 `SOLONID`，静态资源不需要；**首页与 API 的 cookie 保持不变并已实测未误伤**）。公网实测首屏 **20.6MB → 6.04MB（省 71%）**，服务端 TTFB 15ms。**排除项（均非瓶颈）**：应用内部响应仅 0.9ms、数据库 3.2MB/16 表、出口网络正常、负载 0.06
|
||
2026-09-14 | DOC | **拦下一次误改**：`conf.yml` 的 `server.http.coreThreads: x5` / `maxThreads: x10` 初判为「无效数值」，查证 Solon 官方文档后确认 **`xN` 是合法语法 = CPU 内核倍数**，jstack 实测正好 20 个 `smarthttp-` 线程（4 核×5）证明确实生效，遂未动手。教训：**框架配置里的可疑值先查文档，别凭直觉改**
|
||
2026-09-14 | CFG | 服务器补 **2GB swap**（原 swap=0，3.6G 内存跑 12 个容器是 OOM 隐患）：`/swapfile` 已 swapon 并写入 `/etc/fstab`；`vm.swappiness` 60→10 并写入 `/etc/sysctl.conf`
|
||
2026-09-14 | DOC | read 提速部署包归档 `E:\CentOS\deploy-read\`（nginx 配置 + README，含完整实测表、三个坑、回滚命令与可选优化清单）
|
||
2026-09-14 | CFG | **用户给出正式备案号：`黔ICP备2026003933号`**（此前站点挂的 `闽ICP备19024351号` 为旧值）。xpcool.com 改 `src/config.ts` 的 `SITE.icp`（合规信息集中一处）→ 重建 → 重新部署上线，线上 JS 核对新号在、旧号零残留，页脚桌面/移动端均无溢出；admin.xpcool.com 同域名需同步，改 `packages/preferences/src/index.ts` 的 `appCopyrightPreferences`（真正生效处）+ `@core` 框架默认值 + snapshot 三处，push 后由 Gitea Actions 自动部署。**遗留**：home.xpcool.com 与 tool.xpcool.com 两个子站目前**完全没有展示备案号**，已告知用户待其决定是否补
|