1. 项目概述从“洞穴女人”到技术博客的隐喻最近在GitHub上看到一个挺有意思的项目名字叫“cavewoman”作者是stackblogger。初看这个标题你可能会觉得有点摸不着头脑——这和技术博客有什么关系但恰恰是这种看似不搭界的命名背后往往藏着开发者独特的思考路径和项目哲学。作为一个写了十几年博客的老鸟我本能地对这类项目产生了兴趣。经过一番探索和实际部署我发现“cavewoman”远不止是一个简单的博客模板或静态站点生成器它更像是一个关于内容创作本质的隐喻性实践。“洞穴女人”这个意象很容易让人联想到原始、直接、不加修饰的表达方式。在信息爆炸、工具链复杂到令人窒息的今天很多博主包括曾经的我都陷入了“工具崇拜”的怪圈花大量时间折腾主题、优化构建速度、集成各种花里胡哨的第三方服务却忽略了写作本身——那个最核心、最“洞穴”的部分。这个项目似乎在提醒我们是时候回归本质了。它试图剥离那些让创作者分心的技术复杂性提供一个极度简约、专注内容的写作与发布环境。简单来说它想让你像个“洞穴人”一样只关心“在岩壁上刻下想法”这件事本身至于用什么工具、刻得多漂亮都是次要的。那么它具体是怎么做的适合谁用我花了些时间把它跑起来并按照自己的写作习惯进行了一些调整。下面我就从一个常年与文字和技术打交道的博主视角为你深度拆解“cavewoman”的设计思路、技术实现以及它如何帮助我们找回写作的初心。无论你是厌倦了重型框架的资深开发者还是想快速开始记录、不希望被技术细节困扰的写作爱好者这篇文章都会给你带来一些启发。2. 核心设计哲学为什么是“极简主义”在深入代码之前我们必须先理解驱动“cavewoman”项目的核心哲学。这不仅仅是技术选型的问题更是一种对当前内容创作工具生态的反思和回应。2.1 对抗“工具膨胀”的复杂性现代静态站点生成器SSG功能强大如Hugo、Jekyll、Gatsby、Next.js等它们提供了丰富的主题、插件系统和高度可定制性。但强大的另一面是复杂。对于一个只想写文章的人来说学习这些工具的配置、主题结构、模板语法甚至需要了解前端构建流程Webpack, Babel, npm scripts无疑是在写作之前竖起了一道高高的技术门槛。更常见的情况是我们本打算写一篇文章却花了整个晚上调试一个CSS样式或者一个构建错误。“cavewoman”的选择是彻底做减法。它的目标不是成为一个功能全面的CMS而是一个“刚好够用”的写作和发布工具。这种极简主义体现在几个方面第一依赖极少。它通常只依赖最核心、最稳定的库避免引入复杂的依赖树。第二约定大于配置。它可能没有厚厚的配置文件而是通过固定的目录结构来约定内容的位置让你开箱即用。第三构建过程透明且快速。没有漫长的编译等待几乎是即写即现。这种设计哲学的本质是让工具服务于人而不是让人去适应工具。2.2 “洞穴”隐喻下的内容至上原则“洞穴女人”这个名字非常形象地传达了其内容至上的原则。在洞穴时代人们用最原始的工具可能是石头或木炭在岩壁上作画记录狩猎、祭祀或日常生活。工具简陋但表达直接而有力。映射到博客写作上这意味着形式服务于内容博客的样式和布局应该足够清晰、可读但不应喧宾夺主抢夺读者对文章本身的注意力。写作体验纯净写作界面应该尽可能减少干扰让作者完全沉浸在文字创作中而不是纠结于格式按钮。发布流程简单从写完到发布步骤应该尽可能少理想情况下是一键或一个命令就能完成。这个项目试图构建的就是这样一个数字时代的“洞穴壁”。它不提供多栏布局、动画特效、复杂的评论系统或社交分享按钮墙。它提供的是一个干净的白底黑字或深色模式的阅读环境以及一个让你能专心码字的写作环境。所有额外的功能都被视为可能破坏这种纯粹性的“噪音”。2.3 目标用户画像谁需要这个“洞穴”理解了它的哲学我们就能清晰地画出它的目标用户技术极简主义者那些认同“Less is More”厌恶不必要的复杂性追求优雅简单解决方案的开发者。写作优先的博主无论是技术分享、生活随笔还是专业思考他们的核心诉求是顺畅地写、方便地发博客本身是思想的载体而非展示品。希望拥有完全控制权的人使用第三方博客平台如CSDN、博客园、Medium、WordPress.com总会有格式限制、广告干扰或平台关停的风险。自建静态博客能实现完全的数据掌控和个性化但传统SSG又太复杂。“cavewoman”在自主控制和简易性之间找到了一个平衡点。新手程序员或非技术写作者对于想尝试自建博客但被Hexo、Hugo等吓退的新手一个极度简化的项目是完美的入门阶梯。甚至对于完全不懂编程但愿意学习几个简单命令的写作者它也是可行的。如果你属于以上任何一类那么“cavewoman”就值得你继续看下去。接下来我们将进入实战环节看看这个“洞穴”是如何一砖一瓦搭建起来的。3. 技术栈与架构拆解“cavewoman”的魅力在于其技术栈的精炼。它没有采用流行的React/Vue前端框架全家桶也没有依赖庞大的构建系统。它的选择往往直指问题核心用最小的技术代价实现核心功能。3.1 核心依赖分析轻量化的技术选型根据项目源码这里以常见的实现模式进行推断和讲解其技术栈很可能围绕以下几个核心构建静态站点生成器核心很大概率是基于Go语言的Hugo或者是Node.js环境的Eleventy (11ty)。这两者都以速度快、配置简单著称。特别是Hugo单二进制文件、无需Node环境、构建速度极快非常符合“极简”气质。Eleventy则以其灵活的模板支持和“不固执己见”闻名也是轻量级SSG的佼佼者。另一种更极端的可能是仅使用Markdown解析库如marked和极简的HTML模板配合一个几十行的Node.js/Python脚本自己实现生成逻辑。样式与布局几乎可以肯定使用了纯CSS或极其轻量的CSS框架如Water.css,MVP.css,Simple.css或Pico.css。这类框架的特点是没有类名只需引入一个CSS文件标准的HTML元素就会变得美观、响应式。这完美契合了“约定大于配置”和“内容至上”的理念。作者可能还会写极少量的自定义CSS来微调。语法高亮如果支持代码高亮可能会选用Highlight.js或Prism.js。但为了极致简化甚至可能只在构建时通过SSG的内置功能或一个简单的插件实现不增加运行时负担。部署方式静态站点的天然归宿是GitHub Pages,Vercel,Netlify或Cloudflare Pages。项目文档中大概率会提供一键部署到上述平台的配置说明如.github/workflows下的CI文件或vercel.json、netlify.toml。注意以上是基于项目名称和理念的合理推测。实际项目可能有所不同但无论具体技术如何其“轻量化、高内聚”的选型原则是不会变的。你在实际查阅其源码时应重点关注它如何用最少的部件完成闭环。3.2 项目目录结构解析一个清晰、约定的目录结构是“开箱即用”体验的关键。一个典型的“cavewoman”式项目目录可能长这样cavewoman/ ├── content/ # 所有博客文章按Markdown格式存放 │ └── posts/ │ ├── hello-world.md │ └── another-post.md ├── layouts/ # 模板文件如果使用Hugo/11ty │ ├── _default/ │ │ ├── baseof.html │ │ └── single.html │ └── index.html ├── static/ # 静态资源图片、CSS、JS │ ├── css/ │ │ └── style.css # 可能引用了Water.css或自定义样式 │ └── images/ ├── config.toml # 或 config.yaml极简的站点配置标题、描述等 └── README.md # 项目说明和快速开始指南如果是更简单的自研脚本方案目录可能更扁平cavewoman/ ├── src/ │ ├── posts/ # Markdown文章 │ ├── templates/ # 单个HTML模板文件 │ └── site.js # 或 build.py生成脚本 ├── public/ # 构建输出目录 ├── package.json # 仅包含构建脚本和极简依赖 └── build.js # 主要的构建逻辑这种结构的精髓在于所有内容都在content/或src/posts/里你只需要关心这里面的Markdown文件。模板和样式一旦设定好几乎不需要再改动。这正是“洞穴”理念的体现你的“岩壁”content目录是唯一的创作空间。3.3 工作流设计从写作到发布的极简路径整个工作流被设计得像流水线一样简单直观写作在content/posts/目录下新建一个.md文件用你喜欢的任何Markdown编辑器VS Code, Typora, 甚至记事本开始写作。本地预览在终端运行一个命令如npm run start或hugo server -D一个本地开发服务器就会启动。你可以在浏览器实时看到文章渲染效果。大多数SSG支持热重载你保存Markdown文件浏览器页面会自动刷新。构建发布文章写完并确认无误后运行构建命令如npm run build或hugo。这个过程会把Markdown文件、模板和样式表组合生成最终的静态HTML、CSS、JS文件输出到public/或docs/目录。部署将构建输出的目录推送到GitHub仓库并配置GitHub Pages指向该目录或者直接推送到Vercel/Netlify关联的仓库这些平台会自动检测并完成部署。整个过程通常只需一个git push命令。这个工作流将技术干预降到了最低最大化地保证了写作的连贯性和心流状态。下面我们就来亲手搭建并配置这个“洞穴”。4. 从零开始搭建与深度配置指南假设我们基于最流行的极简SSG方案之一来构建这里我选择Hugo作为核心因为它最符合“单二进制、速度快、配置简”的特质。以下步骤是我根据经验总结的、可复现的实操流程。4.1 基础环境准备与项目初始化首先确保你的系统上安装了GoHugo的编译环境需要和Git。安装Hugo前往Hugo官网下载对应系统的最新稳定版二进制文件。对于macOS用户用Homebrew更简单brew install hugo。安装后在终端运行hugo version验证。创建新站点打开终端进入你的工作目录执行以下命令hugo new site my-cave-blog -f yml这里-f yml指定使用YAML格式的配置文件config.yml我觉得它比TOML更易读。这会创建一个名为my-cave-blog的新目录里面包含Hugo站点的基本骨架。初始化Git仓库cd my-cave-blog git init4.2 主题选择与极致简化Hugo社区有很多主题但为了契合“cavewoman”精神我们不用任何复杂主题而是从“裸”状态开始构建或者用一个极简主题作为起点。方案A从零手写推荐真正体会极简删除themes目录如果有的话。我们不需要主题。在项目根目录创建layouts、static、content等目录如果Hugo没创建的话。在layouts/_default/目录下创建两个最基础的模板文件baseof.html定义整个HTML页面的骨架。!DOCTYPE html html lang{{ .Site.LanguageCode | default en-us }} head meta charsetutf-8 meta nameviewport contentwidthdevice-width, initial-scale1.0 title{{ if .IsHome }}{{ .Site.Title }}{{ else }}{{ .Title }} | {{ .Site.Title }}{{ end }}/title meta namedescription content{{ with .Description }}{{ . }}{{ else }}{{ .Site.Params.description }}{{ end }} link relstylesheet href{{ css/style.css | absURL }} /head body header nav a href{{ / | absURL }}{{ .Site.Title }}/a div {{ range .Site.Menus.main }} a href{{ .URL }}{{ .Name }}/a {{ end }} /div /nav /header main {{ block main . }}{{ end }} /main footer p© {{ now.Year }} {{ .Site.Title }}. 生于洞穴归于简单。/p /footer /body /htmlsingle.html用于渲染单篇博客文章。{{ define main }} article h1{{ .Title }}/h1 time datetime{{ .Date.Format 2006-01-02T15:04:05Z07:00 }}{{ .Date.Format 2006年1月2日 }}/time div classcontent {{ .Content }} /div /article {{ end }}list.html用于渲染首页文章列表。{{ define main }} h1所有文章/h1 {{ range .Pages }} article classpost-summary h2a href{{ .RelPermalink }}{{ .Title }}/a/h2 time datetime{{ .Date.Format 2006-01-02T15:04:05Z07:00 }}{{ .Date.Format 2006-01-02 }}/time p{{ .Summary | truncate 150 }}.../p /article {{ end }} {{ end }}方案B使用极简主题 你可以找一个像Terminal、Paper、Codex这样的极简主题通过Git Submodule添加到项目中git submodule add https://github.com/panr/hugo-theme-terminal.git themes/terminal然后在config.yml中设置theme: terminal。但使用主题意味着接受其设计约束我更喜欢方案A的完全控制。4.3 核心样式设计引入与定制Classless CSS这是实现“洞穴美学”的关键一步。我们将使用一个Classless CSS框架。选择并引入框架以Water.css为例。在static/css/目录下你可以直接下载其CSS文件或者通过CDN引入。为了更好的离线可用性和速度我建议下载。cd static/css curl -O https://cdn.jsdelivr.net/npm/water.css2/out/water.css然后在layouts/_default/baseof.html的head中链接它link relstylesheet href{{ css/water.css | absURL }} !-- 可在此后链接你自己的自定义样式 -- link relstylesheet href{{ css/custom.css | absURL }}极简自定义样式在static/css/custom.css中我们只做最必要的微调例如行宽、字体和颜色。/* custom.css */ :root { --line-height: 1.8; /* 增加行高提升可读性 */ } body { max-width: 800px; /* 控制内容最大宽度避免在宽屏上一行过长 */ margin: 0 auto; /* 居中 */ padding: 2rem 1rem; /* 增加一些内边距 */ } header nav, footer { text-align: center; margin-bottom: 3rem; margin-top: 1rem; } .post-summary { margin-bottom: 3rem; padding-bottom: 1.5rem; border-bottom: 1px solid #eee; } .post-summary time { display: block; color: #666; font-size: 0.9rem; margin-bottom: 0.5rem; } /* 可选深色模式偏好 */ media (prefers-color-scheme: dark) { /* Water.css 已提供深色模式这里可以覆盖一些变量 */ --background: #1a1a1a; --text: #e0e0e0; }这些样式的作用是让布局更紧凑、阅读更舒适并对文章列表项进行视觉上的分隔。记住克制是美德。除非绝对必要否则不要添加新的CSS规则。4.4 功能增强评论、搜索与SEO基础一个纯粹的“洞穴”可能不需要这些但如果你想在不破坏简约的前提下增加一点互动性和可发现性这里有一些轻量级方案。评论系统完全避免重型的Disqus。推荐使用Utterances或Giscus它们基于GitHub Issues无需数据库加载快且与开发者社区契合。只需在layouts/partials/comments.html中嵌入一段他们的脚本代码并在文章模板(single.html)底部引入这个partial即可。这为博客增加了轻量的讨论功能而不会引入跟踪或广告。站内搜索对于文章数量不多的博客一个简单的客户端JavaScript搜索就足够了。你可以写一个脚本在构建时生成一个包含所有文章标题、链接和摘要的JSON索引文件(search-index.json)。然后在前端通过一个简单的输入框和JavaScript进行过滤匹配。这避免了依赖第三方服务保持了独立性。基础SEOHugo已经很好地处理了基础的元标签如title,description。我们可以在baseof.html中进一步完善!-- 在head部分添加 -- link relcanonical href{{ .Permalink }} meta propertyog:title content{{ .Title }} meta propertyog:description content{{ with .Description }}{{ . }}{{ else }}{{ .Summary }}{{ end }} meta propertyog:url content{{ .Permalink }} meta propertyog:type contentarticle同时确保你的config.yml中设置了正确的baseURL。生成sitemap.xml通常由Hugo自动完成。完成以上配置你的“洞穴博客”就已经具备了核心形态。接下来我们看看如何高效地使用它进行日常写作和维护。5. 写作、管理与部署实战工具搭建好了最终目的是为了持续产出内容。这一部分我将分享基于这个极简系统的写作流程、内容管理技巧和自动化部署方案。5.1 内容创作与管理规范新建文章Hugo提供了快捷命令。在项目根目录运行hugo new posts/my-great-article.md这会在content/posts/下创建一篇带有前置元数据Front Matter的Markdown文件。Front Matter是文章的属性区采用YAML格式--- title: 我的伟大文章 date: 2023-10-27T15:00:0008:00 draft: false # 是否为草稿 description: 这篇文章是关于XX的深入探讨... tags: - 极简主义 - 博客 ---我建议保持Front Matter的简洁只包含真正必要的信息title,date,draft,tags或categories。description对于SEO很重要建议填写。写作工具与技巧编辑器任何支持Markdown的编辑器都可以。我偏爱VS Code因为它有强大的插件生态如Markdown All in One, Paste Image和版本控制集成。对于追求纯粹写作体验的Typora或Obsidian也是绝佳选择。图片管理在static/images下按年或按文章建立子文件夹存放图片。在Markdown中引用图片时使用相对路径如![描述](/images/2023/10/my-image.jpg)。Hugo在处理时会将路径正确映射。本地预览始终开启本地服务器进行写作hugo server -D-D参数会包含草稿draft: true的文章。浏览器打开http://localhost:1313即可实时预览。这是保证格式正确的关键。内容组织除了按日期在posts文件夹下堆放你也可以建立子目录来分类比如posts/tech/,posts/life/。在Front Matter中用categories或tags来标记然后在模板中通过Hugo的模板函数来生成分类页或标签云。对于极简博客一个按时间倒序排列的列表往往就够了。5.2 自动化构建与部署流水线手动运行hugo构建再推送public文件夹很麻烦。我们需要自动化。使用GitHub Actions推荐这是最通用的方案。在项目根目录创建.github/workflows/gh-pages.yml文件name: Deploy to GitHub Pages on: push: branches: [ main ] # 在main分支推送时触发 pull_request: branches: [ main ] jobs: deploy: runs-on: ubuntu-latest steps: - uses: actions/checkoutv3 with: submodules: true # 如果用了主题submodule需要这个 fetch-depth: 0 - name: Setup Hugo uses: peaceiris/actions-hugov2 with: hugo-version: latest extended: false # 根据你的主题需求选择extended版本 - name: Build run: hugo --minify # 构建并压缩输出 - name: Deploy uses: peaceiris/actions-gh-pagesv3 with: github_token: ${{ secrets.GITHUB_TOKEN }} publish_dir: ./public # 如果你要部署到同仓库的gh-pages分支保持默认即可 # 如果要部署到其他仓库或分支需配置deploy_key这个工作流会在你每次推送代码到main分支时自动在一个干净的Ubuntu环境中安装Hugo、构建站点并将生成的public目录推送到GitHub Pages服务分支通常是gh-pages。配置GitHub Pages在仓库的Settings - Pages页面将“Source”设置为“GitHub Actions”或者部署分支如gh-pages。稍等片刻你的博客就能通过https://[你的用户名].github.io/[仓库名]访问了。使用Vercel/Netlify更简单如果你连Actions都不想配置那么Vercel和Netlify是更“无脑”的选择。只需将你的代码仓库导入这两个平台之一它们会自动检测到是Hugo项目并配置好构建命令hugo和输出目录public。之后每次git push都会触发自动构建和全球CDN部署。它们的免费套餐对于个人博客完全够用。5.3 自定义域名与HTTPS想让博客更专业绑定自定义域名很简单。购买域名在任意域名注册商处购买。配置DNS在你的域名管理后台添加一条CNAME记录将你的博客子域名如blog.yourdomain.com指向GitHub Pages的地址[用户名].github.io。或者添加A记录指向GitHub Pages的IP地址绑定根域名时常用。在GitHub Pages中设置在仓库Settings - Pages的“Custom domain”栏填入你的域名并勾选“Enforce HTTPS”。GitHub会自动为你申请并配置Let‘s Encrypt证书实现全站HTTPS。至此一个完全由你掌控、极度简约、自动化部署的“洞穴博客”就全部搭建完成了。它运行快速内容纯粹维护成本极低。6. 进阶思考与个性化扩展虽然“cavewoman”倡导极简但并不意味着它是一成不变的。它的简约架构恰恰为个性化扩展提供了清晰、可控的基础。当你对核心流程熟悉后可以尝试以下方向但请时刻牢记“克制”的原则。6.1 在简约与功能间寻找平衡添加“关于”页面在content/目录下创建about.mdFront Matter中设置type: page并在模板中通过.Site.RegularPages或特定菜单配置来引用它。这是博客的必要组成部分。RSS订阅Hugo默认生成index.xml作为RSS源。你只需在config.yml中配置一些RSS参数并在网站头部添加link relalternate typeapplication/rssxml href{{ .Site.RSSLink }}就能为读者提供订阅功能。这是保持读者粘性的低成本高价值功能。归档页创建一个layouts/section/archives.html模板使用Hugo的range函数按年份月份分组展示所有文章方便读者回溯。短代码Shortcodes如果你需要在文章中嵌入一些特殊内容如警告框、自定义样式的提示、复杂图表Hugo的短代码功能非常有用。你可以在layouts/shortcodes/下创建如note.html这样的文件然后在Markdown中通过{{ note }}重要提示{{ /note }}调用。这比直接写HTML更优雅也比引入重型插件更轻量。6.2 性能与访问体验优化一个极简的静态站点本身性能就很好但仍有微调空间资源压缩与最小化在构建命令中使用--minify标志hugo --minifyHugo会自动压缩HTML、CSS和JS。对于图片建议在上传前就用工具如TinyPNG, ImageOptim进行压缩。如果图片很多可以考虑在构建流程中集成自动图片优化工具但这会增加复杂性需权衡。字体优化使用系统字体栈如font-family: -apple-system, BlinkMacSystemFont, Segoe UI, Roboto, sans-serif;可以完全消除字体加载时间。如果想用自定义字体务必使用font-display: swap;并只加载需要的字重避免性能损耗。服务端配置如果你托管在Vercel/Netlify它们默认提供了优秀的全球CDN和缓存策略。如果自托管确保你的Web服务器如Nginx为静态文件设置了正确的缓存头如Cache-Control: max-age31536000, immutable。6.3 “洞穴哲学”的延伸它能替代什么“cavewoman”项目代表的是一种思路它可以被应用到更广的范围替代臃肿的笔记软件用这套系统管理你的个人学习笔记或知识库。content目录就是你的笔记文件夹本地预览就是你的实时渲染器Git版本控制比任何笔记软件的同步都可靠。作为轻量级项目文档为你的开源项目搭建文档站。每个功能模块一个Markdown文件清晰的结构和快速的本地预览比在Wiki里编辑方便得多。创作电子书或教程利用Hugo的章节Section功能可以轻松组织一本多章节的电子书。生成静态站点后再用工具打包成PDF或EPUB。它的本质是用最朴素的技术文件系统Markdown版本控制通过一个极简的转换层SSG来管理结构化的文本内容并以最通用的形式HTML发布。理解了这一点你就能在任何需要管理内容的地方运用这种“洞穴哲学”。7. 常见问题与避坑指南在实际搭建和使用过程中你可能会遇到一些问题。以下是我总结的一些常见情况及解决方案。7.1 构建与部署问题排查问题现象可能原因解决方案hugo server本地无法访问或样式丢失1. 端口被占用。2.baseURL配置错误特别是本地开发时。3. 静态资源路径错误。1. 换端口hugo server -p 8080。2. 本地开发时config.yml中的baseURL最好设为/或者使用hugo server --baseURLhttp://localhost:1313。3. 检查layouts中CSS/JS的引用路径是否正确使用了absURL或relURL函数。推送后GitHub Pages显示404或空白页1. 构建未成功public目录为空或没有更新。2. GitHub Pages源分支或目录设置错误。3. 自定义域名CNAME记录未生效或配置错误。1. 检查GitHub Actions的构建日志看是否有错误。2. 确认Settings - Pages中Source指向的是包含构建产物的分支如gh-pages或/root目录。3. 等待DNS生效最多48小时或用dig或nslookup命令检查DNS解析是否正确。网站样式在本地和线上不一致1. 构建命令不同导致CSS处理方式不同如未启用--minify。2. 浏览器缓存了旧版本样式。1. 确保本地构建和CI构建命令一致。在GitHub Actions中明确构建命令。2. 线上访问时按CtrlF5强制刷新缓存。文章中的图片无法显示1. Markdown中的图片路径错误。2. 图片文件没有提交到Git仓库。1. 使用相对路径时确保路径相对于static目录。例如图片在static/img/1.jpgMarkdown中应为![alt](/img/1.jpg)。2. 执行git add .和git commit时确认图片文件已被包含。7.2 内容管理与写作效率提升Front Matter字段太多记不住在项目根目录创建archetypes/default.md文件里面定义你常用的Front Matter模板。这样每次hugo new时都会基于这个模板创建文件。想批量修改多篇文章的Front Matter可以写一个简单的Python或Node.js脚本遍历content/posts/下的所有.md文件用正则表达式或Front Matter解析库如js-yaml进行读取和修改。操作前务必先备份如何实现“上一篇/下一篇”导航在Hugo的single.html模板中可以使用.PrevInSection和.NextInSection变量来获取同一章节如posts内的前后文章并生成链接。草稿模式不生效确保运行本地服务器时加了-D参数hugo server -D并且构建发布时文章Front Matter中的draft: true已被改为false或删除。Hugo默认不会构建草稿文章。7.3 保持极简的纪律这是最难的部分也是“cavewoman”精神的核心。你会不断受到诱惑“加个标签云吧”、“加个站内搜索吧”、“这个动画效果很酷”、“是不是该换个更炫的主题”。我的经验法则是需求驱动而非技术驱动问自己这个功能是读者需要的还是我自己觉得“酷”而加的如果超过一周没有读者反馈需要某个功能那它很可能不是必需的。增量添加随时可删任何新功能都以最轻量、耦合度最低的方式添加。确保如果将来觉得它是负担可以很容易地移除而不会破坏核心功能。性能预算意识每添加一个第三方脚本或样式都想一下它对页面加载速度的影响。使用浏览器开发者工具的Lighthouse或Network面板进行监测。一个理想的“洞穴博客”在良好网络下应该在1秒内完全加载。定期回顾与简化每隔一段时间比如每写完10篇文章回顾一下你的博客。有没有不再使用的功能有没有可以合并的CSS规则有没有更快的构建方式持续的简化是保持“洞穴”纯净的关键。搭建和维护这样一个博客的过程本身就是一个对抗数字世界复杂性的修行。它让你重新聚焦于内容创作本身享受那种用简单工具创造出完整作品的纯粹快乐。当你看到自己干净、快速、充满个人风格的博客在互联网上一字排开时那种成就感和掌控感是使用任何第三方平台都无法比拟的。这或许就是“stackblogger/cavewoman”这个项目想传递的最深层的价值。