正文：那我走？

之前给博客做手机适配时，文章页有个挺明显的问题：目录、右下角工具，还有访客提示，挤在一块了。

单独看每个组件都没什么毛病，放到手机那点宽度里，正文反而成了最容易被挡住的那个。

功能越加越多，看文章的地方越来越少

所以这次把几个组件的位置和展开方式重新调整了一下。毕竟这些东西加上去，最后还是为了方便看文章。

目录不需要一直浮在正文上面

目录展开以后，如果还是一个固定浮层，就可能直接盖住下面的内容。手机上空间本来就少，目录稍微长一点，这个问题就更明显了。

本站现在把手机文章页的目录改成了流式卡片：打开时，后面的内容跟着往下排；收起以后，把空间还回去。

关键的定位调整大概是这样：

1
2
3
4
5
6

@media screen and (max-width: 900px) {
  #body-wrap.post #card-toc {
    position: static !important;
    transform: none !important;
  }
}

这里限定了手机视口和文章页，电脑上的目录不跟着一起改。

不过目录也不能无限展开。长文章里标题比较多，直接铺开的话，看正文之前可能先滑了半天目录……

所以展开后给目录内容限制了高度，超出的部分在卡片里滚动：

1
2
3
4
5
6
7

@media screen and (max-width: 900px) {
  #body-wrap.post #card-toc.open .toc-content {
    max-height: min(38dvh, 300px) !important;
    overflow-y: auto !important;
    overscroll-behavior: contain;
  }
}

38dvh 跟着当前视口高度算，再用 300px 限制一下上限。overscroll-behavior 则用来减少目录滚到边缘后，继续带着外层页面滚动的情况。

目录能打开、能滚、能跳转就够了，没必要一直盖在文章上。

右下角工具先收起来

阅读模式、主题切换、目录、评论、回到顶部……这些按钮都挺有用，但不需要每次看文章都一起摆出来。

手机端现在默认只留一个箭头，点开以后再显示完整工具组。点完其中一个工具，或者继续滚动文章时，就自动收回去。

这样平时少占一点位置，要用的时候也不难找。

底部位置还留了手机安全区：

1

bottom: calc(14px + env(safe-area-inset-bottom));

如果设备有底部安全区，就把那部分也算进间距，尽量别让按钮贴着系统操作区域。

提示就别来凑热闹了

博客里还有一个访客提示彩蛋，放在其他页面还挺有意思。但文章页已经有目录和阅读工具，再弹一个提示，多少有点热闹过头了。

所以文章页直接不显示这个提示。

再喜欢小彩蛋，也得给正文留条活路

类似的调整还有正文行高、代码块横向滚动、图片宽度，以及按钮的触摸区域。手机适配也确实不能只把电脑页面缩小一点就结束了。

有些东西还是得拿手机看看

现在加了检查工具展开、收起和切页后操作的测试，能帮忙发现一些状态问题。切换页面用的是 Pjax，所以还得确认新页面里的按钮能重新初始化，也不会重复创建。

但按钮逻辑通过了，实际看起来舒不舒服，还得打开页面看看。文字会不会太挤、手指好不好点、横屏时有没有奇怪的位置，这些都不能只靠代码判断。

先把这几个抢位置的组件安排好。之后再加东西之前，至少先想一下：手机上的正文还有没有地方待）

文件改了，页面没变）

有一种情况挺迷惑的：CSS 已经保存了，本地页面也能打开，但刚改的样式就是没出现。

看着源文件里的代码，再看看浏览器……难道我改的是另一个博客？

先怀疑一下自己也不是不行

我这个博客有一点额外的处理：自定义的 CSS 和 JS 会合并成两个文件，页面加载的是这两个合并包。所以源文件改了以后，还得把合并包重新生成一遍。

顺手记一下，免得下次又对着没变化的页面发呆。

页面实际读的是哪份文件

博客基于 Hexo 和 Butterfly，自己加的样式放在 source/css/，脚本放在 source/js/。

文件多了以后，就加了一步合并，减少一些资源请求。页面里引用的主要是：

1
2

<link rel="stylesheet" href="/css/custom-bundle.css">
<script src="/js/custom-bundle.js"></script>

比如改了 source/css/custom.css，真正需要更新的还有 public/css/custom-bundle.css。

源文件是新的，不代表浏览器正在读的那一份也是新的。

只启动 server，少了一步

本站的构建命令是这样的：

1
2
3

{
  "build": "hexo generate && node scripts/merge-assets.js && node scripts/cache-bust.js"
}

前面是 Hexo 生成页面，后面两步是博客自己加的处理：合并资源，以及给资源引用加版本号。

但直接启动 hexo server，不会顺带执行后面这两个脚本。于是可能出现两种情况：第一次预览时，合并包还没生成；之前构建过的话，页面读到的还是旧包。

所以我这里的预览顺序是：

1
2

npm run build
npm run server

之后再改自定义样式，也需要重新 build。还有一个容易忘的地方：改了 _config.butterfly.yml，要重启 server，配置不会直接热更新。

这套流程是本站额外加的，如果你的 Hexo 项目直接引用单个 CSS 文件，情况可能就不一样了。

新文件也得登记一下

还有一种情况是，原来的样式都正常，只有新加的那份没效果。

合并脚本没有自动把文件夹里的所有东西都塞进去，而是按清单读取文件。新增文件以后，需要在 scripts/merge-assets.js 的 CSS_FILES 或 JS_FILES 里登记路径。

比如新加了一个样式文件，清单里就得有这一项：

1

'/css/example.css',

这里用的是生成后的资源路径，不是 source/css/example.css。

文件放进文件夹了，但还没被点名，属于是白来了

现在清单里如果写了一个不存在的文件，构建会直接报错并指出路径。比起带着少一块的样式继续生成页面，这样反而更容易找到问题。

最后再看看缓存

合并包已经更新，页面还是旧效果的话，再看看浏览器缓存。

本站构建后会根据 CSS、JS 的文件内容给引用加一个版本号，大概长这样：

1

/css/custom-bundle.css?v=一段由文件内容计算出的值

文件内容变了，这个值也会变，浏览器就能请求新的资源。

以后遇到样式没出现，我会先看页面实际加载的文件，再确认合并包有没有更新、新文件有没有登记，最后看缓存。

至少不用一上来就怀疑自己 CSS 又写错了）

终于有了个追番工具）

学了一段时间 Java，也想折腾一个自己真正需要的工具，于是就有了 OtakuLog。

说实话就是…作为一个追番人，每次都要打开 Bangumi 手动更新进度，有时候忘了就一直显示”在看”，看着一堆过期的追番记录很烦。干脆自己做一个算了。

做了什么

核心就是追番管理——添加番剧、记录看到第几集、打分、写备注。听起来很简单对吧，但做着做着就越做越多了…

• Bangumi 一键导入收藏，不用手动一个个加
• 进度追踪，看到最后一集自动标完成
• 三种视图切换：表格 / 卡片 / 封面画廊
• 拖拽排序，顺序会保存到后端
• 观看热力图，精确到每一集的观看日期
• 以图搜番（截个图就能识别是哪部番哪个场景）
• WebDAV 多设备同步
• 分享卡生成，可以把追番总结做成图片分享

结果做到后面功能越来越多，感觉自己在写一个小型 Bangumi 客户端

技术栈

后端用了 Spring Boot + JPA + MySQL，前端是 Thymeleaf + 原生 JS（没用前端框架，就是写着玩的）。用 Flyway 管数据库迁移，目前已经有 5 个版本了。Chart.js 画统计图，SortableJS 做拖拽，Phosphor Icons 做图标。

测试写了 44 个，Controller / Service / Repository 三层都覆盖到了。说实话写测试的时候才发现好多边界情况自己根本没想到…

印象深刻的坑

Bangumi API 缓存：Bangumi 的 API 有请求频率限制，一开始没做缓存，连续搜几次就被限流了。后来加了 Caffeine 缓存，舒服多了。

热力图数据：一开始用简单的字段记录”看了几集”，后来发现要做热力图需要精确到每一集的观看时间。于是加了 episode_record 表，每次更新进度都记录一条事件，热力图的数据就是从这里来的。

以图搜番：接入了 trace.moe 的 API，上传一张截图就能匹配到番剧名和集数。这个功能纯粹是觉得好玩才做的，但意外地很好用，有时候看到一张图想不起来是哪部番的时候直接搜一下。

写在后面

这是一次把追番需求变成小工具的尝试。虽然功能上比不过那些大项目，但能用它整理自己的观看记录，对我来说就挺有意义的。

GitHub 地址：OtakuLog