从内容骨架到个人站点：近期架构与视觉迭代
最近几轮改动的重点，是让博客拥有稳定的内容结构和一致的视觉语言。功能数量确实增加了，但更重要的是确定哪些信息应由目录表达、哪些交互只服务于首页、哪些效果需要在触屏和低性能环境中主动收敛。
这篇文章把此前分散在代码与提交记录里的变化整理成一次阶段复盘。
首页成为两种内容的共同入口
首页现在有 Articles 和 Gallery 两种视图。导航栏切换 Gallery 时保留首页的背景、标题区域和整体上下文，只替换下面的内容流；URL 使用 ?view=gallery 表达状态，因此刷新和分享后仍能回到对应视图。
两种视图读取各自独立的数据：
- Articles 使用
posts/，显示文章分类、最近更新和文章标签； - Gallery 使用
gallery/，显示画廊分类、作品数量、画廊标签和瀑布流； - 专题目录中的
index.md负责介绍，普通 Markdown 负责具体内容； hidden: true作为统一的内容隐藏开关。
首页的 Recent 只统计带有效日期且在最近 30 天内发布的文章。这也意味着 frontmatter 中的 date 已经成为内容发布流程的一部分，新增文章时需要认真填写。
内容接入逐渐统一
除了 Markdown，站点还需要容纳课程 PDF、Obsidian 笔记和首页音乐。现在这些内容都通过明确的目录约定接入：
posts/中的 PDF 会被复制到构建产物；同名 Markdown 存在时，它可以承担摘要和阅读笔记；- Obsidian 风格的图片引用、callout 与常见代码围栏会在构建阶段转换；
public/audio/home/中的音频会自动组成播放列表，文件名直接作为曲目名；gallery/images/的原图通过脚本生成适合网页加载的 AVIF 资源。
这些能力都围绕同一个原则：内容作者维护文件和元数据，构建层负责把它们转换成站点可消费的数据。
视觉系统从局部样式走向统一规则
近期对亮色和暗色主题都做了系统调整。颜色、边框、阴影、圆角和玻璃表面先沉淀为设计变量，再由首页卡片、侧栏、文章目录和代码块共同使用。这样修改主题质感时，不必在多个组件中反复猜测相近色值。
文章页也补上了更清晰的标题层级、正文宽度、代码块样式和目录反馈。桌面端侧栏支持调整宽度，较窄窗口和移动端则回到更简单的响应式布局。
这轮视觉整理留下了前后对比图，放在 docs/visual-polish/，用于后续判断改动究竟改善了哪些页面，而不只依赖开发时的即时感受。
动效服务于状态反馈
站点现在包含几组具有辨识度的交互：
- 导航文字在悬停时进行逐字翻转，追光效果同步标记当前栏目；
- 首页标题按 Articles/Gallery 切换品牌图形和文字表现；
- 卡片根据指针位置产生聚光与轻微倾斜；
- 明暗主题切换使用以触发点为中心的视图过渡；
- Gallery 卡片在瀑布流中保留图片尺寸差异，减少统一裁切带来的信息损失。
这些效果需要遵守组件生命周期：路由或视图变化后重新计算状态，卸载时移除监听器，避免一次导航留下多份事件处理。触屏设备、减少动态效果偏好和不支持相关浏览器 API 的环境，则使用静态或简化表现。
当前维护流程
新增普通文章时：
- 选择
posts/根目录或已有专题目录； - 填写
title、date、description和tags； - 新专题先创建带
publish: false的index.md； - 本地运行
npm run check和npm run build； - 新专题或阶段性内容完成后，同步更新全站文章归档。
画廊内容使用同样流程，只需把根目录换成 gallery/。音频放入 public/audio/home/，画廊图片的可复现处理命令是：
bash scripts/build-gallery-images.sh下一阶段
接下来更值得投入的方向，是继续完善内容本身的元数据和专题介绍，让搜索、Recent 与归档都保持可靠；同时给关键组件补充更稳定的自动化检查，减少视觉功能升级时对旧页面造成的回归。
博客已经从“能够发布文章”走到了“具备自己的内容模型与交互语言”。后续每次迭代都应该继续围绕可阅读、可维护和可复现这三个目标展开。