写文章的过程可以拆成几个很清楚的步骤：记录、整理、预览、构建和发布。把它们分开之后，遇到问题时更容易判断是哪一步出了差错。
先记录，再整理刚开始不需要追求完整。先把问题背景、尝试过的办法和暂时的结论记下来，等思路稳定后再补标题、目录和配图。这样可以避免为了排版而中断思考。
本地预览很重要文章保存后先在本地打开，检查标题层级、代码块、链接和图片。尤其要注意相对路径和中文链接，它们在本地文件系统里正常，不代表部署到正式域名后也一定正确。
发布后再看一遍构建成功只说明文件生成完成。上线后还要从真实域名访问文章，确认样式、 ...
静态站点没有应用进程需要重启，但发布文件时仍然应该保留上一版。这样新版本出现问题时，恢复服务不需要重新构建。
每次发布使用独立目录把每次构建结果放到带有时间和提交号的目录中，当前服务只指向一个固定的 current 软链接。新文件上传完成并通过基本检查后，再切换这个链接。
切换前后各检查一次切换前确认新目录存在首页文件和静态资源，切换后确认 current 指向了正确目录，并从正式域名打开首页和文章页。检查通过后再考虑清理很久以前的版本。
回滚应该足够简单如果发现页面异常，只需要把 current 指回上一版 re ...
这篇文章作为博客重新上线后的第一篇示例内容，记录一下当前站点的基础结构。
为什么选择静态博客个人博客的主要任务是保存文字、图片和代码片段，不需要复杂的后台服务。Hexo 负责把 Markdown 转成静态页面，主题负责页面结构和交互，部署时只需要上传生成后的文件即可。
这种方式的优点是结构简单、运行成本低，也方便把源码放在 GitHub 中长期维护。写文章时专注于 Markdown，发布时再统一生成站点文件。
当前站点的边界现在的博客只做三件事：记录技术实践、整理项目过程、保存生活随笔。首页使用山景首屏，向下滚动后 ...
静态站点看起来只是上传一批 HTML 文件，但真正发布前仍然有几项检查值得固定下来。
先检查内容先在本地生成站点，再搜索首页和文章中的关键文案，确认没有遗留的演示内容、旧域名或不属于当前项目的链接。文章数量、分类名称和导航入口也要和配置保持一致。
再检查构建结果构建完成后，重点看这些路径是否存在：
首页和文章页能否生成
分类、标签和归档页是否有内容
图片、字体和脚本是否都使用正确的绝对路径
不需要展示的页面是否没有被意外生成
最后检查线上切换发布时把文件放进新的版本目录，再通过软链接切换当前版本。这样旧版本仍然 ...
项目记录
未读首页同时承担展示和导航两种任务，布局不能只考虑第一眼的效果，还要让访客顺利找到文章。
第一屏保持简单山景首屏用来建立站点的氛围，因此只放站点名称、简介和导航。文章列表放到下一段，用户向下滚动后就能进入熟悉的 AnZhiYu 阅读布局。
入口要少而清楚首页提供技术、项目和随笔三个分类入口，分别对应不同的内容方向。分类名称和导航中的名称保持一致，减少用户在不同页面之间切换时的理解成本。
内容决定后续调整现在文章数量还在积累，页面需要保持足够的留白。等真实文章变多之后，再根据阅读和查找习惯调整卡片数量、推荐内容和侧栏信息 ...
项目记录
未读这次首页调整的目标很明确：打开网站先看到一张完整的山景图，继续向下滚动后再进入博客内容。
首屏负责留下印象首屏使用固定高度的背景图，把站点名称和一句简介放在画面中央。导航保持轻量，只承担跳转作用，不把文章列表和大量说明文字堆在第一屏里。
山景图本身已经足够安静，所以文字只保留站点名称、定位和向下滚动提示。访问者可以先感受页面，再决定要不要进入文章区域。
下滑后回到阅读首屏之后仍然使用 AnZhiYu 的原生布局：公告区域、技能标签、分类入口、推荐内容、文章列表和右侧信息卡依次展开。这样既保留了 Butterfly ...
项目结束后，我会先回答四个问题：最初想解决什么，最后实际解决了什么，过程中哪一步最费时间，以及下一次会怎么做。
第一个问题用来对照目标，避免把结果写成流水账。第二个问题可以看出范围有没有变化，也能解释为什么有些功能没有加入。第三个问题帮助定位真正的成本，很多时候最花时间的不是编码，而是确认需求和处理边界情况。
最后一个问题则是复盘的价值所在。记录不是为了证明这次做得完美，而是让下一个类似项目少走一点弯路。哪怕只留下几条简短结论，也比项目结束后完全忘记更有用。
一个博客项目最容易出现的问题，不是页面不够漂亮，而是打开之后不知道应该留下什么内容。
先把用途说清楚当前站点定位为项目分享与生活记录。技术笔记用于保存排查过程，项目记录用于整理目标和结果，生活随笔则留下不适合放进前两类的短记录。
有了这三个入口，写文章时就不必每次重新思考栏目。内容可以先写下来，再决定应该归到哪个分类。
只保留真正需要的功能博客暂时不需要相册、评论和复杂的互动功能。功能越少，维护成本越低，也越容易把注意力放回文章本身。等以后确实有内容需要承载，再逐项开启对应模块。
这次整理的结果源码仓库、主题配置和 ...
生活随笔
未读周末腾出一个下午整理电脑，先把桌面上暂时没有用的文件移到对应项目，再给几个容易混淆的目录补上更清楚的名字。
整理过程中会发现很多“以后可能有用”的文件。它们不一定需要马上删除，但应该离开每天都会看到的地方。桌面只保留正在处理的事情，打开电脑时会轻松很多。
整理项目目录也像整理思绪。哪些事情还在进行，哪些已经结束，哪些只是当时的尝试，很快就会变得清楚。剩下的时间用来写下这段记录，刚好给这个下午留一个标记。
项目记录
未读项目混乱时，最先需要整理的地方通常不是代码，而是电脑桌面上的文件夹。
相似名称会制造错误当多个项目目录名字接近时，打开错误文件夹、推送错误仓库或者把配置部署到错误域名都很容易发生。目录名应该直接表达用途，而不是只依赖记忆区分。
我会保留三层信息第一层是项目性质，例如个人博客或展示站；第二层是项目名称；第三层才是具体的源码目录。GitHub 仓库名称、网站域名和本地文件夹最好能够互相对应。
整理不是一次性的每次完成部署或迁移后，都应该顺手更新 README、仓库地址和本地目录说明。几分钟的记录可以避免下次重新花时间确 ...
