Avatar

Fusion Atlas

Every Hero Has a Code

Avatar

"Our lives are not our own. From womb to tomb, we are bound to others, past and present, and by each crime and every kindness, we birth our future."

网站开发日志

全文阅读时间：约 43 分钟

前言

首页主要讲明了为什么要做一个网站，本页则记录基本的网站搭建、开发、更新和维护内容。

绝大多数人对网站构建的完整流程没有太多概念，那我在做简单科普的同时，也是为自己梳理思路，何乐而不为？

目录

第一章：前期规划

1.1 站点性质

在编写第一行代码前，必须明确站点的性质，这决定了后续的技术栈选型，最简化可以分为两类：

  • 静态站点 (Static Site)：

    • 定义: 内容预先生成，无需服务器端实时运算。
    • 适用: 个人博客、文档库 (Docs)、Landing Page、作品集。
    • 核心技术: HTML/CSS, SSG (Static Site Generators - Hugo/Hexo/Astro).

  • 动态应用 (Dynamic App):

    • 定义: 依赖数据库交互，需服务器端实时渲染 (SSR) 或处理逻辑。
    • 适用: 论坛、电商、SaaS 工具、社交平台。
    • 核心技术: Database, Backend API, Server/Container.

毫无疑问，我需的是静态站点，至少一开始应该是静态站点。

在确定这一点后，第一时间想到的就是各类知名笔记软件的自有发布网站，比如 Obsidian 和 Notion，但发布功能几乎都是付费订阅高级版专享，其实最开始我甚至愿意尝试订阅，但无一例外这些软件所提供的网站服务其自定义程度都明显不够。

既然如此，我为何不尝试从更底层开始呢？

直觉告诉我,静态网站的项目应该会存在不少的开源项目，一查，果不其然。

多方对比之后，最终敲定 “quartz v4”。

1.2 Quartz v4 项目

  • Quartz (尤其是 v4 版本) 是目前构建 数字花园 (Digital Garden) 和个人知识库最优雅的方案之一，它将笔记工具与 Web 发布流程完美解耦，这玩意诞生之初就是用作 Obsidian 官方发布功能的平替，而且完全开源。

Quartz优势：

  • 性能:

    • 生成的是纯静态 HTML，TTFB (首字节时间) 极低，加载速度极快。

  • 极低运维成本:

    • 托管在 GitHub Pages/Cloudflare Pages 上是免费的，且没有服务器被黑的风险（因为是静态文件）。

  • SPA 单页应用 (Single-page application):

    • Quartz 默认启用了客户端路由，点击链接时，网页不会整页刷新，而是像 App 一样平滑过渡。这在静态博客中极为罕见，极大提升阅读体验。

  • 知识关联:

    • Quartz 原生支持 Callouts (警告块)、Latex 公式、Mermaid 图表，继承 Obsidian 的双向链接 + 类似 Wikipedia的鼠标悬停悬浮预览卡片（例如这个：正式发布页），以及内置了 D3.js 驱动的局部/全局关系图谱，完美复刻 Obsidian 的积极体验，这在传统博客框架 (Hexo/Jekyll) 中很难实现。

第二章：后端搭建

敲定了用什么搭建的问题，下一步就是建在哪儿的问题，首先要考虑服务器方案。

2.1 服务器

2.1.1 自己搭一个 (Self-hosted / Homelab)

  • 适用场景: 极客折腾党、低成本大容量存储需求、数据完全自主掌控。

这条路需要自有硬件服务器，虽然说丰俭由人，大到台式机、正经服务器，小到NAS、NUC、旧笔记本甚至树莓派都可以，但要操心的点就太多了。

首先就是比普通电脑更严苛的硬件维护，保证7*24小时不间断运行的，必然要开始考虑 UPS 电源等外围硬件。

之外，还得操心软件使用，比如操作系统基本都是 Linux ，又是一笔额外的学习成本。

网络层面，也基本从头到尾都得自己操心，公网 IP 与内网穿透、动态域名(DDNS)这些都是必备配置流程…

虽然这是终极目标，不过当前阶段来说，成本和运维复杂度都有些杀鸡用牛刀，只能以后再说，一步一步来吧，步子迈大容易扯着蛋…

2.1.2 云服务器 (VPS/Cloud Compute)：

  • 适用场景: 动态应用，需要运行 Docker 容器，需要高度自定义环境或追求性能上限的场景。
  • 平台: AWS EC2，DigitalOcean，Hetzner，阿里云，腾讯云等；

在需要高性能、高稳定性甚至高扩展能力的情况下，云服务器几乎是绕不开的，但好在我并不需要，除非一开始就奔着商业项目而去，云服务商基本都按流量计费，万一遇到被DDoS攻击等恶性事件，运维的负担都是迟早的，其实相比纯粹的技术问题，最难的是如果用阿里云、腾讯云等大陆境内服务器，必须进行 ICP 备案与公安联网备案，否则无法通过 80/443 端口提供服务，火上浇油的麻烦只多不少。

2.1.3 静态托管 (Serverless/PaaS)：

  • 适用场景: 纯静态内容，数字花园，API 驱动的 JAMstack 应用。

  • 平台: GitHub Pages，Cloudflare Pages，Vercel、Netlify等。

  • 优点:

    • 零运维 无需配置 OS、Nginx 或 SSL。Git 推送后由平台自动完成构建、压缩与全球边缘分发。
    • 极致性能: 内容托管在 CDN 节点，用户访问时从地理位置最近的服务器获取，TTFB (首字节时间) 极低。
    • 高安全性: 网站仅由静态 HTML/JS/CSS 组成，不存在传统意义上的后端漏洞，极难被黑。
    • 免费/极低成本: 对于个人开发者，GitHub/Cloudflare Pages 的免费额度通常足以覆盖每日数万次的访问量。

  • 缺点:

    • 灵活性受限: 无法直接运行服务端逻辑（如无法直接运行 Python/Go 脚本），必须依赖第三方 API 或 Serverless Functions (Edge Functions)。
    • 构建时限制: 网站规模极大（数万个页面）时，构建时间受限于平台提供的 CI/CD 性能，可能需要收费升级。
    • 环境黑盒: 无法自定义底层的缓存机制或服务器配置，只能在平台允许的范围内调整。
    • 对中国大陆优化有限: Vercel 等平台在大陆偶尔会出现解析抖动，最好配合 Cloudflare 优化。

其实可以直接写这一段的，但是我认为有必要补充好自建或租云服务器的部分，这样好对比。

Quartz 项目本身就是在 Github 上完全开源的项目，这意味着我可以：

一条龙操作了属于是，真正经历过一个项目之后，才真正体会到微软的可怕。

思索了一会后，我决定简单列举一下整个网站搭建的全流程，顺便看看微软在这其中都参与了多少：

2.2 后端搭建全流程

2.2.1. 终端与代码生产层面

项目起始于操作系统，嘿，您猜怎么着？这里是微软的传统基本盘… 😅

  • 操作系统 (OS): Windows 10 。

    • 这还有啥好说的，生态级别的寡头垄断，虽然 Mac、Linux 也不是不能选，但考虑到后续的各个步骤，这微软从一开始就绕不开了，因为Windows 控制着所有的开发环境变量，不用 Windows 那不就是给自己找罪受…

  • 集成开发环境 (IDE): Visual Studio Code (VS Code)。

    • 依旧 行业垄断 ，这一个月全程使用 VS Code 写代码，我现在能理解为什么 VS Code 能绑架全球开发者的插件生态和编码习惯，太多上下游功能整合在其中，不用不知道，确实太方便了。

  • 版本控制 (SCM): Git。

    • 虽然 Git 是开源的，但其全球采用率已超过 93.8%！ 😅
    • 更骚的是，我在终端中频繁使用的各种 Git 凭据管理和集成界面，均由 VS Code 内置驱动！我一开始不知道还专门下载了GitHub Desktop桌面端软件 🫠 ，用了很久才发现根本没必要，直接用 VS Code 全搞定了 🤣 ，深度集成让“微软化的 Git 操作”成为了事实上的交互标准…

2.2.2. 代码托管与协作层面

代码搞定后，就是发布到线上仓库的步骤。

而当我执行 git push 时，数据流向了 Github。

作为全世界几乎所有程序员的代码仓库，结果微软在 2018 年花费 75 亿美元全资收购了，当时我顶多是个圈外爱好者，没什么感觉，现在开始汗流浃背了… 😅

  • 代码仓库 (Repository): GitHub
    • 占有率: 截至 2025 年，GitHub 拥有超过 1.5 亿 开发者用户，托管仓库总数突破 10 亿。
    • GitHub 几乎是现代开源界的代名词。微软通过收购 GitHub，全球数亿万计的项目源码和开发者的行为数据现在全在微软手里。

2.2.3. 持续集成与部署层面

Quartz 的自动化部署直接用上了 GitHub 的原生云能力。

代码同步到线上仓库后我甚至不需要点击什么，自动化流水线会在同步后直接开始操作网站的内容更新。

我连配置的步骤都省了，当然这一点是 Quartz 原作者的功劳，人家直接把这一步打包封装好了。

  • 自动化流 (Workflow): GitHub Actions。

    • 现状: GitHub Actions 是目前个人及中小企业中使用率最高的 CI/CD 工具（占比约 62%）。
    • 地位: 基础设施垄断。Quartz 的核心更新逻辑、转换逻辑均在微软的服务器上跑的。

  • 运行环境 (Runner): Azure 云基础设施。

    • 现状: GitHub Actions 后端由 Azure 提供算力支持。Azure 目前稳居全球公有云市场第二（约 23-25% 份额）
    • 毕竟亚马逊电商相关的云服务是大头，但 Azure 就不一样了，我的每一次构建，都在消耗微软的算力，但这是免费的…虽然占有率比不上第一的亚马逊，但在开发者服务领域，其渗透率远超亚马逊。

2.2.4. 静态分发与解析层面

最终，网站通过微软的 CDN 触达全球（不过我接下来打算使用 Cloudflare 进行优化）。

  • 静态托管 (Static Hosting): GitHub Pages。

    • 静态网站托管市场的领头羊，完全免费、与仓库深度集成、一键部署。对于开源文档和个人博客，其市场占有率虽然没什么公开资料，但依然是个人开发者、学术机构和开源项目文档的“默认选择”，虽然有 Vercel 和 Cloudflare 的新的平替选择，但其地位在短期内不可动摇。

  • 域名解析 (DNS): 默认提供的 .github.io 域名。

    • 微软不仅提供了内容容器，还定义了大部分人在公网上的寻址方式与品牌背书。
      • 不过这个问题倒是不大，GitHub Pages 支持换域名。

2.3 后端搭建总结

从头到尾我的感受是，真正的强大并非表现为专利流氓或强制收费，而是一种 “不可替代的顺滑”：

  1. GitHub 托管代码。
  2. VS Code 编写代码。
  3. GitHub Actions 自动化构建。
  4. GitHub Pages 最终发布。

这形成了一个完美的、自我强化的开发者闭环。

“开源” 对于世界级大厂的战略意义，就是让我们从一个产品无缝迁移到了另一个产品。

毕竟越是大厂，越没有纯粹做慈善的，这种对基础设施的底层占领，确实是核心竞争壁垒。

当然了，只是这次的经历让我把注意力主要集中在微软了，并不是针对它。

真要举例谷歌、苹果、英伟达，甚至阿里、腾讯等区域巨头，在各自的核心领域，其一手遮天的程度也都差不多。

毕竟能混到正球级别的垄断地位的，没有一个是吃干饭的。

第三章：前端开发

Quartz 使用 Preact (JSX) 和 TypeScript 进行组件化开发，如果想深度修改布局，得具备前端开发知识，虽然门槛不低，但时代变了，现在有生成式AI，这对我来说就变成了可能。

顶级大模型确实是超水准教师，极大帮助学习时理清思路，作为一个没系统性学过编程的人，靠着 Gemini 3.0 Pro，愣是把这个网站开发完毕了。

虽然磨了一个多月，但从无到有的抠出上千行代码并成功运行，这段经历的价值无可替代。

这么多年总说自己知识学杂了，现在也算是因祸得福，早年间设计相关的东西比如色彩学、配色逻辑啥的没白学，现在能直接用上，代码层面，仰仗着长年网上冲浪的经验，对我倒也不算是毫无概念的天书，这次算是正儿八经的接触并开始深入认识学习TypeScript、CSS（Cascading Style Sheets）、HTML等前端语言。

3.1 Google Gemini AI 协助记录

截止2026年1月，Gemini 的 Canves 功能 + Gemini 3.0 Pro版本的模型，已经能帮我全链路的生成较为复杂的目标代码，虽然大多数时候都得做手动修正，附带耗费大量肉脑的调试工作才能完成，但能做到从零到一的实现，对现阶段的我来说就已经是逆天级别的神导师了，其无微不至的细致程度，几乎是把知识塞脑子里的定制化体验，放以前那可是大户人家才享受得起的顶级私教待遇…

大模型，尤其是多模态大模型，这意味着但靠文字和它说，是完全不够的，需要时不时辅助上传图片和代码文件本身，才能更加地事倍功半。

这就得要求你得非常清楚的知道自己在干嘛，喂给它的图片要怎么截图才能保留足够的信息量？喂给它的代码文件，如何针对性的删除和提问无关的部分？

这都是会越来越繁琐的麻烦事…这对于前期啥也不懂的我来说，确实头大到令人崩溃…

但是！如果你确信自己目标足够明确且具备充足的理论实际性，这些反而是值得的、必要的。

哪怕是平常的菜刀况且需要磨刀，好的AI自然也必须给伺候到位了，才能发挥的好。

在经过和Gemini半个月的互相折磨后，我发现优化提示的技巧是没有上限的，当前AI最适合的身份，就是带菜鸟上分的大佬。

你得想办法主动跟得上大佬，借此加速进步。

反面案例：指望“人工智能”直接帮自己解决问题。

经常这么干的人其实都不知道自己真的在“问”什么，只是机械性的推脱思维在作祟。

AI潮确实让更多人暴露了自己常态化的行为逻辑就是单纯的傲慢，证明了“只想着发号施令”确实是一些人固有的思维习惯。

不过话又说回来了，绝大多数人本来也就只会问些极其简单的问题，面对AI的时候自然也不会例外，他们使用 AI 的场景也大多不会是突破自我上限的尝试，而只是日常琐事而已，自然抱着 “完全糊弄” 的心态，问出 “如何糊弄” 的问题，得到 “足够糊弄” 的回答，最后得以 “随便糊弄” 的交差，也算是达成闭环了。

鉴于我没订阅…每天只有3次Pro版本的提问限额，所以只能把需求做成序列，排着队慢慢问吧，一开始以为会很墨迹，但实测3次其实并不是个大问题，相反，真能天天借这个机会实现3个小需求那才是困难之处，毕竟还有别的事要做。

加上还有几次限额的思考模型和不限量的快速模型，无非是需要我考虑哪些问题是真正有价值的，不过这也算好事，至少能有意识的把好钢用在刀刃上了。

作为实打实把 “用AI” 当成个事情死磕了2个月的人，我明显感觉：

在认真对待、不抱着“完成任务”心态下，想要有效率的去使用大模型协助自己，哪怕每天仅问三个“大”问题，长期下来也是较为耗费心力的事情。

这其实和健身是一个道理，要做的事情没有一个是难的，但能长期坚持的人少之又少。

毕竟只要是人类，都极为擅长纸上谈兵。

3.2.1 我的建站大模型提问词模板：

开场词：

  • 我已在自己的GitHub仓库Fork了quartz项目并成功搭建了自己的个人网站，现在正在配置各种文件以设计网站，请按照如下目标修改当前各个文件内的代码…

修改词：

  • 实操后，预览（npx quartz build —serve）显示不及预期…
  • 使用chrome审查元素后发现…

结尾定义（Canves专属）：

  • 你需要修改相关文件代码来实现这点。

3.2.2 已通过 Gemini 解决的问题

备注：网站前端开发到一半，我才意识到自己应该记录下过程，所以这里仅有一部分的内容。

有些是凭借记忆进行整理，光记得有那么个事儿，细节就没办法写太细了。

  • 当前的布局中间（pageBody）的文章部分，文件名的字号过小，甚至比文章内部的标题（markdown语法中的“# ”）要小，我应该单独调整文章文件名字号，最好也单独修改其颜色。

  • 关于footer布局中的内容，我需要写一个特殊的链接：使用户点击后滚动至当前页面顶部。

  • 搜索栏要自适应页面宽度靠页面最右端对齐，除非页面宽度低于1200px，也就是quartz布局中的平板（tablet）布局，此时搜索栏消失。

  • 布局的中间内容区 (Center)中，最上面的文章文件名距离页面顶部的间距过大。

  • 目前顶栏布局header中，明明已经在quartz.layout.ts文件中定义了Links属于DesktopOnly，且在Component.MobileOnly中没有Links，为什么在预览网页时移动端（也就是窗口宽度小于800px）依旧出现了Links组件？

  • 我需要标题、导航链接组件无论在任何窗口宽度时都靠页面左侧对齐，而搜索栏无论在任何窗口宽度时都靠页面右侧对齐，中间的签名文本则动态显示宽度和自动换行。

  • 我最下方footer布局距离pagebody布局有非常大的空白距离，使用chrome审查元素后发现与 body data-slug=“index”、div id=“quartz-root” class=“page”、下div id=“quartz-body”这层的“grid”部分有关，我在custom.scss中通过footer { grid-area: auto !important; }取消 grid 区域的自动推移，但也只能使footer紧贴在 .page 下方，但空白并未消失，即便文章非常长，页面拉到底后都能继续再拉一段，要彻底消除这段空白。

  • 顶栏布局（header）中签名文本内容过长，使得其他组件被推至窗口外。

  • 有些定义中的“p”、“a”都是什么含义？比如有时修改.sidebar.left .signature {}，还有时则需要修改.sidebar.left .signature { p {}}，区别是什么？还有哪些其他的子定义？

  • 我已经定义好了.signature组件并通过custom.scss定义格式以正常运行，目前问题是，我还想在同一个布局中设计第二个文本，格式与现有的完全不同，可能需要修改相关文件代码来实现这点。

  • 如何在网站首页设计动态效果的跳转卡片？我是依旧需要在scss、tsx、ts文件之间编辑？还是要通过.md文件来配合可编辑样式的markdown链接中插入什么组件？我知道首页本质上是index.md文件，但并不清楚如何与quartz本身进行配合。

    • 已解决，通过单独创建一个新模块组件：LinkCards.tsx，然后在首页文件 index.md 中进行引用从而实现功能，至于具体的显示方式则在custom.scss中专门针对定制。

  • 左侧边栏长度固定导致展开所有文件夹结构后的单个Explorer显示区域被压缩到极小，我希望当内容过长的时候加长的是整个左侧边栏，滚轮滑块应该出现在左侧边栏，而不是Explorer内部，Explorer展开时应该是完整的。

    • 已解决，通过强制撑开容器宽度 + 隐藏左侧边栏滚动条解决。

  • 背景的“流动光斑”动画效果有色彩断层（Color Banding）问题。

    • 已验证为绝大多数显示设备的硬件性能限制。,在深色背景（Dark Mode）下，尤其是 RGB 数值很低（如 rgb(22, 22, 22)）的区域，色彩的可选级数非常少。当你叠加一个巨大的、透明度极低（opacity: 0.1~0.2）的渐变时，浏览器试图在“几乎全黑”和“稍微不那么黑”之间渲染过渡，但 8-bit 色彩深度不够用，于是就出现了像等高线一样的条纹。
    • 这问题断断续续折腾了我3天2夜，目前采取背景添加噪点+改进网页渲染方式+修改动画效果本身尽可能规避等多种办法优化，目前基本上是看着丝滑了，基本可以算是解决…

  • 移动端 下滑刷新（全面屏操作逻辑）失效。

    • 具体问题：连续点击多个站内链接（比如两个全局都存在的链接互相交替点击）从而不停跳转，最终停下时一定会导致浏览器的“下滑刷新”（全面屏操作逻辑）失效，只能使用浏览器的手动刷新按钮，但是反复点击单一链接时则不会出现这个问题…
    • 已验证是 SPA 的问题，（SPA：单页应用，Single-page application，是只加载一个单独网页的 Web 应用的实现，当需要显示不同的内容时，它通过 JavaScript 更新主体内容），为浏览器渲染进程对滚动容器状态的判定锁死，Quartz 会拦截浏览器的默认跳转行为，通过异步获取新页面内容并局部替换 DOM，通过在 Quartz 的 nav 生命周期中强制触发布局重计算（Layout Reflow），从而“唤醒”失效的下拉刷新功能。
    • 已解决，方法为代码补丁注入到 quartz.config.ts 文件中来强制重置浏览器状态。

  • quartz可以将某一个文件夹作为链接显示为一个单独的页面，这个页面中并没有如正常文章页那样显示出我在 custom.scss 中所写的全局效果。我能专门否定制这个页面的内容？

    • 具体问题：quartz.layout.ts 相关代码忘了写。
    • 已解决，补上、完事。

  • 在 quartz.layout.ts 文件中，export const defaultContentPageLayout: PageLayout 与 export const defaultListPageLayout: PageLayout 中的 left部分始终都是一致的，目前我的办法仅是每次修改时都复制粘贴，帮我优化一下，以便每次我仅需要修改一个地方即可。

    • 具体问题：知道改写一个独立的常量然后两处都引用即可，但不知道怎么写，这块交给AI是最省事儿的，最困难的地方就是知道把哪一部分的代码复制粘贴到正确的位置，好在这块目前的我算是能看懂。
    • 已解决，复制、粘贴、预览、保存、完事。

第四章：网站现状

4.1 当前计划 / 需求 / 待实现目标

  • 增加评论功能？

  • 各跳转链接直接的优化，主要是制定各种 绝对路径 和 相对路径 。

  • 网站本身已经基本搞定，开始填内容（发布筹备、各平台存货搬运）。

  • 使用 Cloudflare 进行 CDN 优化。

  • 在一些老设备中，因为老旧操作系统的系统字体库缺少 Unicode 新版本的 Emoji 定义，导致相关 Emoji 表情无法正确显示，指望用户去正确更新补丁是不现实的，得想个办法在服务端/代码层面解决这个问题…

  • 网站测试相关内容需要完整写下来。

  • .md文件内的 markdown 格式表格是否可以定制网站全局效果？（主要是想定制每列列宽）

4.2 已实现需求

4.2.1 开发层面

  • 便于调试
    • 我制作了一个一键打开Quartz本地Web服务器预览的.bat文件以便快速预览，可自动化重启服务（过程中也可手动强制重启）。
    • 我想要在PC的Chrome浏览器中以移动端打开localhost:8080，要怎么办？已解决：Chrome的F12确实有专门的移动端调试按钮。

4.2.2 交互体验增强

  • 文章内跳转按钮，可高度定制样式（层级、形状、配色、动画）的markdown链接，已在首页实现。
  • 全局平滑滚动。
  • footer栏 (页脚) 中“回到顶部” 链接样式优化。
  • 首页（Home）专属卡片定制。
    • 让首页卡片仅在首页生效，同时内容响应式适应各显示尺寸。
  • 正式发布页（Officially）专属卡片定制。
    • 让正式发布页卡片仅在首页生效，同时内容响应式适应各显示尺寸。
  • 关于页（AboutMe）专属卡片定制。
    • 让正式发布页卡片仅在首页生效，同时内容响应式适应各显示尺寸。
    • QQ、微信因其封闭而难以制作直链，目前图省事了直接放二维码。

4.2.3 配色

  • 全局暗色模式
    • 已通过浏览器设置 + 锁定 CSS 变量统一data-theme中light和dark的色值 + 隐藏深色模式切换按钮，组合达成“强制暗色模式”。
  • 流动极简主义背景
    • 虽然当前的网页固定为了黑暗色系，但整体背景为纯色，我想换一个有点高级感的背景，增加大块的渐变色块，最好是轻微动态的，然后使.sidebar.left、.center、.sidebar.right等前景布局半透明，以让背景色模糊的透过，达成一种极简主义+毛玻璃的质感，要符合quartz.layout.ts中整体主题颜色。
    • 后续我希望背景的色块能有尽可能明显的“流动感”，而不是目前的固定摆动，多且密集的色块是不是要比单一且巨大的要好？
      • 需要进一步修改为小而多的色块而不是当前的仅两块，其中蓝色为主，多进行复用，而橙色仅作为点缀，少量使用 已放弃。（性能开销大，且不够纯粹效果容易显脏）。
  • 宏观配色方案完全固定
    • 已专门生成一个“网页实际渲染-预览页.md”的演示预览文件。
  • 自定义全局本文细节
    • 文章主标题表现力增强。
    • 文章(H1)标题略微高亮。
    • 代码块 (Code Block) 增加玻璃质感。

4.2.4 布局

  • 制作全局顶部页眉导航栏(Header)：
    • 定制优化以独立出pageBody页。
  • 页面主容器 (page)：
  • 左侧边栏 (Left)：
    • 已摆放多个不同名称和内容的Explorer + 自定义排序方式。
  • 中间内容区 (Center)：
  • 右侧边栏 (Right)：
  • footer栏 (页脚)：
    • footer布局完全适配整体主题布局 + 整体主题配色。
    • footer布局进行内容自定义。
  • 列表页（文件夹页）定制

4.2.5 针对移动端优化

  • 平板优化（页面宽度小于1200px）：
    • 页面宽度1200px 下隐藏 header 中的搜索框（同步网页自身的转移右侧边栏行为）
  • 手机优化（页面宽度小于800px）：
    • 全局顶部页眉导航栏(Header)完全重新制作，以适配手机竖屏模式。
      • 定制Header中每一个元素的相对位置以适配不同显示宽度的手机。
    • 左侧边栏 (Left)完全隐藏，功能由其他布局的代偿。
    • 右侧边栏 (Sidebar Right) 响应式修正，以优化网页自身转移后的位置和间距。
    • footer栏 (页脚)完全重新制作，以优化网页自身转移后的位置和间距。
    • 背景光斑动画完全重新制作，以适配手机竖屏模式。
    • 首页卡片优化，让首页卡片的内容响应式适应各显示尺寸。

4.3 当前已知BUG统计

  1. 右侧边栏的 目录组件 (TOC)，在目录很长的时候，如果直接拉到底点击最下面的目录内容，中间的部分条目就不会按照预期进行渲染，排查了好多地方愣是没找到锅在谁头上，好烦啊！

  2. 移动端测试瞎JB点疯狂跳转的时候有概率导致浏览器的 “下滑刷新” （全面屏操作逻辑）失效，只能使用浏览器的手动刷新按钮，暂时不知道是什么导致的…

4.4 废案

  • 当前的顶栏（header布局）始终处于显示状态，我希望在页面开始下拉后，也就是正式阅读文章时，顶栏向上收缩消失，在返回页面顶部时再重新出现。（已放弃）
  • 移动端放置单独的目录栏按钮，可点击收纳？（已经不必要，且桌面端改造过大，屎山代码了已经…）

第五章：各版本设计变迁

网站前端接近完成时，我才决定加入这一部分，所以也就凭借记忆和部分留存下来的截图做一个大概的概括，算是给自己留个念想吧。

4.1 初始版本：

桌面端显示效果

移动端显示效果

最初 Quartz 默认的显示界面，基本上可以说是啥也没有的状态。

但确认了 Quartz 4 理论上实现超高度的定制化之后，那就是大显身手的时候了，Quartz简直就是为我而生的。

Quartz 默认配置甚至没有全局顶栏，就算强行加入之后也只是显示在页面中间栏的上方而已，想要大改布局，就得从零开始对底层文件进行大刀阔斧的重写。

不过相比之下，原作者把真正的后端实现都搞定了，我不过是在巨人的肩膀上小修小补而已，没什么可抱怨的，学！边学边做。

4.2 中间版本：

桌面端显示效果

移动端显示效果

基本布局已经搞定，大的框架已经初步成型，知道了哪里应该放什么，怎么实现就是一步一步去啃的事儿了。

不过还是遇到了极为棘手的问题，那就是移动端适配，在桌面端设想的很好的显示效果，到了移动端几乎都是灾难性的，不只是显示的问题，而是桌面的组件在大多时候都会直接导致移动端出现BUG，最终很多桌面端口的显示代码只能被迫重写，以便一开始就考虑兼容性问题。

好在当年平面设计的经验算是起到了部分避坑的作用，那就是 不要过早的考虑颜值问题，不然无用功少不了。

这个阶段，无整体背景，也无单独的首页卡片，但这些部分是早早就规划了的，最终一定要实现。

4.3 当前版本：

桌面端显示效果

移动端显示效果

布局、整体配色方案、动态流动背景、视觉引导、卡片功能开发、交互微动画、响应式多端适配、文案、未来筹备、发布与调试，每一项都是好几天的琢磨和斤斤计较，每天3-5个小时，边学边做，连续磨了一个多月，肯定还有进一步优化的空间，不过目前已经令自己非常满意了。

越是私人的部分，越要优先满足取悦自己。

这一个月过的，舒服。

本站可随意转载，但请注明出处。 Fusion Atlas © 2026. All Rights Reserved.

关系图谱