HY
折腾进行时
Hello, I'm HY.
博客日志 · 第 5 页
BLOG CHANGELOG/PUBLIC RECORD
博客日志
这里记录这个博客从上线、写作到页面迭代的每一个重要节点，每一次都按真实改动整理，展开即可查看完整变更说明。
版本规则：Major 代表结构级升级 · Minor 代表新功能 · Patch 代表修复、内容与维护
V1.50当前版本52个更新日255条详细记录26.09—26.10时间跨度
- 第 12 次记录
桌面并成一排、手机收成一行 4 张，贴纸改成按需加载
展开这条记录
背景
V1.9 那版是「桌面两层、手机随机露 8 张」，这次两件事都推翻了：两排错位看久了不如一排整齐，手机端 8 张分两行也不如 4 张铺一行。顺带撤掉便签、加进第一张会动的贴纸，最后发现一件蠢事——手机端只显示 4 张，实际却把 11 张全下载了，因为随机抽签是在图片请求发出去之后才切的 display。改成按需加载后，手机端首屏的贴纸流量从 149 KB 掉到 47 KB
01首页 · 具体变更
桌面贴纸从两层并成一层：11 张全部 bottom: 5 铺成一行，脚踩同一条地面线。left 改成按「视觉中心等距」计算——各张基准宽度不同、图片在盒子里居中，按 left 等距排会让视觉中心最多漂 ±11px（1920 宽）
03首页 · 具体变更
新增第一张动图贴纸「夏娜·甩发」：6 帧 300ms 一轮的动画 webp，GIF 转出来的（帧按并集 bbox 统一裁剪，缩放走预乘 alpha 防止红头发外圈挂黑边）
05性能 · 具体变更
贴纸图片改成按需加载：服务端只输出 data-home-wallpaper-src 不发请求，脚本在手机端只给随机抽中的那 4 张赋 src、桌面端等 window.load 之后再统一赋值。实测手机端从 12 个请求 / 149 KB 降到 5 个请求 / 47 KB；桌面端字节不变，但全部移出 LCP 关键路径
07素材 · 具体变更
新增相册「夏娜表情」共 9 张：发怒、叹气、大哭、慌乱、懵圈、挥手、星星眼、脸红、蜜瓜包，原图画稿不压缩存档
02首页 · 具体变更
手机端从 2×4 两行改成一行 4 张：mobileStickerLimit 由 8 改成 4。这个数直接决定行数——每行张数 = floor(97.6 / (尺寸/屏宽×100 + 1.6))，68px 时 390 宽能放 5 张、360 宽掉到 4 张，所以填 5 会在窄机型上翻回两行
04首页 · 具体变更
下架夏娜蜜瓜包与露易丝女仆两张贴纸，相册里的原始画稿保留；移除卡片上的「欢迎访问」便签（组件不再渲染该节点，而不是靠清空文字隐藏）
06性能 · 具体变更
新贴纸体积从 60.2 KB 压到 32.3 KB：alpha_quality 100→70（这张图的 alpha 几乎只有 0/255，有损压缩碰不到它）、quality 90→70，分辨率维持 202×192。质量曲线在 q50~q70 几乎是平的，说明字节是帧数据本身
08内容 · 具体变更
同步首页贴纸那篇实现记录（/posts/blog/homestickercard/）：新增「并成一排」「第一张动图贴纸」「改成延迟加载」三个小节，配了两张成品图
- 第 11 次记录
贴纸扩到 12 张，桌面分两层、手机只随机露 8 张
展开这条记录
背景
贴纸是一张张攒起来的，问题也是攒出来的：手机上要全部显示就只能往上堆行，最后变成三排 50px 的小人墙，连卡片底部的社交按钮都快被压住；桌面端反过来——两排六个站得舒服，再加就顶到卡片了。这次撤掉两侧那 4 张旧贴纸换成新角色，并把排布改成自适应：桌面分前后两层、手机随机挑 8 张用 68px 的正常尺寸显示，刷新换一批
01首页 · 具体变更
贴纸从 7 张扩到 12 张：新增高坂桐乃 3 张（欢呼 / 躺平 / 抱臂）与夏娜系 6 张（蜜瓜包、跃斩、黑红双色持剑、露易丝女仆、粉发猫耳）
03首页 · 具体变更
手机端改为随机抽 8 张显示（homeCardConfig.mobileStickerLimit 可调，填 0 即全显示）：以前是「缩到 50px 也要全塞下」，现在是 68px 两行。抽签结果在同一次页面加载内保持不变，刷新才换一批
05素材 · 具体变更
白底原图用「亮度 + 低饱和度谓词 + 四角洪水填充」抠底：靠连通性保住角色内部的白衬衫，同时吃掉落地灰影；画笔感强、浅色部件直接贴背景的那 6 张，本地抠图会咬掉剑刃和衣领，改用云端前景提取后再本地收边
02首页 · 具体变更
桌面改双层排布：前排 6 张脚踩同一条地面线，后排 6 张错位插空；窗口高度不足 940px 时后排整排隐藏，避免顶到卡片底部的导航与社交按钮
04首页 · 具体变更
移除 4 张旧贴纸（金发偶像、洛琪希、祢豆子、初音未来），底排随之从 8 张步长 12.5% 改成 6 张步长 17.5%
06修复 · 具体变更
云端抠图会把日期和画师签名当成前景留下，用「只保留面积 ≥ 最大连通域 5% 的块」一次清掉；它在角色外留的半透明白描边则用 alpha 阈值掐掉
- 第 10 次记录
新增相册「首页贴纸原图」，全分辨率原稿可直接翻看
展开这条记录
背景
首页贴纸最多只显示 104px 高，但手上的源图是 2048px、还带着画师签名，此前只躺在本地文件夹里。项目自带相册能力，就把它们收进 public/gallery/stickers/：不转码、不缩放、不重编码，直接放原始 PNG。截图站上线前实测过——构建产物与源文件逐字节一致（md5 相同），因为相册页读的是 public 目录、用的是裸 <img>，压根不经过 Astro 图片管线。代价是这页滑到底会拉 18MB，我认了这个代价
01相册 · 具体变更
新增「首页贴纸原图」相册共 12 张：9 张 1440~2048px 的原始 PNG，加上 3 张早期素材（它们只有 192px 的版本，那就是现存最清晰的形态）
03维护 · 具体变更
重建 LQIP 占位表：补齐新相册与壁纸的条目，清掉已删除图片留下的失效条目
02相册 · 具体变更
相册索引与导航自动收录，无需改主题；封面手动指定为桐乃那张欢呼
- 第 9 次记录
壁纸池添了夏娜横竖各一张，三篇动画观后感补上题图
展开这条记录
背景
壁纸池一直是那几张老面孔，这次补了一组夏娜：横版进桌面池、竖版进移动池，原图一并归档进 git（壁纸的展示版会走构建管线重新编码，不存原图以后就没法重压）。顺手给三篇动画观后感补了标题卡题图——这三篇正文通篇没有配图，翻到最后有点干，加一张收个尾
01壁纸 · 具体变更
桌面壁纸池加入 1920×1005 横版夏娜、移动池加入 1080×1920 竖版，原图同时归档到对应 originals/ 目录；壁纸轮播会自动带上
03内容 · 具体变更
《我的妹妹哪有这么可爱！》《零之使魔》《灼眼的夏娜》三篇观后感末尾各补一张标题卡题图
02相册 · 具体变更
桌面壁纸、手机壁纸两个展示相册同步换图，顺带清掉已废弃的旧素材
04内容 · 具体变更
《零之使魔》的封面换成 2048×1152 源图，比原来那张 1672×941 更经得起高分屏放大
- 第 8 次记录
时间线不再被聚合站霸榜，按来源 3:4:3 交错
展开这条记录
背景
朋友圈上线后自己刷着发现不对劲：前排几乎全是博友圈那类聚合站。查下来随机池本身已经是 6:4，问题出在排序——聚合站更新频率是个人博客的几十倍，按时间倒序它天然霸榜（第一页 20 篇里 14 篇是社区）。给时间线加了一层来源配额，本站 3 成、Blog 4 成、社区 3 成，再按配比交错排列
01朋友圈 · 具体变更
新增来源配比配置：时间线按 本站 30% / Blog 40% / 博客社区 30% 分配展示名额，全部收在新的 src/config/momentsConfig.ts 里，只新增文件不碰主题源码
03朋友圈 · 具体变更
每个友链的取文上限从 6 篇提到 12 篇，并改为从配置读取：本站只有一个源，上限 6 篇时最多只能贡献 6 篇，而 40 篇里要占 3 成就得 12 篇，怎么配都凑不出来
05友链 · 具体变更
把博友圈、博客星球、八零圈、BlogsClub、中文独立博客聚合列表这 5 条的标签统一成「博客社区」，友链页筛选栏从 11 个 chip 收敛为 全部 / Blog / 博客社区 三个
07维护 · 具体变更
已知副作用：组内「取最新 N 篇」的策略下，几个月没更新的友链（夏夜流萤、霞の葉間）会掉出 40 篇名额，8 个来源实际只出现 6 个。想保证每个友链都露脸，需要把组内挑选改成按友链轮询
02朋友圈 · 具体变更
排序改为按配比交错：原本整体按发布时间倒序，配额只能约束总量、管不住顺序——社区组总共 12 篇，但博友圈那几篇时间最新，倒序一排还是全跑到最前面。改成每一步挑「当前实际落后目标比例最多」的那一组取下一篇，组内仍是新的在前，第一页 20 篇稳定在 8 Blog / 6 本站 / 6 社区
04朋友圈 · 具体变更
移除随机卡片里「20% 概率优先抽本站」的旧逻辑：来源配比已经在池子里分好组，再叠一层倾斜会把本站实际命中率压到 20%，跟配置里写的 3 成对不上
06修复 · 具体变更
补装漏装的 @fontsource-variable/noto-sans-sc：它在 package.json 里声明了，但 node_modules 下并不存在，OG 图片路由读取字体时抛 ENOENT，导致整个构建中断、dist 被削到只剩 21 页（连首页都没生成）
08内容 · 具体变更
发布文章《给朋友圈加了层来源配额：本站 3 成、Blog 4 成、社区 3 成》
- 第 7 次记录
首屏标题少等 0.3 秒，文字与图片彻底解耦
展开这条记录
背景
V1.45 把预取关掉之后，回头重新归因一次 LCP，结果发现之前判断错了——拖慢首屏的不是那张毛玻璃卡片、也不是壁纸，而是卡片里那行标题「折腾进行时」。它被入场动画设成全透明、还要等 0.36 秒才开始淡入，而浏览器不把全透明的元素算作「已经画出来」，于是最大元素的计时被硬生生推迟。更绕的是，这个 0.36 秒的起点还得先等卡片里的小图加载完。这次把这条链条拆成两段，文字归文字、图片归图片
01性能 · 具体变更
标题换上专属入场关键帧，起点直接 opacity: 1，只保留从下往上滑 12px 的位移。之前它借用的是通用内容关键帧，起点是全透明，而 Chrome 不会把 opacity: 0 的元素计入内容绘制，等于 LCP 被延迟到淡入之后才成立
03性能 · 具体变更
入场逻辑拆成两段：文字动画不再等卡片图片加载，两帧之后直接放行；图片单独走一条就绪通道，只控制自己的 0.24 秒淡入。之前图片没到，连标题的入场都要一起陪着等
05修复 · 具体变更
更正 V1.45 里对 LCP 元的判断：之前看帧截图误以为是壁纸，读了 trace 才确认最大元素是 h1 里的文字节点，并据此重写了归因结论
02性能 · 具体变更
标题延迟从 0.36 秒砍到 0.08 秒。视觉上依然是「滑上来」，但因为不透明，第一帧就已经算画好了，不再多花 0.36 秒等它出现
04维护 · 具体变更
图片隐藏加了一层保护：只有当 JS 确实接管、且入场已启动时才隐藏图片，脚本失效时会直接显示，不会永久空白一块；开启「减弱动态效果」时也直接显示
- 第 6 次记录
首屏少传 483KB，顺手修掉两个小毛病
展开这条记录
背景
接着 V1.4 的体检继续往下钻，这次换了个办法——把 Lighthouse 抓的逐帧截图导出来一张张看，首屏到底慢在哪立刻就清楚了：前 2.6 秒整屏是白的，然后卡片和贴纸一次性冒出来、背景还只是个色块，真正的壁纸要到 4.3 秒才到。顺着这条线查下去，发现最大的那笔流量根本不是图片——是 Swup 趁你还在看首页，就把导航里 7 个页面全提前下载好了
01性能 · 具体变更
关掉 Swup 视口预取：链接只要露出 20% 面积并停留 500ms 就会被提前下载，而首页第一屏正好有 7 个链接满足条件（卡片导航 5 个 + RSS / 打赏），一次抓回 483KB 的页面 HTML，占移动端总流量的 34%。改回 hover-only 之后，首屏少发起 14 个请求、少传 483KB，桌面端少 924KB～1042KB
03维护 · 具体变更
把首屏慢的原因彻底拆成两截：那张 89KB 的壁纸，请求直到 638ms 才发出——因为它藏在 <template> 标签里，浏览器解析 HTML 时根本看不到它，必须等内联脚本把它克隆进 DOM 才开始下载；而它下载时只抢到约 12% 的带宽（89KB 花了 3.67 秒），剩下的都被别的请求占着
05性能 · 具体变更
/images/ 和 /favicon/ 补上 30 天缓存头：这两类之前落在默认规则上，响应头是 max-age=0, must-revalidate，等于浏览器每次访问都要把它们重新校验一遍
07维护 · 具体变更
把整个 fork 的合并负担量化了一遍：664 个文件与上游不同、3.7 万行改动，并揪出 18 个「本地删了但上游还在」的文件——这些上游一更新就会报 modify/delete 冲突，以后合并时统一 git rm 处理，不用每次现想
02维护 · 具体变更
这次没有写 visible: false，而是直接把配置还原成上游那行 preload: true。两者运行时完全等价（跑库自己的 buildInitScript() 验证过，产出的插件参数一模一样），但这样这一行和上游字节一致，以后合并上游连 diff 都不会产生
04性能 · 具体变更
侧边栏头像改成懒加载，并去掉 fetchpriority=high：一个小头像被标成高优先级，而真正的首屏标题和壁纸反而只有默认优先级，等于小图在跟主图抢带宽
06修复 · 具体变更
修掉书签导航页一个一直裂着的图标：那条 Firefly 主题书签指向 /favicon/firefly-32.png，但换 favicon 时把这个文件删掉了，页面上一直是个 404 的空图标，改用图标库的 GitHub 图标
- 第 5 次记录
首屏少传 283KB，标题不再等贴纸图
展开这条记录
背景
跑了一次 Lighthouse 体检：桌面端已经满分，移动端 72 分，而且瓶颈压在一个反直觉的地方——不是 JS 慢、也不是图太大，而是首页标题被 9 张贴纸图的加载堵住了，最大元素的渲染延迟高达 2190ms。这次把贴纸图、装饰层入场逻辑和 favicon 一起收拾了一遍
01性能 · 具体变更
贴纸图压缩到实际显示尺寸：8 张从 331KB 降到 127KB（省 62%）。源图是 360×480，但 CSS 里 max-height: 104px 把它们夹到约 78×104，按 192 宽重新导出并降低 alpha 压缩质量
03性能 · 具体变更
favicon 从 88KB 换成 8.9KB：原来那个 .ico 其实是一张 221×183 的 PNG 改名的，重新生成了 16/32/48 的真多尺寸 ICO
05视觉 · 具体变更
关闭桌面端与移动端的水波纹动画效果，减少持续占用主线程的 canvas 绘制
07维护 · 具体变更
体检数据与优化清单整理进 docs/pagespeed-optimization.md，按合并上游的风险分档，附可复现的判定命令
02性能 · 具体变更
修掉首页 LCP 被贴纸图阻塞：装饰层入场动画原本要等 9 张图全部加载完才开始（还带 1400ms 兜底超时），现在只等卡片自身的图、兜底收到 400ms，标题的渲染延迟从那 2190ms 降下来
04修复 · 具体变更
新增 favicon-192.png，OG 图生成和 apple-touch-icon 改用 png 格式图标——只有 .ico 的话会落到 sharp 兜底，而它读不了 ICO，站点图标会静默降级成透明图
06视觉 · 具体变更
开启多张壁纸自动轮播，每 5 秒切换一张
- 第 4 次记录
首屏图片体积砍掉 93%
展开这条记录
背景
把 7 张壁纸从 PNG 批量转成 WebP q90，总量从 14.3MB 压到 1.0MB；同时给 CDN 缓存加了过期续命机制，访客永远秒开旧页面，后台静默更新
01性能 · 具体变更
壁纸全部转成 WebP q90：桌面端 4 张 + 移动端 3 张，总计 1.0MB（原 PNG 14.3MB），首屏图片加载量减 93%
03性能 · 具体变更
vercel.json HTML 缓存加 stale-while-revalidate=604800：CDN 缓存过期后先给访客旧页面秒开，后台同时拉新页面更新缓存
02性能 · 具体变更
新增 scripts/compress-wallpapers.ts：一键压缩壁纸到指定质量，支持强制重跑，以后换壁纸跑一遍就行
04维护 · 具体变更
壁纸配置同步更新为 .webp 路径，构建验证通过
- 第 3 次记录
页面全部缓存到边缘节点
展开这条记录
背景
vercel.json 按资源类型分层设置缓存头：HTML 边缘缓存一天、哈希资源一年不可变，部署后自动预热全站缓存，新文章发布依旧即时可见
01性能 · 具体变更
HTML 页面新增 s-maxage=86400 边缘缓存，CDN 节点直接吐页面；浏览器端保持 max-age=0，发新文章立即可见
03性能 · 具体变更
/assets/、/pagefind/、/pio/ 等静态资源缓存 30 天，过期后由 CDN 后台重新验证更新
05自动化 · 具体变更
新增 Cache Warm 工作流：每次部署后自动从 sitemap 提取全站 URL 预热边缘缓存，并统计命中率
02性能 · 具体变更
/_astro/ 哈希静态资源缓存一年并标记 immutable，重新部署自动换哈希无需手动刷新
04性能 · 具体变更
/api/ 数据接口边缘缓存 1 小时，浏览器端不缓存
06自动化 · 具体变更
预热脚本多轮并发请求直到 HIT 率达标，日志直接输出在 Actions 运行记录