这个项目的目标很明确：做一个可以静态部署的个人图库博客，同时尽量降低图片站点常见的两个问题。
第一是首屏加载太重。第二是内容维护太复杂。
为了让这两个问题都可控，整个站点采用了几条比较核心的技术策略。
1. 用 Next.js 做静态导出
项目基于 Next.js 的 App Router，但最终不是做服务端渲染，而是走静态导出。
这意味着页面会在构建时直接生成成静态文件，部署后不依赖数据库，也不需要运行时接口去拼页面。
这样做的好处很直接：
- 部署简单，适合 GitHub Pages 这类静态托管
- 成本低，维护压力小
- 页面结构稳定，适合个人作品集和博客
2. 图片在构建期处理，而不是运行时处理
图库站最大的性能压力通常来自图片。
如果原图直接进入首页和列表页，移动端体验会很差，所以这里把图片处理放在构建阶段完成。
每张原图会自动生成三层资源：
thumb：给首页、列表页和卡片页preview：给详情页默认展示full：只在用户点击查看原图时加载
这样做以后，用户平时浏览到的是较轻的版本，而不是一上来就下载原图。
3. 内容层把图片和文章统一成一个可读模型
项目里真正让页面简单的，不是样式，而是内容层的抽象。
图库和博客最终都会整理成统一的数据结构，比如：
- 标题
- 日期
- 摘要
- 标签
- 封面
- 图片列表
页面组件只消费这些统一数据，不关心文件到底来自哪里，也不直接拼图片路径。
这让后面做首页、图库页、标签页和博客页都轻很多。
4. 发布流程做了“最小输入”优化
一开始如果每组图库都必须写 index.md 和 images.json，维护成本会很高。
所以现在内容层支持了更轻的用法：
- 图库：只要新建目录并放进
images/ - 博客：普通文章可以直接写一个
.md
如果你后面想补标题、摘要、标签和图片说明，再补元数据文件就可以。
这种策略比较适合个人站点，因为它优先保证“能持续更新”，而不是强迫每次发布都走完整流程。
5. GitHub Pages 的关键适配点
因为这个站部署在 GitHub Pages 上，所以还有一个很实际的问题：它不是挂在网站根路径，而是挂在仓库子路径下。
这会影响：
- 页面路由
- 静态资源路径
- 构建后的图片地址
所以项目里对 GitHub Pages 做了单独适配，确保缩略图、预览图和原图都能在 /xiaety_gallery/ 这个前缀下正常访问。
6. 混合横竖图的展示策略
图库站还有一个常见问题：横图和竖图混排时，要么裁切严重，要么留白很多。
这次的处理策略是：
- 首页精选区使用规则网格，保证整体整齐
- 图库归档页和标签页使用更适合混合比例的瀑布流
- 卡片图片默认完整显示，不再强行裁成统一竖图比例
这样做不是完全追求绝对统一，而是优先保留图片内容本身。
结语
这个项目最重要的不是某个单独的技术点，而是几件事一起配合：
- 静态导出让部署简单
- 构建期图片处理让浏览更轻
- 内容层统一抽象让页面实现更干净
- 最小输入的发布方式让维护更省力
对于个人图库博客来说，这样的组合比复杂的后台系统更适合长期维护。