腾讯云部署 VitePress 技术站：Node、Docker Nginx 与发布全流程

这篇文章不再只记录“第一步”，而是把这次站点真正落地的完整过程串起来：

• 腾讯云服务器环境确认
• Node.js 安装与路径规划
• Docker 版 Nginx 部署
• VitePress 初始化、构建与发布
• 域名、HTTPS 和后续自动发布应该怎么补
• 为什么最终选择这套方案

如果以后我要继续往站里补前端、爬虫、AI、Go、后端排障这些内容，这套底座也依然能继续用。

先说结论：为什么选这套方案

个人技术站的底座，我最后选择的是：

• Node.js 负责本地和服务器上的构建能力
• VitePress 负责生成静态站点
• Docker + Nginx 负责线上访问和静态文件托管

原因很直接：

1. VitePress 足够轻

我这个站点不是先做复杂社区系统，而是先做“内容沉淀和长期维护”的技术站。

这时最重要的不是功能多，而是：

• 写文章方便
• 构建和发布简单
• 页面足够清晰
• 后续改结构成本低

VitePress 本质上就是把 Markdown 转成静态站点，非常适合这个阶段。

2. Nginx 托管静态站点足够稳

对个人站点来说，VitePress 构建后的产物就是静态文件。

这时用 Nginx 做访问入口有几个明显好处：

• 性能稳定
• 配置简单
• 后续加 HTTPS、反向代理、二级域名都方便

3. Nginx 用 Docker 管理更省心

我没有选择把 Nginx 直接装到系统目录里，而是放进 Docker。

这样做的好处是：

• 配置和站点目录都能挂载到宿主机
• 迁移和重建更方便
• 不容易把系统环境改乱
• 以后升级、回滚更简单

4. Node 单独安装，方便构建

VitePress 本身还是 Node 生态工具，所以构建端离不开 Node。

我把 Node 独立安装到：

/mydata/node

这样做主要是为了：

• 路径清晰
• 后续升级更好找
• 和系统默认环境分离一些

本次部署的整体结构

可以把这次结构理解成下面这样：

内容编辑 -> VitePress 构建 -> 生成静态文件 -> Nginx 对外提供访问

落到服务器目录上，大致是：

/mydata/node      Node.js 安装目录
/mydata/vitepress VitePress 项目目录
/mydata/nginx     Nginx 配置、挂载目录、静态站点目录

对外访问链路则是：

浏览器 -> 腾讯云服务器 -> Docker 中的 Nginx -> 静态文件

如果要继续往“真正长期可用”的站点走，后面通常还会多两步：

浏览器 -> 域名 -> HTTPS -> 腾讯云服务器 -> Docker Nginx -> 静态文件

也就是说，这篇文章负责先把“站点搭起来并发布出去”讲清楚，后续再补：

• 域名与 HTTPS
• 自动构建与自动发布

一、先确认服务器环境

在真正部署前，我先做了几件基础确认：

• 能否正常远程登录腾讯云服务器
• 服务器里是否已经有 Docker
• 当前目录规划是否清晰

这一步看起来简单，但很重要。

如果一开始不把目录规划好，后面 Node、Nginx、项目文件、构建产物很容易混在一起。

二、安装 Node.js

这次我把 Node 安装在：

/mydata/node

这样做的目标不是追求花哨，而是为了后续维护时：

• 一眼能找到 Node 装在哪
• 版本升级不至于混乱
• 构建工具路径更统一

Node 这层主要承担的是：

• 安装依赖
• 本地预览
• 构建 VitePress 站点

也就是说，线上访问真正依赖的是 Nginx，但构建这件事仍然离不开 Node。

三、用 Docker 起一个 Nginx

Nginx 我没有直接用系统包安装，而是走了 Docker。

挂载目录统一放到：

/mydata/nginx

这里通常会放三类东西：

• html：最终对外提供访问的静态文件
• conf.d：Nginx 配置
• docker-compose.yml：容器编排配置

这种结构的好处是：

• 配置和数据都落在宿主机
• 容器删了也不影响站点文件
• 下次迁移服务器时非常直观

四、初始化 VitePress 项目

项目目录统一放在：

/mydata/vitepress

我选择把项目单独放一个目录，而不是散落在 Nginx 目录里，是因为它们本来就是两层职责：

• /mydata/vitepress 负责“源代码和内容”
• /mydata/nginx/html 负责“最终发布产物”

这样以后无论是改主题、加文章、重构导航，还是重新构建发布，都更清晰。

五、构建与发布流程

这次真正的发布思路其实很简单：

1. 在项目目录构建 VitePress

cd /mydata/vitepress
npm run docs:build

2. 把构建结果复制到 Nginx 挂载目录

cp -a /mydata/vitepress/docs/.vitepress/dist/. /mydata/nginx/html/

3. 由 Docker 中的 Nginx 对外提供访问

也就是说：

• VitePress 负责生成页面
• Nginx 负责把页面发出去

如果只是第一次理解流程，这样看已经够了。

但从真正长期维护的角度，我更推荐把“发布上线”固定成一套可重复的动作。

4. 更适合长期维护的上线方式

这次实际上线时，我更倾向下面这套流程：

# 1. 本地重新构建
cd /Users/wss/Documents/New\ project/vitepress-work
npm run docs:build

# 2. 先在服务器备份当前站点
ssh tencent-cvm 'ts=$(date +%Y%m%d-%H%M%S) && mkdir -p /mydata/nginx/backups/$ts && cp -a /mydata/nginx/html/. /mydata/nginx/backups/$ts/'

# 3. 用 rsync 覆盖到线上
rsync -av --delete "/Users/wss/Documents/New project/vitepress-work/docs/.vitepress/dist/" tencent-cvm:/mydata/nginx/html/

# 4. 在服务器本机校验页面
ssh tencent-cvm 'curl -I http://127.0.0.1/'
ssh tencent-cvm 'curl -I http://127.0.0.1/bigdata/'
ssh tencent-cvm 'curl -I http://127.0.0.1/posts/production-nginx-502-troubleshooting'

这一套比单纯 cp 更适合日常发布，原因有三个：

• 有备份，回滚更安心
• rsync --delete 能让线上目录和本地构建产物保持一致
• 发布完立刻 curl 校验，不容易把问题留到浏览器里才发现

5. 为什么这次没有强依赖重启 Nginx 容器

这是因为当前 Nginx 是通过 Docker 挂载宿主机目录的方式运行：

• 宿主机目录是 /mydata/nginx/html
• 容器内目录是 /usr/share/nginx/html

静态文件一旦同步到宿主机挂载目录，Nginx 通常就能直接读取到最新文件。

也就是说，大多数情况下：

• 更新静态文件即可生效
• 不需要每次上线都重启容器

这也是我为什么更喜欢 VitePress + Docker Nginx 这套组合的原因之一：发布动作足够轻。

六、这套方案为什么适合个人技术站

如果现在就做博客、后台、社区、评论、登录系统，全都一口气上，当然也不是不行，但会明显增加复杂度。

我这次更想要的是一套：

• 能快速上线
• 能持续写内容
• 结构能慢慢演化
• 后期还能扩展

的底座。

而 Node + VitePress + Docker Nginx 恰好满足这个阶段的需求：

• 比传统动态博客更轻
• 比一次性做全栈社区系统更容易起步
• 比只在本地写笔记更适合长期沉淀

七、域名和 HTTPS 为什么建议尽快补上

只用服务器 IP 访问，确实已经算“上线了”。

但如果你准备把它长期当成个人技术站来维护，最好尽快补下面这两件事：

• 自定义域名
• HTTPS

原因很现实：

• 浏览器访问体验更完整
• 后续接统计、搜索、第三方回调更方便
• 文章分享出去也更像一个正式站点

对当前这套 Docker Nginx + VitePress 结构来说，这一步并不会明显增加复杂度，因为静态文件托管方式本身没有变，补的是：

• 域名解析
• 80 到 443 的跳转
• 证书申请与自动续期

如果你现在正准备做这一步，可以直接继续看：

• Nginx 配 HTTPS 与域名接入：个人站点从可访问到更适合长期使用

八、自动发布为什么值得单独补

如果每次更新文章都靠手工 build + rsync，短期当然能用，但时间一长会遇到几个问题：

• 容易漏备份
• 容易同步错目录
• 发布后忘了做校验

更适合长期维护的方式，是把下面这条链路固定下来：

提交内容 -> 自动构建 -> 自动同步到服务器 -> 自动做基础校验

这样做的价值不是“显得更专业”，而是能把日常维护动作做成稳定重复的流程。

如果你后面准备把站点发布自动化，可以继续看：

• GitHub Actions 自动发布 VitePress：适合个人博客的轻量 CI/CD 方案

九、这套方案的边界

这套方案也不是万能的。

它更适合：

• 技术站
• 文档站
• 个人博客
• 知识库

如果后面你要做：

• 评论系统
• 用户体系
• 公众号联动后台
• 小程序内容管理

那后续大概率还要继续往下补服务端和后台能力。

但作为第一阶段底座，它已经非常够用了。

十、这次部署之后，后面还能怎么扩

这次把底座跑起来之后，后续就可以继续往里叠能力：

• 继续优化首页和分类导航
• 增加更多技术方向内容
• 补 HTTPS 和自定义域名
• 增加搜索和统计
• 接自动化发布
• 后续再接入后台管理

一句话总结

这次部署的重点，不是把个人站做得多复杂，而是先把“写内容、构建、发布、访问”这一整条链路打通。

对一个准备长期维护的技术站来说，Node + VitePress + Docker Nginx 是一套足够轻、足够稳、也足够容易继续扩展的起步方案。