XiYuJing|文章:243 次提交之后：XiYuJing 开发流水账

[[item.c]]

翻完 GitHub 上的上传记录，才发现从 8 月 30 日到 9 月 14 日，`origin/main` 已经积累了 **243 次提交**。

这不是一份提前排好的开发计划，更像一本边用边改、边改边修的折腾日记：白天觉得某个地方不顺眼，晚上就打开编辑器；一个小功能上线后，又拖着文件管理、后台配置、移动端样式和一串边界情况一起长大。

把提交记录按时间摊开，大致能看到这样一份账本：

- 8 月 30 日：83 次提交，先把全站的脸和骨架换了一遍。
- 8 月 31 日：5 次提交，继续修首页标签云的 3D 投影和远近层次。
- 9 月 4 日：8 次提交，网站配置真正联动前台，后台和资源聚合开始重做。
- 9 月 5 日至 6 日：66 次提交，文章编辑、评论、相册、音乐播放器和右侧栏集中落地。
- 9 月 7 日至 8 日：28 次提交，处理加载体验、视频背景、导航交互与归档时间线。
- 9 月 13 日：27 次提交，把日志、访问 IP、留言弹幕和评论体系补起来。
- 9 月 14 日：26 次提交，统一头像、文章封面、文件用途和各类前端细节。

数字看起来很热闹，真正值得记下来的，是这些提交背后反复出现的问题。

## 第一段：先对齐 poetize，再谈“自己的风格”

最初最密集的工作几乎都围绕视觉重构。导航栏先是统一模板，随后又参考 poetize 重做；登录与注册从普通表单变成滑动卡片；百宝箱经历了下拉菜单、专题页、收藏卡片和友链布局的多轮调整。

文章页也是同样的节奏。Markdown 正文换成 `vditor-reset` 风格，代码块改成深色高亮，顶部封面重新排布，右侧目录固定到屏幕四分之一处，右下角只留下目录、回顶和主题设置三个按钮。

现在回头看，这一段并不是简单的“抄样式”。真正耗时的是那些肉眼不一定注意、但一碰就出错的地方：

- 下拉菜单鼠标移动时突然消失，于是补透明桥接区域。
- 收藏夹面板多了一个 `</div>`，把后面的友链面板挤出居中容器。
- 全站没有统一设置 `box-sizing`，卡片宽度一加内边距就从四列变成三列。
- 打字机反复点击会启动多个循环，切换时还要先逐字删除再逐字输出。
- 目录所在滚动容器不是窗口，`window.scrollTo` 根本不起作用。

这些问题在提交标题里各占一行，实际排查却经常要从模板、CSS、压缩后的 JavaScript 一路查到浏览器控制台。也正是这些细碎修复，让页面从“大体像”慢慢变成了“可以一直用”。

## 第二段：功能开始互相牵连

9 月 4 日之后，开发重点从页面样式转到了完整功能。

网站配置开始驱动首页昵称、简介、欢迎语和打字机诗句；资源聚合把音乐、友链、收藏夹和相册收进统一后台；文章编辑页支持从文件管理器中插入图片、音频和视频；页脚版本号也与后台配置同步。

紧接着，音乐播放器、首页三栏布局、移动端抽屉导航、日历筛选和文章归档陆续出现。一个功能也不是孤立完成的：

- 音乐播放要跨页面不中断，还要记住曲目、进度、播放模式和浏览器自动播放限制。
- 视频背景要兼顾固定效果、首帧加载、移动端性能和加载界面退出时机。
- 归档页做成蛇形时间线后，又要处理列数、连线方向、背景层级和滚动容器。
- 后台上传 MP4 时顺手调用 `ffmpeg` 做 faststart，避免用户等视频缓冲。

这一段最明显的感受是：前台看起来只多了一个按钮，后台往往要多一套模型、一组接口、一个管理页面，以及若干条“文件删了但数据还在”“资源改名后页面找不到”的收尾逻辑。

## 第三段：后台不只是 CRUD

9 月 13 日，后台新增了实时日志、访问 IP 统计、属地和风险识别，还能按请求频率标记异常访问、批量拉黑高风险 IP。页面本身不算华丽，但它让很多以前只能 SSH 进去确认的事情，变成了可视化操作。

同一天，留言板和弹幕上线，文章评论区也同步换成公共评论编辑器。评论表情包、图片上传、服务端校验、悬停预览、后台筛选和未关联图片清理，一项接一项补齐。

这里花了大量时间在“不要相信输入”上：

- 图片要经过服务端校验，不能只看前端扩展名。
- 弹幕内容要过滤和限长，不能直接塞进页面。
- 评论图片失去关联后要能自动清理，避免存储越积越乱。
- 匿名用户与登录用户的历史头像、回复弹窗和展示比例要统一。
- 后台管理不能只显示数据，还要能按留言、弹幕、图片等实际用途筛选。

功能越多，越能理解为什么日志、权限和清理机制不能等到最后再补。很多“上线后再处理”的问题，最后都会以更高的排查成本回来。

## 第四段：最后一轮，开始收拾仓库和素材

9 月 14 日的提交看起来没有前面那么“新”，却更像一次真正的大扫除。

文件管理增加了使用位置查询，图片开始按实际用途归类并规范扩展名；账号头像与头像图片管理拆开，文章封面也终于有了独立管理页和背景预览；后台侧边栏会记住展开状态，弹幕历史头像和匿名头像规则得到修正。

这些改动不会立刻带来一个炫酷的新页面，却直接影响长期维护：

- 知道一张图在哪里使用，删除前才有底。
- 知道封面属于哪篇文章，换图时不用逐个试。
- 知道文件按用途归档，备份和迁移才不会靠猜。
- 知道排序、筛选和预览对应真实数据，后台才不是一堆表单的集合。

## 最后：流水账里真正留下来的东西

243 次提交不是一个需要炫耀的成绩。它更像 243 个问题被拆开、处理、验证，然后留下的时间戳。

这次开发最大的收获有三个：

1. **视觉统一不是换几组颜色。** 导航、登录、文章、后台、移动端和加载状态都得一起变，才不会出现“首页很新，点进去还是旧项目”的割裂感。
2. **一个功能从来不是一件事。** 上传背后是校验，展示背后是缓存，删除背后是关联，配置背后是权限，真正的成本通常藏在主流程之外。
3. **记录比记忆可靠。** 提交信息写得具体，过几天还能明白当时为什么修改；日志和后台数据足够清楚，线上出问题时才有排查入口。

这篇流水账写到这里，最后一条公开提交是「优化登录与匿名弹幕头像规则」。GitHub 页面暂时安静了，但博客本身还没有“完成”这个概念。

下一次继续折腾时，大概还是会在某个看起来很简单的地方停下，然后修出一串新的提交。至少现在，每次修改都有迹可循，算是给这段开发过程留下了一份完整的备份。

留言