企业官网建设流程全解析

如果你第一眼看到“caveman”这个词，想到的是住在山洞里、穿着兽皮、手里拿着石斧的原始人，那你的直觉没有错，但也不全对。在个人站长的圈子里，“caveman”这几年慢慢成了另一种意思的代名词：用最原始、最笨拙、最不依赖框架的方式，把内容放到网上。它可能是一个纯手工敲出来的HTML页面，可能是一套连JavaScript都没怎么用的极简博客主题，也可能是一个只有几个文件、却能稳定跑好几年的静态站点。我最早碰到叫caveman的项目，是朋友丢给我一个压缩包，里面就一个index.html和一个style.css，当时我还嗤笑了一声，后来看完才知道，这东西虽然土，但真的是把“内容为王”这四个字做到了极致。

这个项目真正吸引我的地方在于，它把网站开发里那些花里胡哨的东西全部剥掉，只留下一个核心：把你要表达的东西，用最快的速度、最稳的方式呈现给访问者。它没有复杂的构建流程，没有几十个node_modules依赖，更没有什么服务端渲染、微前端、容器化那一套。你打开代码，看到的每一行都是自己能看懂的HTML、CSS，甚至不需要任何框架知识就能改。对于厌倦了“框架疲劳”、想回归内容本身的博主、独立开发者、内容创作者来说，caveman这种风格的项目简直是一股清流，它不一定适合做复杂的电商平台，但做个人主页、作品集、文档站、轻量博客，完全是杀鸡用牛刀，而且杀得很稳。

我在过去的项目里试过用caveman的思路重做过一次个人主页，前后花了一个周末，部署完之后几乎没再管过它 — 它就这么稳稳定定地跑着，没有依赖更新要处理，不用每个季度升级一次框架，也不用担心哪天某个底层库删库跑路导致网站白屏。这篇文章我就把这段经历好好拆一遍，说说caveman这种“返祖式”建站方式到底妙在哪里，踩过哪些坑，以及如果你也想搞一个，具体每一步该怎么做。

1. 项目定位与核心思路拆解

1.1 caveman到底是什么：一个快速、扎实、反潮流的内容站点方案

caveman在这里指的是一类项目，而不是某一个具体的软件包。它的核心特征可以用三个词概括：零依赖、纯静态、高可读性。零依赖指的是你不需要安装任何第三方库、框架或者运行环境，一个浏览器能打开文件，它就工作；纯静态意味着整个站点由预生成的HTML、CSS、JS文件组成，服务器只负责把文件原样吐给访问者，没有数据库查询、没有模板渲染、没有接口调用；高可读性则是说代码结构极其透明，一个新手花半小时也能摸清整个站点的脉络。

我自己理解下来，caveman式的建站思路其实是对“网页越来越重、加载越来越慢”这种现象的一种反思。现在随便打开一个内容型网站，动辄几百KB的JavaScript，十几张高清图，还有一堆第三方追踪脚本。用户只是想看一篇文章、找一个联系方式，结果光加载就花了好几秒。caveman这条路反其道而行之，它默认访问者是来“看内容”的，不是来“体验你的前端炫技”的，所以一切设计都以内容快速呈现为最优先级。这样做的好处你实际跑起来才能感受到：页面几乎秒开，服务器成本低到可以忽略，而且你写内容的时候完全不用分心去想“这个组件框架支不支持”。

1.2 这套方案的适用场景与不适合的场景

每个方案都有自己的边界，caveman不是万能的。我目前认为它最适合三类场景。第一类是个人品牌站/作品集，这类站点的特点是内容不多、更新不频繁、但对稳定性和加载速度极其敏感，把自己过往的文章、项目、联系方式挂上去，用最朴素的版式就很有质感。第二类是纯内容博客，尤其是想长期写、又不想花太多精力维护的博客，caveman配上一个Markdown文件就是无敌的组合，写文章时你只需要关心文字本身，发布时跑一条命令或干脆手动复制文件上去就能完事。第三类是项目文档/工具首页，很多开源项目在正式做官网之前，都会先用一个极简的caveman风格站点把文档和基本信息立起来，后面真有需要再升级。

反过来，如果要做在线购物、社区论坛、需要用户注册登录的SaaS产品，那caveman就不合适了 — 它没有后端逻辑，没有数据库支撑，强行套用只会让开发流程变得拧巴。我在实际操作中也反复提醒自己：不要因为喜欢极简风格就把它硬塞给需求复杂的项目。工具选型这件事，永远是需求先行。

1.3 为什么这个思路能长期跑：从协作与维护成本维度看

一个大多数开发者不爱听的大实话是：很多网站的维护成本，有一半以上是框架和依赖链条带来的。今天这个库有安全漏洞要升级，明天那个框架出了新版本大版本号直接不兼容，后天某个npm包作者因为种种原因把包下线了 — 这些跟你的网站内容一毛钱关系都没有，但都会变成你不得不花时间的理由。caveman思路从根本上消灭了这一类麻烦，因为压根就没有依赖，自然也就没有依赖升级这回事。它特别适合十年二十年维度去存续内容，你把文件放在一个简单的Web服务器上，几乎不会遇到技术债要还的日子。

我在维护过程中最深的体会就是“省心”。上次去查看服务器日志，这个大半年没动过的站点还是稳稳地响应着每一个请求，那一刻你会意识到，有时候少即是多，这句话在web世界里同样是真理。

2. 技术方案选型：为什么是纯HTML而非静态站点生成器

2.1 静态站点生成器和手工HTML的边界在哪

说到做静态站点，很多人第一反应是Hugo、Astro、VitePress这类生成器。这些工具确实厉害，Markdown写文章、编译出静态文件，还自动帮你处理好目录、路径和样式。那为什么caveman不直接用它们，而要退回到手工HTML？我的判断基于一个朴素的成本考量：当你的站点只有一两个核心页面、或者文章数量很少时，引入生成器的学习成本和配置成本已经超过手写HTML的重复成本了。举个例子，如果你只想放一个关于页、一个首页、一个博客列表，手写三个页面加上一个公共的CSS文件，总共不过个把小时的事。而用生成器，你得先熟悉目录规范、主题配置、布局语法，前前后后折腾下来一个晚上可能还没满意。反而是caveman这种“笨办法”，小体量时极其高效。

同时也要承认，如果你的文章量很大、动不动上百篇，纯手工维护的麻烦就会体现出来 — 每篇文章要手动写标题、写日期、做目录链接，重复劳动让人崩溃。那么更好用的其实是“半caveman”模式：本地用任何一个你喜欢的生成器产出静态文件，部署出去之后就是纯静态站点，这兼顾了两边的优点。

2.2 选型对比：一张表看清caveman、生成器与动态建站

这里把我实际对比过的几条路线放在一个表里，差别就很直观了：

我自己目前的倾向是“起步用caveman，量变引发质变时再换生成器”。从caveman迁移到生成器并不亏，因为你的内容和设计思路完全可以平迁；反过来如果一开始就用动态建站，那就有种大炮打蚊子的感觉了。

2.3 过程里值得较真的两个小点：语义化HTML与CSS最小化

caveman风格不代表粗糙，恰恰相反，它特别讲究语义化HTML和CSS的精简。语义化指的是用对标签做对的事：导航栏用<nav>，正文用<article>，页脚用<footer>，而不是满屏幕的<div>到底。这样做最直接的好处是SEO和可访问性都会更好，搜索引擎的爬虫和屏幕阅读器都能更容易理解你的页面结构。我在实际写代码时会把每一篇文章的标题都放进<h1>或<h2>的正确层级里，列表就老老实实用<ul>/<ol>，这些细节在页面里看不见，但日积月累对内容传播的助力是实实在在的。

CSS最小化也不是说所有样式越少越好，而是裁掉那些“可有可无”的装饰，保留用于阅读舒适度的排版规则 — 比如行高、最大宽度、字间距、合适的留白。我会刻意不写任何动画和过渡效果，既避免让访问者等动画播完，也让代码变得非常容易审查。后来有人问我为什么你的页面滚动时没有任何滑动效果，我回答：内容的优先级应该高于动效，这句话可能是caveman风格设计最好的注脚。

3. 实操过程：从零到上线一个caveman风格的个人站

3.1 目录结构与基础文件的搭建

动手做之前，我先把整个项目结构规划得很清爽。一个caveman站点最核心的文件就这么几个：

caveman-site/ ├── index.html # 首页/内容入口 ├── about.html # 关于页面 ├── blog.html # 博客/文章列表页 ├── css/ │ └── style.css # 全局样式，一个文件搞定 ├── posts/ │ ├── hello-world.html │ ├── second-post.html │ └── ... └── images/ # 需要配图时才用，能省则省

这样的好处是结构一目了然，即便隔半年再来看，你也能三秒钟找到想改的文件。我强烈建议不要把样式拆成十几个CSS文件，caveman阶段就用一个文件，按区块用注释分隔，比如“/* Header/”、“/Article */”，维护起来反而比多文件更顺手。

3.2 手写首页的细节与文本排版要领

写index.html时，我用的结构大致是这样：顶部是站点名和一句简短的自我介绍，中间是最新文章的列表，底部是联系方式和版权信息。没有侧边栏，没有轮播图，没有弹窗。文字排版上，把正文的最大宽度限制在720px以内，因为人眼的阅读宽度是有限的，太宽了眼睛移动范围大，容易疲劳；字号设为16px到18px之间，行高设为1.6到1.8倍，这是被反复验证过的中文阅读舒适区间。

另外还有一个很不起眼但很重要的点是字体栈。在CSS里我会这样写：font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", "PingFang SC", "Microsoft YaHei", sans-serif;— 这是让不同操作系统的用户看到最适应当地环境的字体，无需加载任何外部字体文件。外部字体虽然好，但会带来额外的网络请求和加载延迟，对caveman风格来说有些亏。

3.3 一套非常轻量的CSS框架写法

整个风格的灵魂其实在style.css里，但别误会，它并没有高深的东西，只是一个克制、舒服的设计规范。我把自己实际用的核心代码放出来，你可以直接用：

:root { --bg: #faf9f6; --fg: #2d2a26; --accent: #8b5a2b; --muted: #777; --max-width: 720px; } * { box-sizing: border-box; } body { margin: 0 auto; max-width: var(--max-width); padding: 2rem 1.25rem 4rem; background: var(--bg); color: var(--fg); font-size: 17px; line-height: 1.7; } a { color: var(--accent); text-decoration: none; border-bottom: 1px solid transparent; } a:hover { border-bottom-color: currentColor; } .post-list { list-style: none; padding: 0; } .post-list li { margin-bottom: 1.25rem; } .post-title { font-size: 1.5rem; font-weight: 700; } .post-meta { color: var(--muted); font-size: 0.875rem; } pre, code { font-family: ui-monospace, SFMono-Regular, Menlo, monospace; font-size: 0.9em; background: #f0ede8; padding: 0.15em 0.4em; border-radius: 4px; } pre { padding: 1rem; overflow-x: auto; line-height: 1.45; }

这段代码里做了几个关键决定：一是用CSS变量定义颜色、宽度，换主题时只需改变量；二是列表去掉了项目符号，让视觉更干净；三是给代码块独有的背景色，确保文章里的技术片段一眼可分辨。整个样式没有使用任何UI框架，全部自己写，而这也意味着你完全清楚每一行样式的用途，不会被框架的默认样式绑架。

3.4 响应式设计：为什么先移动端后桌面端

现在的访问流量里，手机浏览器占比早就超过了桌面端，所以每个caveman站点都必须考虑小屏幕。我的做法是拿一个基准样式先适配手机，然后再用媒体查询修正桌面端。上面那段代码里其实已经天然适配了移动端，因为body { max-width: 720px; margin: 0 auto; padding: 2rem 1.25rem; }在手机上会刚好铺满屏幕，只是两侧留了适度的呼吸空间。

桌面端需要额外处理的场景主要是导航栏和文章里的表格。导航栏我采用最简单的做法：一个<nav>里放了几个链接，在手机上自然换行，桌面端用flex排一行。表格则靠CSS让它在小屏下横向滚动：overflow-x: auto; display: block;，看起来虽不是最优雅，但胜在简单可靠。

3.5 部署上线：从本地文件到公网可访问

caveman项目的部署是我见过的所有建站方式里最省事的，本质上就是把文件放到一台支持静态文件的服务器上。我自己的经验是优先用GitHub Pages，推一次代码，几十秒后网站就更新了，全程零成本。核心操作如下：

1. 建一个仓库，名字取为<你的用户名>.github.io
2. 把项目文件全部推到仓库里
3. 在仓库的Settings页面开启Pages服务，分支选main，根目录就可以
4. 等一两分钟，访问https://<你的用户名>.github.io就能看到页面

如果是自己买服务器，那就更直接，把文件丢到Nginx或者Caddy的网站根目录就行。Nginx一个最简单的server块差不多长这样：

server { listen 80; server_name example.com; root /var/www/caveman-site; index index.html; }

然后nginx -t检查配置，systemctl reload nginx重载服务。没有数据库要接，没有环境变量要填，整个过程快到我头一次部署时还不太敢相信就这么结束了。

4. 内容组织与写作流程设计

4.1 用纯HTML写文章和用Markdown写有什么区别

caveman项目的文章本质上是HTML文件，这意味着你写的是带标签的内容。时间久了、文章多了，你可能会觉得繁琐。我自己实际用的是折中方案：日常写作在本地用Markdown写，遇到代码块、列表时Markdown的表现力也够，等写完了再转成HTML放进posts目录。转换工具很多，我用的是pandoc这个老牌命令行工具，一条命令就能把Markdown文件变成干净的单篇HTML：

pandoc hello-world.md -o posts/hello-world.html

这样做的好处是两头兼顾：写作时不用操心标签，发布后得到的是完全静态、零依赖的HTML文件。文章数量多了之后，你需要维护一个简单的索引页，把最新文章链接放在首页或一个blog.html页面。刚开始可以手动维护，要是嫌麻烦，后续再引入模板生成也来得及。

4.2 一个约定俗成的内容组织标准：按主题而非按日期

写了几个月caveman博客之后，我给自己定了一个规则：每篇文章的文件名用主题关键词而不是日期。比如why-caveman.html、css-tips.html这样的命名，比2026-01-15-post.html更有利。因为文件名会直接反映在URL里，主题关键词对搜索和访客的理解都更友好。日期信息则写进文章内部的<time>标签里，这样两不耽误。

在首页的列表里，我也不会堆太多摘要，只展示标题和发布日期，让访客自己点进去读。这个看似偷懒的设计其实是被数据驱动的 — 我观察过站内的访问行为，首页上的长摘要滚动翻看的概率很低，大家更习惯扫一遍标题，挑感兴趣的打开。与其费心写摘要，不如把功夫放在文章本身。

4.3 图片与资源处理：轻量化是caveman的底线

图片往往是页面体积膨胀的主要来源，caveman风格的站点必须管住图片这张嘴。我在项目中约定，每张配图都要经过压缩后再上传，常见的工具是Squoosh或者命令行里的cwebp。如果需要，尽量减少图片数量，能用文字说清楚的事就不要配一张无信息量的装饰图。封面图如果不是内容必需，我基本不加。

另外，图片的尺寸也要写对。HTML里<img>标签带上width和height属性，就能避免图片加载时页面的跳动，这个细节虽小，但体验提升明显：

<img src="images/caveman-demo.jpg" alt="caveman站点的首页截图" width="800" height="450" loading="lazy">

loading="lazy"表示这个图片会在滚动到附近时才真正加载，对含多图的页面尤其友好。

5. 常见问题与排查技巧实录

5.1 一阵见血的问题速查表

一手实践下来，新手玩caveman最容易栽的跟头就那几个，我整理成了一张表，方便对照排查：

5.2 我踩过的三个坑和对应解法

讲几个我自己真实踩过的坑。第一是部署到GitHub Pages后CSS完全找不到，排查了半天发现仓库里的css文件夹是Css，而HTML里写的是css/style.css。Linux系的服务器文件名大小写敏感，Windows上开发的本地一切正常、线上就崩的情况，多半就是这个原因。从那以后我文件名一律用小写，杜绝这类问题。

第二个坑是换了字体源站却没换。有一次我图省事把外部字体的@import引入了CSS，结果那次外部字体服务的节点因为合规原因不能访问，整个站点的文字差点变成系统默认字体。后来我把所有外部资源都清理干净，只用系统自带字体栈，再也没有类似焦虑。

第三个坑比较隐蔽，我把博客列表页写成了每篇文章都要手动添加一行新链接，结果文章一多，经常忘记更新列表。后来我用一个浏览器里的脚本，定时把posts目录里的文件名抓出来、核diff检查首页有没有遗漏。这个做法虽然土，但很有效。你在手工维护阶段，不妨也给自己的“发布流程”立个检查清单：写完文章、转换HTML、放入目录、更新索引页、推仓库、看一眼线上页面。

5.3 监控与维护心得：让它安静地待在角落

绝大多数caveman站点没有复杂的运行状态需要看，但我仍然会做一些最基本的健康监测。例如配置一个简单的定时任务，每小时用curl去抓一下自己站点的状态码，只要不是200就发一封告警邮件。这样即便无人维护，站点出了问题我也能在几小时内知道。

另外建议每半年对整站做一次备份。caveman项目备份极其容易，就是把整个目录打一个压缩包扔到网盘或另一个git仓库里，一条命令就能搞定：

tar -czf caveman-backup-$(date +%F).tar.gz caveman-site/

这样折腾一轮下来你会发现，维护成本低到几乎可以忽略，但你花在内容本身上的时间反而变多了 — 这在我看来，就是caveman这类项目最值得的地方。

6. 拓展思路：caveman风格的价值不止于建站

6.1 RSS与博客精神：回归内容分发

做caveman站点的过程中，我顺便重新拾回了RSS。以前用动态站点时，RSS插件总是不太稳定，输出格式时不时出问题。现在纯静态页面里我可以手写一个feed.xml，完全掌控其中每一个字段。RSS最大的好处是隐私友好且渠道自主，访客订阅后就自动获得更新，不受社交平台算法干扰。我会在每篇新文章发布后同步更新feed.xml里的条目，然后在首页放一个橙色的RSS链接图标。坚持下来后，我的读者里愿意用RSS阅读器订阅的，反而是粘性最高的一批人。

6.2 从个人站点到产品落地页：同一套思路的迁移

caveman的思路也可以迁移到轻量产品落地页里。给一个小工具或小应用做个官网时，并不需要一上来就搞复杂的首页，一个index.html配上清晰的用户价值描述、使用截图、下载链接和FAQ，就足以支撑早期的转化。等产品真正长大、需求明确了，再去扩展成框架化的前端项目。这种“先用最笨的方式验证”的思路，避免了很多过早优化的问题。

6.3 关于“返祖式建站”的一些个人反思

写到这里，我的感受是caveman并不是技术上的倒退，它在某种程度上是一种提醒：互联网的起点就是内容共享，而内容本身从来不需要厚重的技术栈来衬托。那些能把极简做成高级感的站点，背后其实同样付出了相当大的心思，只不过心思全花在内容和阅读体验上。我个人觉得，如果你是一个长期主义者，打算把某个领域的内容安安静静写十年，caveman这种方案可能是让你走得更远的一种选择 — 它不复杂，但足够扎实，它不需要你频繁为技术操心，让你重新把注意力放回到那些真正值得被创造的东西上。