![\"03-c4d827f208a3af55b30b5d77e2af25e5\"](\"https://images.mtfh.cc/2025/10/03-c4d827f208a3af55b30b5d77e2af25e5.png\")
九月份博客版本更新时，升级了 Vuepress 版本导致对 NodeJS 版本要求提高了，为此不得不去升级主机的 NodeJS。曾经提到过把博客的自动编译工作放在容器里执行，文档编译相关的依赖从主机转移到了容器。不同的 Node 版本，使用不同容器即可，不需要在主机中安装多个版本的 NodeJS 或被迫限制在某个固定的版本。
\nact_runner 容器这篇 文章里提到过如何在主机环境中注册 act_runner 并使用 Gitea Actions 自动部署博客，现在需要将这些行为搬到 Docker 容器中完成。
官方帮助文档中包含使用容器注册并运行 act_runner 的方式与方法。可以直接使用 docker 命令运行，也可以使用 Docker Compose。
\n直接使用 docker 运行：
\ndocker run \\\n -v $(pwd)/config.yaml:/config.yaml \\\n -v $(pwd)/data:/data \\\n -v /var/run/docker.sock:/var/run/docker.sock \\\n -e CONFIG_FILE=/config.yaml \\\n -e GITEA_INSTANCE_URL=<instance_url> \\\n -e GITEA_RUNNER_REGISTRATION_TOKEN=<registration_token> \\\n -e GITEA_RUNNER_NAME=<runner_name> \\\n -e GITEA_RUNNER_LABELS=<runner_labels> \\\n --name my_runner \\\n -d gitea/act_runner:nightlyDocker Compose ：
\nversion: \"3.8\"\nservices:\n runner:\n image: gitea/act_runner:nightly\n environment:\n CONFIG_FILE: /config.yaml\n GITEA_INSTANCE_URL: \"${INSTANCE_URL}\"\n GITEA_RUNNER_REGISTRATION_TOKEN: \"${REGISTRATION_TOKEN}\"\n GITEA_RUNNER_NAME: \"${RUNNER_NAME}\"\n GITEA_RUNNER_LABELS: \"${RUNNER_LABELS}\"\n volumes:\n - ./config.yaml:/config.yaml\n - ./data:/data\n - /var/run/docker.sock:/var/run/docker.sockdocker compose up不同于在主机中直接运行 act_runner ，使用容器的方式会将注册与运行动作合并为一步。
\naction-runner-helper 仓库为了方便后续重复部署，把 Docker Compose 部署方式相关文件放到了 Git 仓库里。将文件版本化之后，方便将来审查与问题追溯。
\n# For more details on configuration options, refer to:\n# https://gitea.com/gitea/act_runner/src/branch/main/internal/pkg/config/config.example.yaml\n#\n\nlog:\n level: info\n\nrunner:\n file: .runner\n capacity: 1\n env_file: .env\n timeout: 3h\n shutdown_timeout: 0s\n insecure: false\n fetch_timeout: 5s\n fetch_interval: 2s\n github_mirror: ''\n labels:\n - \"ubuntu-22.04:docker://ubuntu:22.04\"\n - \"node-jod:docker://node:jod-bookworm\"\n\ncache:\n enabled: true\n dir: \"\"\n host: \"\"\n port: 0\n external_server: \"\"\n\ncontainer:\n network: \"\"\n privileged: false\n options: \"--add-host=host.docker.internal:host-gateway\"\n workdir_parent:\n valid_volumes: []\n docker_host: \"\"\n force_pull: true\n force_rebuild: false\n require_docker: false\n docker_timeout: 0s\n\nhost:\n workdir_parent:services:\n act_runner:\n image: gitea/act_runner:nightly\n restart: unless-stopped\n environment:\n CONFIG_FILE: /config.yaml\n GITEA_INSTANCE_URL: \"${INSTANCE_URL}\"\n GITEA_RUNNER_REGISTRATION_TOKEN: \"${REGISTRATION_TOKEN}\"\n GITEA_RUNNER_NAME: \"${RUNNER_NAME}\"\n GITEA_RUNNER_LABELS: \"${RUNNER_LABELS}\"\n volumes:\n - ./config.yaml:/config.yaml\n - ./data:/data\n - /var/run/docker.sock:/var/run/docker.sockINSTANCE_URL=https://gitea.mtfh.cc\nREGISTRATION_TOKEN=<your_registration_token>\nRUNNER_NAME=gitea-runner\nRUNNER_LABELS=linux-amd64:host# 启动容器\n# 修改了配置文件或容器参数等等\ndocker compose up -d\n\n# 结束容器\ndocker compose down最后，完整代码参考 action-runner-helper。
\n\n\n原本让 AI 帮忙写了个脚本，用来辅助用户录入容器注册时所需的参数信息，不过后来发现多余了。
\nDocker Compose 会默认从 .env 文件中读取变量值并赋给 YAML 中对应的变量，并不会读取 SHELL 临时变量。既然能直接从 .env 里获取参数，那直接改 .env 文件就好了，再整个脚本就有点多此一举了。
\n
添加环境测试工作流，检查工具版本问题。主要用于检测 Vuepress 编译时所需要的工具依赖，包括 NodeJS、Yarn 和 Git。
\nname: Check Env\nrun-name: ${{ gitea.actor }}\n\non:\n workflow_dispatch:\n\njobs:\n check-env:\n runs-on: node-jod\n steps:\n - name: Checkout repository\n uses: https://gitea.com/actions/checkout@v4\n\n - name: Check Node.js version\n run: node -v\n\n - name: Check Git version\n run: git --version\n\n - name: Check Yarn version\n run: |\n if ! command -v yarn >/dev/null 2>&1; then\n echo \"Yarn not found, installing...\"\n npm install -g yarn\n fi\n yarn -v这时候如果有缺少依赖或版本不匹配问题，可以提前发现。比如说需要激活新版本的 Yarn。
\n分别执行文档编译工作流与子模块合并工作流
\n添加手动触发工作流的方式；工作流的执行标签使用 node-jod —— 基于 Debian 的 node-22.04 容器；编译文档前激活新版本的 Yarn。
工作流修改后大致内容如下：
\nname: Build Docs\nrun-name: ${{ gitea.actor }}\non:\n push:\n branches:\n - main\n workflow_dispatch:\n\njobs:\n Build-Docs-and-Deploy-It:\n runs-on: node-jod\n steps:\n - name: Check out code\n uses: https://gitea.com/actions/checkout@v4\n with:\n fetch-depth: 0\n ssh-key: ${{ secrets.DEPLOYKEY }}\n ssh-known-hosts: ${{secrets.SSH_KNOWN_HOSTS}}\n submodules: true\n\n - name: Setup and build docs # 两次 Build 是为了生成文章分类信息\n run: |\n corepack enable\n yarn install\n yarn docs:build\n yarn docs:build自动更新子模块方面，相对于之前版本单独初始化子模块，这里在检出仓库时连带子仓库一并初始化了——能借助 actions/checkout@v4 自动设置认证信息。
name: Sync Submodules \nrun-name: ${{ gitea.actor }} \n \non: \n workflow_dispatch: \n \njobs: \n update-submodules: \n runs-on: node-jod \n steps: \n - name: Checkout repo \n uses: https://gitea.com/actions/checkout@v4 \n with: \n ssh-key: ${{ secrets.DEPLOYKEY }} \n ssh-known-hosts: ${{ secrets.SSH_KNOWN_HOSTS }} \n submodules: recursive \n \n - name: Update submodules \n run: | # 拉取子模块主分支后，再合并 \n git -C src/posts fetch origin main \n git -C src/posts checkout main \n \n - name: Commit update \n run: | \n git config user.name \"${{ vars.USER_NAME }}\" \n git config user.email \"${{ vars.USER_EMAIL }}\" \n git add . \n if ! git diff --cached --quiet; then \n git commit -m \"$(git -C src/posts log -1 --pretty=format:\"%s\")\" \n git push origin HEAD \n else \n echo \"No submodule updates\" \n fi如果不添加文件映射的话，容器内的文件是没法直接拷贝到宿主机的。解决这一问题的方式有很多。可以添加目录映射（逻辑卷）；上传文档，再使用上传的文档创建一个 Web 容器，然后让 Nginx 作反向代理；还可以使用 SCP 发送文件到宿主机。
\n\n\n当前博客的部署方式是结合 Nginx 一起考虑的。博客项目包含文章的编辑与发布，博客本身的改版，最后统一输出的是一组静态文件——即项目目录
\n./src/.vuepress/dist里的内容。至此「软件」的开发部分完成了，下面讨论部署与分发。因为「博客软件」是网页应用的形式呈现的，部署成功也就完成了应用的分发。
\nNginx 把网站发布出去的步骤包括但不限于 Nginx 配置、域名配置和防火墙配置等。
\n
其实 Github 有现成的 Actions 插件，不过由于某些因素下载不了或者特别慢。就只能让 AI 帮我生成一段配置了。
\nname: Build Docs\nrun-name: ${{ gitea.actor }}\non:\n push:\n branches:\n - main\n workflow_dispatch:\n\njobs:\n Build-Docs-and-Deploy-It:\n runs-on: node-jod\n steps:\n\t # 省略的步骤\n\t \n - name: Install sshpass (with CN mirror)\n run: |\n sed -i 's/deb.debian.org/mirrors.ustc.edu.cn/g' /etc/apt/sources.list.d/debian.sources\n apt-get update && apt-get install -y sshpass\n\n - name: Deploy via scp (password)\n run: |\n ssh-keyscan -H ${{ secrets.HOST }} >> ~/.ssh/known_hosts\n sshpass -p \"${{ secrets.PASSWORD }}\" scp \\\n -o StrictHostKeyChecking=no \\\n -r ./src/.vuepress/dist/* \\\n ${{ secrets.USERNAME }}@${{ secrets.HOST }}:/var/www/html由于 SCP 拷贝文件需要远程主机的地址，所以在运行 act_runner 容器时，配置文件里需要有以下配置，来保证执行工作流的容器能够访问宿主机，而不是 act_runner 容器。
\ncontainer:\n\toptions: \"--add-host=host.docker.internal:host-gateway\"另外在 Gitea 仓库配置中添加上相应的变量，secrets.HOST 变量值使用 host.docker.internal 即可。
博客代码仓库与文章仓库是两个独立的版本仓库，博客仓库通过子模块的方式来引用文章仓库。把博客的代码（Vuepress）和文章放一起，会更简单——不用折腾 @vuepress/plugin-git 问题，也不需要推送子仓库之后再去更新主仓库。
但是个人习惯上，还是倾向于将应用与数据分离开来。更新文章即关注博文的编辑与发布；而功能或 UI 上的改进即为博客版本的迭代。二者之间不具有强关联性——如果想换一个博客框架的话，只要保证新框架具有相似的功能集（Markdown 文件的静态编译功能）就好了，没有的话也可以自己开发；可能的话，网友替换掉子模块后，便能得到一个文章内容不同克隆体。
\n子仓库的自动同步功能是由 Webhook 结合 Gitea Actions 协作来完成的。子模块推送更新后，触发子仓库 Webhook ，主仓收到 Webhook 请求后执行更新子仓库的工作流——模块的更新、合并和提交等操作，完成主仓库的同步更新。
\nGitea 默认具有 Webhook 支持，除了和自身集成，还支持飞书、钉钉和企业微信等应用。要想通过 Webhoook 启动工作流，需要 /repos/{owner}/{repo}/actions/workflows/{workflow_id}/dispatches 这个接口的支持。
博客仓库（vuepress-starter）切换到 dev 分支，在项目录下的 .gitea 目录里添加 update-submodules.yml 文件， 内容如下：
\n\n默认主分支（
\nmain）写保护，主分支不直接用来做提交和推送。最终的提交经由其他分支开发并测试好之后，再合并或者变基过去。
name: Sync Submodules \nrun-name: ${{ gitea.actor }} \n \non: \n workflow_dispatch: \n \njobs: \n update-submodules: \n runs-on: nas \n steps: \n - name: Checkout main repo \n uses: https://gitea.com/actions/checkout@v4 \n with: \n ssh-key: ${{ secrets.DEPLOYKEY }} \n ssh-known-hosts: ${{ secrets.SSH_KNOWN_HOSTS }}\n \n - name: Update submodules \n run: | \n git submodule update --init --remote --merge \n \n - name: Commit updated submodules \n run: | \n git config user.name \"${{ USER_NAME }}\" \n git config user.email \"${{ USER_EMAIL }}\" \n git add . \n if ! git diff --cached --quiet; then \n git commit -m \"$(git -C src/posts log -1 --pretty=format:\"%s\")\" \n git push origin HEAD:dev \n else \n echo \"No submodule updates\" \n fi工作流功能便是合并子模块的最新提交，提交信息使用的是子模块最新的提交信息。
\n重点关注工作流的触发方式，这里使用的是 workflow_dispatch 。该方式可以在仓库网页里的工作流标签中手动触发，也可以使用接口来触发，Webhook 采用的便是后者。
最后添加 update-submodules.yml 文件到 Git 仓库，提交并推送到 Gitea。
接口密钥用于 Webhook 发送工作流触发请求；部署密钥用于授权工作流对博客和文章仓库的拉取和推送操作。
\n依次选择：设置 => 应用 => 管理 Access Token 。然后，生成一个 Gitea API 访问令牌。
\n![\"03-1fa3dd61bd14b955b457f714c62249e9\"](\"https://images.mtfh.cc/2025/10/03-1fa3dd61bd14b955b457f714c62249e9.png\")
生成的密钥字段保存好，后面配置 Webhook 时会用到。
\n![\"03-c7f67fc9e7fbe22d35bf442535dc3937\"](\"https://images.mtfh.cc/2025/10/03-c7f67fc9e7fbe22d35bf442535dc3937.png\")
使用 ssh-keygen 创建密钥
# -f 后面是文件名称，如果没有该参数，将默认生成到 $HOME/.ssh\n# 添加这个是为了更改默认生成的位置\n# -C 为备注内容，会被添加到公钥末尾\nssh-keygen -t ed25519 -C \"deploy@mtfh.cc\" -f id_ed25519![\"03-4ee81b0e844b60abdf7fb350ce03411c\"](\"https://images.mtfh.cc/2025/10/03-4ee81b0e844b60abdf7fb350ce03411c.png\")
为 Gitea Actions 添加密钥和为仓库添加部署密钥参考创建 Gitea Actions ｜Vuepress 自动化部署（基于 Gitea Actions）
\n前往仓库设置 => Web 钩子 => 添加 Web 钩子 => Gitea
\n![\"03-d09adf079bc850a5ab5294baf64e7ce6\"](\"https://images.mtfh.cc/2025/10/03-d09adf079bc850a5ab5294baf64e7ce6.png\")
填写接口地址，设置接口访问密钥等一系列参数设置
\n![\"03-a9f244825455de1d65dc6fdf80db04b1\"](\"https://images.mtfh.cc/2025/10/03-a9f244825455de1d65dc6fdf80db04b1.png\")
模拟发送请求，应该发送失败——前面添加的工作流并不在 main 分支中。
默认的 Webhook 推送只能触发主分支的工作流，但测试只能使用 dev 分支或其他。这样一来在正式发布前，就无法进行基础的流程测试了。
\n一个比较笨的方法就是本地镜像一个 Gitea 服务，使用镜像的主分支测试。因为曾经做过 Gitea 备份，想要本地镜像一个很简单，甚至之前做测试时有一个现成的。
\n另一种方式是，单步验证——分别验证 Action 触发情况和 Webhook 的发送情况。
\n\n\n单步验证的方式，可以规避人为的粗心大意导致的问题。比如
\nupdate-submodules.yml便是在多次执行验证之后得到的结果。
配置好 Webhook 后，除了测试推送外，随意修改点内容推送到 Gitea 就可以看到，Webhook 发送记录。
\n由于默认的 Webhook 只能触发主分支工作流，因此想要验证工作流正确与否，就需要手动构造并发送 Webhook 请求。
\ncurl 命令发送请求示例：
\ncurl -X POST\n\t -H \"Content-Type: application/json\"\n\t -H \"Authorization: token <your api token>\" \\\n https://<your domain>/api/v1/repos/<username>/<repo>/actions/workflows/<workflow id>/dispatches\n -d '{\"ref\": \"dev\"}'除了使用 curl 命令外，还可以使用 Postman 、Apiforx 等图形化工具。Apifox 以项目的角度管理接口，除了设计接口，还可以通过多种方式导入接口。将 Gitea 的接口导入进来，测试和查找接口就比较方便了。
![\"03-3f3a45d1117d8d8dc872b1867ba002ee\"](\"https://images.mtfh.cc/2025/10/03-3f3a45d1117d8d8dc872b1867ba002ee.png\")
![\"03-a5004f8bd8b9d8e7ce88f373413630c9\"](\"https://images.mtfh.cc/2025/10/03-a5004f8bd8b9d8e7ce88f373413630c9.png\")
![\"03-894c2fcaaf3076f61d61b60373b00d65\"](\"https://images.mtfh.cc/2025/10/03-894c2fcaaf3076f61d61b60373b00d65.png\")
观察前面的工作流文件，可以看到，我是通过以下命令获取子仓库的最新提交信息的：
\ngit -C src/posts log -1 --pretty=format:\"%s\"最初的思路并不打算使用命令的方式来获取子仓库的提交信息，因为 Webhook 的推送数据中包含相关信息，请求体样本如下：
\n{\n \"ref\": \"refs/heads/dev\",\n \"before\": \"c07cc3900253bb43a682cc4ed354c225ed472867\",\n \"after\": \"2518d11a6ef532597e4490aec36f1c3570d0aa7d\",\n \"compare_url\": \"https://gitea.mtfh.cc/mtfhx/blog-posts/compare/c07cc3900253bb43a682cc4ed354c225ed472867...2518d11a6ef532597e4490aec36f1c3570d0aa7d\",\n \"commits\": [\n {\n \"id\": \"2518d11a6ef532597e4490aec36f1c3570d0aa7d\",\n \"message\": \"Posts: 2025-09-21 11:11:48\\n\",\n \"url\": \"https://gitea.mtfh.cc/mtfhx/blog-posts/commit/2518d11a6ef532597e4490aec36f1c3570d0aa7d\",\n \"author\": {\n \"name\": \"Happilys\",\n \"email\": \"happilys_mtfh@sina.com\",\n \"username\": \"mtfhx\"\n },\n \"committer\": {\n \"name\": \"Happilys\",\n \"email\": \"happilys_mtfh@sina.com\",\n \"username\": \"mtfhx\"\n },\n \"verification\": null,\n \"timestamp\": \"2025-09-21T11:11:48+08:00\",\n \"added\": [],\n \"removed\": [],\n \"modified\": [\n \".obsidian/core-plugins.json\",\n \".obsidian/workspace.json\"\n ]\n }\n ],\n \"total_commits\": 1,\n \"head_commit\": {\n \"id\": \"2518d11a6ef532597e4490aec36f1c3570d0aa7d\",\n \"message\": \"Posts: 2025-09-21 11:11:48\\n\",\n \"url\": \"https://gitea.mtfh.cc/mtfhx/blog-posts/commit/2518d11a6ef532597e4490aec36f1c3570d0aa7d\",\n \"author\": {\n \"name\": \"Happilys\",\n \"email\": \"happilys_mtfh@sina.com\",\n \"username\": \"mtfhx\"\n },\n \"committer\": {\n \"name\": \"Happilys\",\n \"email\": \"happilys_mtfh@sina.com\",\n \"username\": \"mtfhx\"\n },\n \"verification\": null,\n \"timestamp\": \"2025-09-21T11:11:48+08:00\",\n \"added\": [],\n \"removed\": [],\n \"modified\": [\n \".obsidian/core-plugins.json\",\n \".obsidian/workspace.json\"\n ]\n },\n \n // 以下内容省略\n}经过一番尝试后——使用 toJSON(github.event) 打印出 github.events 对象，发现没有提交信息相关内容，也就宣告这种方式在当前的 Gitea 版本（1.24.5）中不适用。
（问 AI）调研一番后，才决定使用命令来获取提交信息。
\n\n尝试后，给我一种与下面例子类似的感觉。
\n卖方已经将货物的重量和数量报给对方海关。货物运输抵达后，咨询我方海关货物重量和数量信息，被告知没有相关数据。取货后，只好自行为货物称重和计数。
\n
九月底实际上线时，出现了些小问题。更新了 Vuepress 版本之后，NodeJS 的最低版本需要 20 以上。当初作自动化部署时使用的版本是 18 ，部署方式使用的官方预编译的二进制安装的。
\n使用 Linux 预编译的二进制安装方式如下
\nwget https://nodejs.org/dist/v22.20.0/node-v22.20.0-linux-x64.tar.xz\n\ntar -xvzf node-v22.20.0-linux-x64.tar.xz && cd node-v22.20.0-linux-x64\n\ninstall -m 755 bin/* /usr/local/bin/\ncp -r include/* /usr/local/include/\ncp -r lib/* /usr/local/lib/\ncp -r share/* /usr/local/share/后面有必要把文档编译过程扔到容器里完成。
\n因为博客仓库的主分支设置了分支保护，白名单设置里，只允许我自己向主分支推送。要么取消白名单保护，要么将部署密钥添加到用户级（尚未验证）。
\n懒得再去重新添加密钥，就取消了白名单保护——只要密钥拥有写权限，就可以推送提交。
\nGitea 1.22.2 版本不支持通过接口来触发工作流，但是可以通过评论工单的方式来变相触发工作流 。
\n基于评论工单的方式触发工作流，工作流文件需要放在 .github 目录下，触发方式为 issue_comments ，并且 .gitea 和 .github 只能存在一个。
为了自定义工单评论请求的请求体，就需要手动构造请求，让 Gitea Actions 执行 curl 命令来发送这份请求。另外，只要有文章更新，这一流程会被反复触发。工单系统会因为工作流的反复触发而导致数据污染，当然如果不介意的话倒也没问题。
实际考量，如果想获得子模块的自动同步的话，更新 Gitea 是最根本方式；如果项目急需上线的话，便只能如此了。但，后续还是应该升级 Gitea ，并改为 Webhook 的方式。
\n\n\n系统维护除了解决一个个具体问题外，还需要疏通各个通路和问题解决后的收尾工作。
\n否则在面对紧急问题时哪头都堵，不得已作出各种让步；随之而来的便是系统维护代价越来越高，以至于走向崩溃。
\n
该功能作为博客文章一键发布功能之一，然而本地写作流程还没有具体方案。做这些的主要目标便是搭建一个契合自己的内容输出平台，也是学习闭环中的关键流程。
\n目前的创作流程还比较粗糙，学习、实践和记录三者同时进行，结束后（成功抑或失败）再编写文章总结。与此同时还需要去对关键步骤进行还原，为文章提供素材。文章草稿完成后，再校验和发布。整个流程走下来还是比较漫长的，除了文章的编辑过程，还有发布流程的改进。
\n该功能上线之后，只需推送 「文章」仓库的提交便搞定了，不需要手动地合并子仓库的提交了。
\n而文章的创作流程有待进一步改进……
\n\n\n先在笔记中罗列大纲，编辑为草稿；移到「文章」仓库，补充素材（图片、流程图）、链接和参考文献等，创建提交并推送到 Gitea，然后去主仓库合并更新并推送提交。
\n
当前网站的文章、博客代码和其他的项目代码都由自己在云端部署的 Gitea 服务管理。如果某一天阿里云「跪」了，那么我所有数据也就全体「升天」。因此 Gitea 服务的备份工作显得格外重要。
\nGithub 很多时候访问不了，有时候想要拉取一些代码，就特别麻烦。需要安装 Git 都还好说，但代码下载不下来就难受了。Gitee 和 GitCode 需要迎合市场需求，掺杂了不需要的东西也不好用（做代理不错）。
\n所以就目前来看，比较好的方案还是私有化部署 Gitea。GitLab 太大，云服务器配置低容不下，况且它其中的功能对于个人以及小型企业来说非必须的。
\nGitea 本身没有维护模式这一说法。 Gitea 服务是由 Nginx 反向代理出去的，除了提供 SSL 支持外，还需要代理博客网页的请求，二者通过域名来区分。为了保证 Gitea 的数据库与本地数据的完整性，因此备份时需要停止服务。而这样 Nginx 接收到来自客户的 Gitea 服务请求时就直接 502 了，这是不希望看到的。
\n![\"Screenshot](\"https://images.mtfh.cc/2025/09/01-f197a3174051656e0d612ce45d5b0584.png\")
维护页最简单的就是一个 HTML 网页了。AI 技术的发展太快了，这种网页甚至不需要自己去写。
\n使用 create-vue 脚手架，创建好 maintenance-html 工程。然后用 Trae 打开工程，输入提示词，网页就做好了。
\n\n其实工程都不需要自己创建，但是为了保证工程的一致性，就手动创建了。由 Trae 创建的话，还需要提示词来约束。
\n
![\"Screenshot](\"https://images.mtfh.cc/2025/09/01-3ede748eba6be5633676e0d05b535738.png\")
![\"Screenshot](\"https://images.mtfh.cc/2025/09/01-cd6ba67ee408ab80b57efb4bf6db5236.png\")
第一种方式，在 Gitea 服务启/停前后，运行一个同端口的 HTTP 服务，用来响应来自 Nginx 的代理请求。这样不需对 Nginx 做任何操作，缺点在于二者转换存在一定的延迟，可能会出现 502 。
\n第二种方式，通过切换 Nginx 配置文件来解决的。这样能够无缝切换到维护模式，然后再从维护模式切换回来。但是执行备份脚本的角色就需要提供 Nginx 控制权限和文件修改权限。另外，后续 Gitea 重新部署的话也同样需要这样一份文件。
\n第三种方式，当上游代理（Gitea 服务）不可达时，由 Nginx 响应维护页。维护页需要以单个 HTML 文件的形式存在，多文件配置起来比较麻烦（未测试成功）。部署 Gitea 的时候也需要针对维护页作配置。
\n\n\n如果仅仅只是为了达成目的，就不需要考虑这么多了。更多的还是希望规划好每个步骤，并对每一步制定相应的约束。这样下来整体协调统一，机器自动执行时保证不会出问题才是关键。
\n
根据官方文档介绍，gitea （二进制）拥有数据备份功能。不过仅支持备份，不能恢复。
添加一份维护页的代理配置 gitea-mainten.conf，将 gitea.conf 改名为 gitea.conf.disable。
server {\n listen 80;\n server_name gitea.mtfh.cc;\n return 301 https://$server_name$request_uri;\n}\n\nserver {\n listen 443 ssl;\n server_name gitea.mtfh.cc;\n\n ssl_certificate /etc/nginx/certificates/gitea.mtfh.cc.pem;\n ssl_certificate_key /etc/nginx/certificates/gitea.mtfh.cc.key;\n\n ssl_session_timeout 5m;\n ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE:ECDH:AES:HIGH:!NULL:!aNULL:!MD5:!ADH:!RC4;\n ssl_protocols TLSv1 TLSv1.1 TLSv1.2;\n ssl_prefer_server_ciphers on;\n\n location / {\n\t\t\troot /var/www/maintenance\n }\n}重新加载 Nginx ：
\nsystemctl reload nginx.service停止 Gitea 服务：
\nsystemctl stop gitea.service最后使用命令 gitea 命令备份数据：
\n./gitea dump --config app.ini![\"gitea-dump-output\"](\"https://images.mtfh.cc/2025/09/01-bc299eaa56cfed689d3301a7b8faa59d.png\")
根据 AI 提供的备份脚本，简单修改后，大致内容如下：
\n#!/bin/bash\n# gitea-backup.sh\n# Gitea 备份/恢复全流程自动化脚本（7z 压缩 + Nginx 维护页 + sudo + 自动清理旧备份）\n\nset -euo pipefail\n\n# 省略的配置内容\n\n# ================= 工具函数 =================\nrun_sudo() {\n if [[ -n \"$SUDO_PASS\" ]]; then\n echo \"$SUDO_PASS\" | sudo -S \"$@\"\n else\n sudo \"$@\"\n fi\n}\n\nswitch_to_maintenance() {\n echo \"===> 开启维护页\"\n run_sudo mv \"$NGINX_CONF_DIR/$NGINX_NORMAL_CONF\" \"$NGINX_CONF_DIR/$NGINX_NORMAL_CONF.disabled\"\n run_sudo cp \"$NGINX_CONF_DIR/$NGINX_MAINT_CONF\" \"$NGINX_CONF_DIR/$NGINX_NORMAL_CONF\"\n run_sudo nginx -s reload\n}\n\nswitch_to_normal() {\n echo \"===> 恢复正常代理\"\n run_sudo mv \"$NGINX_CONF_DIR/$NGINX_NORMAL_CONF\" \"$NGINX_CONF_DIR/$NGINX_MAINT_CONF\"\n run_sudo mv \"$NGINX_CONF_DIR/$NGINX_NORMAL_CONF.disabled\" \"$NGINX_CONF_DIR/$NGINX_NORMAL_CONF\"\n run_sudo nginx -s reload\n}\n\nstop_gitea() { \n echo \"===> 停止 Gitea 服务\" \n run_sudo systemctl stop gitea \n} \n \nstart_gitea() { \n echo \"===> 启动 Gitea 服务\" \n run_sudo systemctl start gitea \n}\n\n# 省略掉部分辅助函数\n\n# ================= 主流程 =================\nif [[ $# -lt 1 ]]; then\n echo \"Usage: $0 backup|restore [backup_file.7z]\"\n exit 1\nfi\n\nACTION=\"$1\"\n\nif [[ \"$ACTION\" == \"backup\" ]]; then\n DATE=$(date +'%Y-%m-%d_%H-%M-%S')\n TMP_DIR=\"$BACKUP_DIR/tmp-$DATE\"\n mkdir -p \"$TMP_DIR\"\n\n switch_to_maintenance\n stop_gitea\n\n echo \"===> 备份 Gitea 数据目录\"\n rsync -a --delete \"$GITEA_DATA/\" \"$TMP_DIR/data/\"\n backup_service\n\n echo \"===> 备份数据库\"\n backup_db \"$TMP_DIR\"\n\n start_gitea\n switch_to_normal\n\n echo \"===> 压缩为 7z\"\n 7z a -mx=9 \"$BACKUP_DIR/gitea-backup-$DATE.7z\" \"$TMP_DIR\"\n rm -rf \"$TMP_DIR\"\n\n cleanup_old_backups\n\n echo \"===> 备份完成: $BACKUP_DIR/gitea-backup-$DATE.7z\"\n\nelif [[ \"$ACTION\" == \"restore\" ]]; then\n\t# 节省篇幅，省略掉恢复步骤\n\t# 后来也没用上\nelse\n echo \"未知操作: $ACTION\"\n exit 1\nfi完整内容看这里。经测试，执行后拿到的备份数据，能够成功还原数据。
\n脚本虽然能成功执行，但其中有大量的 sudo 影子。不止是需要管控 Gitea 服务，还需要控制 Nginx 服务，同时还会修改 Nginx 配置文件。一个简单的备份脚本，哪能允许干这么多事儿！
git 用户本质是为 Git 提供 SSH 协议的，根本就不允许有 sudo 权限。可现在倒好，sudo 有了，登录密码有了，攻击者拿到密钥和密码，可以为所欲为了！
\n\n线上服务是正常，所以此处采取镜像的方式进行数据恢复测试。
\n
将备份后的数据拷贝到另一台设备，部署 Gitea 服务，然后恢复数据。不管是 Gitea Dump 备份，还是脚本备份，恢复流程一致。
\n安装数据库，原来用什么数据库，还原的时候一样。
\n\n\n线上用的 MySql，镜像的时候装的 Mariadb。后面假设线上用的 Mariadb
\n
sudo dnf install -y mariadb-server mariadb\n\n# 执行数据库初始化\nmysql_secure_installation\n\n# 连接数据库\nmysql -uroot -p创建数据库和关联用户
\nCREATE DATABASE gitea CHARACTER SET 'utf8mb4' COLLATE 'utf8mb4_bin';\n\nCREATE USER 'gitea'@'%' IDENTIFIED BY 'password';\nGRANT ALL PRIVILEGES ON gitea.* TO 'gitea'@'%' WITH GRANT OPTION;\nFLUSH PRIVILEGES;\n\n初次安装的历史比较久远，忘记创建数据库是需要对数据库字符集和排序规则进行设定，导致数据恢复之后，安全检查老提示字符集问题。
\n\n Screenshot 2025-09-01 at 19.03.57
创建 git 用户，用于执行 gitea 程序和存放运行数据，同时也便于支持 SSH 协议。
\n![\"Screenshot](\"https://images.mtfh.cc/2025/09/01-c97122972e4644df8a33ddff5025f42b.png\")
# 创建 git 用户，并分配家目录\nuseradd -m git\n\n# 创建 Gitea 数据目录\nsu - git\nmkdir gitea获取线上同版本 gitea 程序，放到家目录或 /usr/local/bin 。由于脚本打包，将可执行文件一同打包了进去，所以我就不需要单独下载了。
\n\nsystemd 配置，需要根据可执行文件的位置作出相应的变化。
\n
Gitea 的 systemd 配置示例如下：
\n[Unit]\nDescription=Gitea (Git with a cup of tea)\nAfter=syslog.target\nAfter=network.target\n\n[Service]\nRestartSec=2s\nType=simple\nUser=git\nGroup=git\nWorkingDirectory=/home/git/gitea\nExecStart=/home/git/gitea/gitea web --config /home/git/gitea/app.ini\nRestart=always\nEnvironment=USER=git HOME=/home/git GITEA_WORK_DIR=/home/git/gitea\n\n[Install]\nWantedBy=multi-user.targetNginx 代理配置如下：
\nserver {\n listen 80;\n server_name gitea.home.local;\n\n location / {\n proxy_pass http://127.0.0.1:3000;\n\n proxy_set_header Host $host;\n proxy_set_header X-Real-IP $remote_addr;\n proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;\n proxy_set_header X-Forwarded-Proto $scheme;\n }\n}本地测试环境，省事的话可以不走代理。用代理的话主要为了 HTTPS 代理和虚拟主机功能。
\n解压备份数据：
\n# Gitea Dump 备份的数据\nunzip gitea-dump-1756097579.zip\n\n# 脚本备份的数据\n#7za x gitea-backup-2025-08-28_10-30-01.7z\n7z x gitea-backup-2025-08-28_10-30-01.7z使用解压出的 SQL 文件，恢复数据库：
\n# Gitea Dump 备份的数据\nmysql --default-character-set=utf8mb4 -ugitea -p gitea < gitea-db.sql\n\n# 脚本备份的数据\nsed -i 's/utf8mb4_0900_as_cs/utf8mb4_bin/g' db.sql\nmysql --default-character-set=utf8mb4 -ugitea -p gitea < db.sql恢复数据时需要重点关注的配置：
\nWORK_PATH = /home/git/gitea\n\n[repository]\nROOT = gitea-repositories\n\n[server]\nSSH_DOMAIN = gitea.home.local\nDOMAIN = gitea.home.local\nHTTP_ADDR = 127.0.0.1\nHTTP_PORT = 3000\nROOT_URL = http://gitea.home.local\n\n[lfs]\nPATH = lfs\n\n[log]\nROOT_PATH = log\n\n仓库地址位置不对的话，仓库列表有该仓库，但仓库里代码没了；
\n\n
ROOT_URL配置不正确的话就会出现，登录不了的情况（认证成功，但跳转不到个人主页）。
最后检查解压出的备份数据位置是否和配置文件中的一致；检查数据库能否登录并访问数据表；检查 systemd 配置文件是否配置正确；检查代理配置是否正确（未使用代理忽略）。
\n启动服务：
\nsystemctl daemon-reload\nsystemctl start gitea.service管理后台 -> 维护 -> 自我检查\n管理后台 -> 维护 -> 管理面板\n健康检查所有仓库重新同步所有仓库的 pre-receive、update 和 post-receive 钩子\n\n使用 Gitea Dump 数据恢复之后，代码仓库不完整。曾认为是 Gitea Dump 备份代码仓库时数据备份不完全，但其实是我配置文件没改。因此不管是 Gitea Dump 还是脚本均能够还原数据。
\n
如果顺着 AI 提供的框架拓展的话，也许上个月就不会有结果了。仅仅只是为了自动化备份的话——删除其他逻辑，仅保留备份的顺序逻辑和辅助代码，就会变得简单多了。
\n为了以最小权限来执行备份脚本，维护页的激活方式改为了「第三种方式」。同时脚本不再对 Nginx 内容做任何操作。我只需要给 git 用户授权 systemctl start gitea.service 和 systemctl stop gitea.service 两条命令的权限即可。由于数据库的备份需要 PROCESS 权限，因此不得不去创建一个管理员权限，用来备份数据库。
关于 systemd 、Nginx 和备份等相关配置暂且只能由笔记记录下来，部署时手动恢复了。
\n改进后的脚本流程图：\n![\"Gitea](\"https://images.mtfh.cc/2025/09/01-ea8a87574a482d00fefe8a570cc77324.gif\")
脚本内容如下：
\n#!/bin/bash\n# gitea-backup.sh\n# Gitea 备份流程自动化脚本\n\nset -euo pipefail\n\n# ================= 配置区 =================\nBACKUP_DIR=\"${PWD}/backup\" # 备份存放目录\nGITEA_DATA=\"$HOME/gitea\" # Gitea 数据目录\nDB_TYPE=\"mysql\" # mysql / postgres / sqlite3\nDB_NAME=\"gitea\"\nDB_USER=\"happilys\"\nDB_PASS=${DB_PASS:-}\n\nKEEP_DAYS=7 # 自动清理超过 KEEP_DAYS 的旧备份\n\n# ================= 工具函数 =================\nbackup_db() {\n local dst=\"$1\"\n case $DB_TYPE in\n mysql)\n mysqldump -u\"$DB_USER\" -p\"$DB_PASS\" \"$DB_NAME\" > \"$dst/db.sql\"\n sed -i 's/utf8mb4_0900_as_cs/utf8mb4_bin/g' \"$dst/db.sql\"\n ;;\n postgres)\n PGPASSWORD=\"$DB_PASS\" pg_dump -U \"$DB_USER\" \"$DB_NAME\" > \"$dst/db.sql\"\n ;;\n sqlite3)\n cp \"$GITEA_DATA/gitea.db\" \"$dst/db.sqlite\"\n ;;\n *)\n echo \"未知数据库类型：$DB_TYPE\"\n exit 1\n ;;\n esac\n}\n\ncleanup_old_backups() {\n echo \"===> 清理 $KEEP_DAYS 天前的备份\"\n find \"$BACKUP_DIR\" -maxdepth 1 -type f -name \"gitea-backup-*.7z\" -mtime +$KEEP_DAYS -print -exec rm -f {} \\;\n} \n\n# ================= 主流程 =================\nDATE=$(date +'%Y-%m-%d_%H-%M-%S')\nTMP_DIR=\"$BACKUP_DIR/gitea-backup-$DATE\"\nmkdir -p \"$TMP_DIR\"\n\nsudo systemctl stop gitea.service\necho \"===> Gitea 服务已停止\"\n\necho \"===> 备份 Gitea 数据目录\"\nrsync -a --delete \"$GITEA_DATA/\" \"$TMP_DIR/data/\"\n\necho \"===> 备份数据库\"\nbackup_db \"$TMP_DIR\"\n\nsudo systemctl start gitea.service\necho \"===> Gitea 服务已启动\"\n\necho \"===> 压缩为 7z\"\n7z a -mx=9 \"$BACKUP_DIR/gitea-backup-$DATE.7z\" \"$TMP_DIR\"\nrm -rf \"$TMP_DIR\"\n\ncleanup_old_backups\n\necho \"===> 备份完成: $BACKUP_DIR/gitea-backup-$DATE.7z\"\n\n!!! 不得将上述代码应用于您的生产环境，否则造成的数据损失，后果自负！
\n
使用安装脚本安装 rclone 客户端，执行 rclone config 根据提示配置好网络存储后就可以使用命令同步或上传数据到云端了。网络存储方式 rclone 支持的列表很多，比如亚马逊 S3、七牛 Kodo，还有阿里云 OSS 等等，选择一个合适的即可。
使用脚本安装 rclone ：
\nsudo -v ; curl https://rclone.org/install.sh | sudo bash\n\n初次脚本安装还挺流畅，写这篇文章的时候，本地试了下——卡着不动了。实在不行，要不咱们上点「魔法」？
\n没「魔法」的话，想办法下载可执行文件拷到主机，给到可执行权限也行。
\n
rclone 配置参考这个内容，阿里云 OSS 同理。上传数据到阿里云 OSS ：
\nrclone copy backup/gitea-backup-2025-08-27_18-14-16.7z aliyun:mtfh-code-backup --v --log-file=~/.config/rclone/rclone.log\n\n使用 rclone 向七牛 Kodo 上传备份数据时，尝试几次始终出现
\nRequestTimeTooSkewed错误；换成阿里云 OSS 才上传成功。\n request-time-too-skewed-error
上传没问题后，就可以将这段命令添加进脚本，自动同步备份数据了。修改后，内容大致如下：
\n![\"request-time-too-skewed-error\"](\"https://images.mtfh.cc/2025/09/01-e24f5f04cb08af05ad016216ef25475f.png\")
# 省略的内容\n\necho \"===> 压缩为 7z\"\n7z a -mx=9 \"$BACKUP_DIR/gitea-backup-$DATE.7z\" \"$TMP_DIR\"\nrm -rf \"$TMP_DIR\"\n\ncleanup_old_backups\n\necho \"===> 上传文件\"\nrclone copy \"$BACKUP_DIR/gitea-backup-$DATE.7z\" aliyun:mtfh-code-backup -vv --log-file=~/.config/rclone/rclone.log\n\necho \"===> 备份完成: $BACKUP_DIR/gitea-backup-$DATE.7z\"脚本有了，云端同步的方式也有了，接下来就是让脚本定期执行了。使用 crontab 辅助工具，定时任务也就搞定了，唯一需要注意的就是环境变量。
\n由于当前代码仓库用户仅有我一个人，数据更新不是很频繁，因此采取一周备份一次就够用了。
\ncrontab 配置如下：
\nHOME=/home/git\nDB_PASS=<password>\n\n00 3 * * 6 $HOME/backup/gitea-backup.sh >> $HOME/backup/gitea-backup.log 2>&1\n\n在此之前我是这么配置的
\n\n
00 3 * * 6 DB_PASS=<password> $HOME/backup/gitea-backup.sh >> $HOME/backup/gitea-backup.log 2>&1检查日志
\nless /var/log/cron，发现只执行了变量定义，没有执行脚本。
目前博客与 Gitea 为一体，恢复了 Gitea 博客也便能够恢复（还需要手动干预）。然而 Nginx 配置与定时任务缺少代码关联，只能根据配置笔记来手动恢复。需要寻找方法将这些内容关联起来，达成一条命令一杯茶的功夫，所有内容自动恢复。
\n距离上面那一步还比较遥远 😂，近在眼前的——想好如何完成自动化部署任务吧！
\n优先基础需求使用起来，然后再根据使用时的反馈，发现问题再解决问题。依此不停地迭代，直到达成自己期望的样子。
\n\n\n如果搭建好完整的 CI/CD 系统，迭代流程会相当丝滑，只要把重心放在设计和编码上就好。如果再配合上 AI 工作流，那效果或许会非常棒。
\n
这里的本地部署，指的是部署到家庭的 Nas 主机上，操作系统使用的是 Rock Linux 8.9 （最新 10.0 了，后面找机会迁移到 9.6 ）。
\nVBoxes 服务由三部分组成，vboxes 接口服务、网页和 Nginx 代理。最初希望只有一个 vboxes 程序搞定一切，现在则是由 Nginx 处理网页静态资源请求。因此想要自动化部署就比较麻烦了，不然这篇就叫《VBoxes 服务的自动部署》。
\nvboxes 程序目前仅作为接口服务，即使具备静态服务器的功能（尚未将网页资源打包进可执行文件当中）。当前的 VBoxes 服务架构如图：
\n![\"VBoxes-1\"](\"https://images.mtfh.cc/2025/08/24-dbc3a55dc20aff89a40cb6f71a3edaaa.jpg\")
这里使用 systemd 来管理 vboxes 服务。
\n创建并编辑配置文件 /etc/systemd/system/vboxes.service ，内容如下：
[Unit]\nDescription=VBoxes (Vagrant box share server)\nAfter=syslog.target\nAfter=network.target\n\n[Service]\nRestartSec=2s\nType=simple\nUser=happilys\nGroup=happilys\nWorkingDirectory=/srv/nas/VagrantBoxes\nExecStart=/usr/local/bin/vboxes --address 0.0.0.0 --port 9321 --host http://192.168.5.114 --dir ./Boxes\nRestart=always\n\n[Install]\nWantedBy=multi-user.target加载服务配置并启动
\nsystemctl daemon-reload\n\n# 启动\nsystemctl start vboxes\n\n# 开机自启\n#systemctl enable vboxes![\"vboxes-status\"](\"https://images.mtfh.cc/2025/08/24-4d41a1b069315b1e279e969a303f44c9.png\")
配置好 Vue 的开发环境后，拉取代码，打包。把生成的网页文件放到指定目录，编辑 Nginx 配置
\n\n\n实际情况是在开发机打包好，上传到 Nas 主机上的。因为前端不像 C/C++ 程序，跨 CPU 或系统都需要重新编译。C++ 语言是跨平台的，但编译后的二进制不能跨平台。
\n
user nginx;\nworker_processes auto;\nerror_log /var/log/nginx/error.log;\npid /run/nginx.pid;\n\nevents {\n worker_connections 1024;\n}\n\nhttp {\n log_format main '$remote_addr - $remote_user [$time_local] \"$request\" '\n '$status $body_bytes_sent \"$http_referer\" '\n '\"$http_user_agent\" \"$http_x_forwarded_for\"';\n\n access_log /var/log/nginx/access.log main;\n\n sendfile on;\n tcp_nopush on;\n tcp_nodelay on;\n keepalive_timeout 65;\n types_hash_max_size 2048;\n\n include /etc/nginx/mime.types;\n default_type application/octet-stream;\n\n server {\n listen 80;\n server_name vboxes.home.local;\n\n\t\t# 网页的静态资源处理\n location / {\n root /srv/data/vboxes-ui;\n }\n\n\t\t# 其他配置\n }\n}修改网页文件的权限或用户/组
\nchown -R nginx:nginx /srv/data/vboxes-ui\nchmod -R u=rwX,go=rX /srv/data/vboxes-ui家庭内网环境一般可以直接关停 SELinux 和防火墙 。
\n关闭防火墙
\nsystemctl disable firewalld编辑 /etc/selinux/config 来停用 SELinux
# This file controls the state of SELinux on the system.\n# SELINUX= can take one of these three values:\n# enforcing - SELinux security policy is enforced.\n# permissive - SELinux prints warnings instead of enforcing.\n# disabled - No SELinux policy is loaded.\nSELINUX=disabled另外
\n# 获取 SELinux 状态\ngetenfoce\n\n# 临时设置 SELinux\n## 停止（Permissive: 仅发出警告，不作实际控制）\nsetenfoce 0\n\n## 启动（Enforcing: 完全激活状态）\nsetenfoce 1这里客户端浏览器可以直接访问接口请求，不过因为浏览器同源策略问题，因此需要使用 Nginx 来代理接口请求（这里提到过）。
\n\n\n生产环境不会将公开接口暴露出来，这里 vboxes 监听所有接口（
\nvboxes -a 0.0.0.0），只是为了方便网页开发时的调试工作。
# 省略的配置\n\nhttp {\n\t# 省略的配置\n\n server {\n listen 80;\n server_name vboxes.home.local;\n\n\t\t# 网页静态资源\n location / {\n root /srv/data/vboxes-ui;\n }\n\n\t\t# 接口和 .box 文件代理\n location ~* (^/api|\\.box$) {\n proxy_pass http://127.0.0.1:9321;\n\n proxy_set_header Host $host:$server_port;\n proxy_set_header X-Real-IP $remote_addr;\n proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;\n }\n }\n}重新加载 Nginx 配置后，即可访问 VBoxes 网页
\nsystemctl reload nginx![\"nas-home-local\"](\"https://images.mtfh.cc/2025/08/24-701ef3ab2a8c8f47fc8a6224a959b304.png\")
部署过程中，主要问题还是在 vboxes 程序上，部署反而并未发现多少问题。程序方面，存在内存占用较高、运行时异常重启和下载速度太慢等问题。
\n部署前端文件时，将文件放指定目录后（该目录下的内容同时会被 SMB 共享出去），在经过一段时间之后目录下文件权限全变成问号了。
\n后面移到了未被 SMB 共享的目录（即前面配置中出现的位置）也便正常了。
\n局域网带宽为 1 Gbps ，使用 Vagrant CLI 获取「盒子」时平均速率 10 M/s 。很明显不符合预期，在其他设备上测试也是如此。
\n使用 iperf3 进行网络测试，能够接近理论带宽。
\n将 vboxes 重新编译安装之后，然后启服务，似乎恢复正常了。
\n\n\n运维不懂开发，开发不懂运维。原地死锁——自动运维也就很难发展了。
\n开发角度，可以通过一些技术将原来七个步骤缩短为三个步骤。相对于七步而言，三步更不易出错；而相对于机器而言，人在执行重复性任务时更容易出错（虽然可以通过后天训练提高）。
\n
后续的改善步骤除了搭建好自动化流程，还需将重点放在开发上。
\n\n\n手动部署的方式还是麻烦，如果每次都需要这么做，很容易出错。仅就一台设备而言，好说；可设备多起来的话，岂不原地升天。
\n如果只有一个二进制程序，不管是本地部署，还是容器化部署都很轻松，虽然当下情况也能使用 docker，但后面还是希望改进为单一的可执行文件形式——把网页文件也编译进二进制。不管你外层是否添加代理还是其他的什么东西，vboxes 程序是完备的。不需要像现在这样，由 Nginx 处理静态文件请求。
\n另外，单一的二进制也方便嵌入式设备使用，也不用像 Qt 部署时，需要带上一堆动态库（系统自带的和开发时使用的版本往往是不一样的，甚至某些库会因为一些需求而魔改过）。
\n
自动化方案有两种，第一，编写 Dockerfile ，自动构建 Docker 镜像，然后使用 Docker 自动化部署；第二种，完成「二进制资源访问器」的实现，自动化执行 CMake 的 Build 和 Install 步骤（然后重启服务）。将来可以打包为 rpm ，通过包管理器来安装部署。
\n容器化方案：
\n![\"VBoxes-3\"](\"https://images.mtfh.cc/2025/08/24-ca2d5128a43f4724663195c0b1edc076.jpg\")
非容器化方案：
\n![\"VBoxes-2\"](\"https://images.mtfh.cc/2025/08/24-94284ed5ae0fc1a189fd42c04a955fa8.jpg\")
程序崩溃跟踪和日志记录
\n可能存在的内存问题
\n多线程：解析数据时程序时没法正常退出的
\n.box 文件元数据解析：vboxes 模块在 box 文件元数据的读取方面太慢了，除了要计算 MD5 值，还需要解析 tar 包，效率打了大大的折扣。既然都用 C/C++ 了，为什么不定义一个数据结构写到文件头呢？
\n代码工程化：相对于整个 VBoxes 项目而言，包括前端和其他的衍生工具。
\n单元测试：因为修改代码引发 Bug ，谁也不愿因此背锅。如果开发时可以大胆地改进糟糕的实现，而不用担心因为代码的修改导致接口出错而引发的 Bug。单元测试可以很好减轻修改代码引发错误的可能，只需要跑一遍单元测试就可以知道接口有没有被改坏。
\n代码格式化：想要统一所有的 C/C++ 语法代码不可能，但是格式化语言子集还是能够做到的。
\nVuepress Theme Hope 主题默认启用文章分类功能，该功能通过 FrontMatter 中的 category 字段来识别不同类别。如果我希望为文章添加分类就需要维护每篇文章的 category 字段。如果我将这篇文章放在 Web 分类下，一个月后忘记自己设置过 Web 分类，需要翻阅过去的内容，要么重新命名一个 「前端」分类。
\n因此，我希望实现根据文章所在目录自动进行分类的功能。观察目录结构，所有的类别一目了然，也不需要手动编辑 FrontMatter 中的 category 属性。
\n\n\n根据 Vuepress 插件文档，定制一套分类规则也许更灵活。但毕竟对 Vuepress 理解有限，直接修改博客插件规则较为麻烦，不如改写 FrontMatter 更容易理解。
\n
自动分类插件通过 autoCategory 函数递归地遍历文档根目录，也就项目中的 posts 目录。通过比较文章所在目录和文档根目录获得到文章的分类列表。比如 posts/前端/Vue/基于 highlight.js 的代码块组件封装 就被归类到 前端 和 Vue 这两个类别。
实现代码如下：
\n// scripts/auto-category.js\nimport fs from \"fs\";\nimport path from \"path\";\nimport matter from \"gray-matter\";\n\nlet docsDir: string;\n\nexport function autoCategory(dir: string) {\n if (!docsDir) { docsDir = dir; }\n\n const entries = fs.readdirSync(dir);\n for (const entry of entries) {\n const fullPath = path.join(dir, entry);\n const stat = fs.statSync(fullPath);\n if (stat.isDirectory()) {\n autoCategory(fullPath);\n } else if (entry.endsWith(\".md\")) {\n const content = fs.readFileSync(fullPath, \"utf8\");\n const parsed = matter(content);\n\n if (parsed.data.category) continue;\n\n const dirRelativePath = path.relative(docsDir, dir);\n const category = dirRelativePath === \"\" ? [] : dirRelativePath.split(path.sep);\n\n if (category.length > 0) {\n parsed.data.category = category;\n const newContent = matter.stringify(parsed.content, parsed.data);\n fs.writeFileSync(fullPath, newContent);\n console.log(`Added category \"${category}\" to ${path.relative(docsDir, fullPath)}`);\n }\n }\n }\n}插件部分定义如下：
\n// src/index.ts\nimport path from 'path'\nimport type { Plugin } from '@vuepress/core';\nimport { autoCategory } from './node/autoCategory.js'\n\nconst autoCategoryPlugin = (docDir: string | string[]): Plugin => (app) => {\n return {\n name: 'vuepress-plugin-auto-category',\n\n onPrepared() {\n const dirs = Array.isArray(docDir) ? docDir : [docDir];\n const absDirs = dirs.map((dir) => path.resolve(app.dir.source(), dir));\n\n for (const absDir of absDirs) {\n autoCategory(absDir);\n }\n }\n };\n};\n\nexport default autoCategoryPlugin;导入依赖并注册插件，然后执行打包脚本两次即可获得带有文章分类的博客。
\n// 其他内容省略\nimport autoCategoryPlugin from \"./plugins/auto-category/index.js\";\n\n\nexport default defineUserConfig({\n // 省略的配置\n plugins: [\n autoCategoryPlugin(\"posts\")\n ]\n});![\"Screenshot](\"https://images.mtfh.cc/2025/08/08-8d56ed399d8e857a08ddc7d7dc58d423.png\")
因为某些原因，不得不将插件的 autoCategory.ts 挪出来作为独立的预处理脚本。
修改后 scripts/auto-category.ts 代码内容如下：
import fs from 'fs'; \nimport path from 'path'; \nimport matter from 'gray-matter'; \n \nconst docsDir = path.resolve(__dirname, '../src/posts'); \n\nfunction autoCategory(dir: string) { \n let count = 0; \n const entries = fs.readdirSync(dir); \n for (const entry of entries) { \n const fullPath = path.join(dir, entry); \n const stat = fs.statSync(fullPath); \n if (stat.isDirectory()) { \n count += autoCategory(fullPath); \n } else if (entry.endsWith(\".md\")) { \n const content = fs.readFileSync(fullPath, \"utf8\"); \n const parsed = matter(content); \n \n if (parsed.data.category) continue; \n \n const dirRelativePath = path.relative(docsDir, dir); \n const category = dirRelativePath === \"\" ? [] : dirRelativePath.split(path.sep); \n \n if (category.length > 0) { \n parsed.data.category = category; \n const newContent = matter.stringify(parsed.content, parsed.data); \n fs.writeFileSync(fullPath, newContent); \n console.log(`Added category \"${category}\" to ${path.relative(docsDir, fullPath)}`); \n count++; \n } \n } \n } \n return count; \n} \n \n// 执行入口 \n(function main() { \n console.log(`📁 Scanning Markdown files in: ${docsDir}`); \n const changed = autoCategory(docsDir); \n console.log(`✅ Done. ${changed} file(s) updated.`); \n})();由于需要将该文件作为独立的脚本运行，并且使用的是 TypeScript 语法（也可以把代码改为 JavaScript 直接丢给 Node 执行），这里使用 ts-node 包来执行 Ts 脚本。
\nyarn add -D ts-node typescript另外在 package.json 中的 scripts 对象中添加如下命令
{ \n \"type\": \"module\", // 这一行需要删掉\n \"scripts\": { \n // 需要添加的命令\n \"docs:prebuild\": \"ts-node scripts/auto-category.ts\", \n }\n}这里需要删掉 "type": "module" 这行， 不然会出现 TypeError: Unknown file extension ".ts" for xxx.ts 错误。
![\"Screenshot](\"https://images.mtfh.cc/2025/08/08-8c8aa601163a60595e617cb5fd268b87.png\")
最后执行以下命令便可以生成和前面相同的内容
\nyarn docs:prebuild\n\nyarn docs:dev\n# 或者\n#yarn docs:build\n\n当时在做这项修改的时候挺膈应的，需要变更的内容太多了。除了修改代码，还需要安装额外的依赖、修改 package.json 和 CI 文件（build-docs.yaml）。
\n经验有限，一时半会儿也想不到比较好的办法，因此只能强行去改了。
\n写这篇文章时想到了一个更快的方法，只需要改动一行代码就能解决问题 😂。
\n
以下是在测试中遇到的一些问题。第一条并非真实问题，最后一条属于事先调研不充分，第二条才算是实实在在的问题。但既然已经发生，就不存在真实问题和虚假问题的区别了。
修改文章的目录结构后，预期结果——最新发布的文章排序应该和未分类时的相同，并且文章状态栏包含分类信息。此时使用的还是插件的形式，在分类页中能看到已经分类过的文章，但是主页中这些文章被放到了文章列表的末尾（开始在主页里不到，下意识认为主页没索引这些文章）。
\n![\"Screenshot](\"https://images.mtfh.cc/2025/08/08-4abdd9f5f3d703ceac694d999ac7053d.png\")
此时怀疑是 Vuepress 的文章排序规则导致的——子目录中的文章优先级始终低于父目录。实则并没有这项机制，不论是 AI 还是自行验证都是如此。
\n\n\n这时候就体现了 AI 的优势，问 AI 几秒钟就能得出结论，但手动测试的话就需要十五到二十分钟了。因为本就是不熟悉才需要测试，在不熟悉的状态下配置相同的环境，然后再去模拟相似的场景实验，就非常麻烦。
\n上述场景建立在独立探索情景下，如果有前辈指导那这篇文章也许就不存在了。
\n
知道了文章排序优先级不受目录层级影响后，发现一条关键线索——分类过的文章日期丢了。
\n![](\"https://images.mtfh.cc/2025/08/08-b2b94e08b35601ffe7d235b0d97fbed6.png\")
顺着年初给 Git 插件打补丁的思路，一路排查到 Git 命令行发现——修改了文章目录位置却还没提交，Git 也就查不到记录。
\n也许插件的实现和发布中间隔的时间太久了，改完之后就做测试和发布应该不会出这种情况。
\n由于改变目录结构就会改变链接地址，考虑到改动已发布的文章目录位置，会导原链接失效。需要为旧地址设置重定向，来指向新的地址。
\n做法很简单，为每个移动过的文章添加一条 FrontMatter 属性，名称为 redirectFrom ，值为移动前文的位置，原文件不需要真实存在。该功能是由 redirect-plugin 实现，已由 Vuepress Theme Hope 主题内置并默认开启。
需要注意的是默认的开发服务器对此项设置并不会生效（但 redirectTo 却可行）。打包之后，使用 Python 启动一个静态服务器，测试成功。
python3 -m http.server 8080 --directory src/.vuepress/dist/具体原因是…… ?
\n由于在插件中注册的任何一个钩子调用时机均迟于 plugin-blog 创建分类信息的时机，因此 plugin-blog 创建分类信息时并不知道文章有分类信息。而第二次执行能成功，是因为第一次已经为文章添加好了分类数据——这就相当于人为地为文章添加了分类信息，然后执行打包脚本。事实上，第二次 auto-category 插件并未向文件写入分类信息。
\n| Hook | 触发时机 | 能否修改 FrontMatter | 备注 |\n|
\n", "image": "https://images.mtfh.cc/2025/08/08-8d56ed399d8e857a08ddc7d7dc58d423.png", "date_published": "2025-08-08T06:38:43.000Z", "date_modified": "2026-01-31T09:20:36.000Z", "authors": [], "tags": [ "前端", "Vue" ] }, { "title": "基于 highlight.js 的代码块组件封装", "url": "https://blog.mtfh.cc/posts/%E5%89%8D%E7%AB%AF/Vue/%E5%9F%BA%E4%BA%8E%20highlight.js%20%E7%9A%84%E4%BB%A3%E7%A0%81%E5%9D%97%E7%BB%84%E4%BB%B6%E5%B0%81%E8%A3%85.html", "id": "https://blog.mtfh.cc/posts/%E5%89%8D%E7%AB%AF/Vue/%E5%9F%BA%E4%BA%8E%20highlight.js%20%E7%9A%84%E4%BB%A3%E7%A0%81%E5%9D%97%E7%BB%84%E4%BB%B6%E5%B0%81%E8%A3%85.html", "summary": "基于 highlight.js 的代码块组件封装 代码块组件主要用于显示 Vagrantfile 模版，而 Vagrantfile 中的实际内容其实是 Ruby 脚本。使用 highlight.js 对模版内容进行高亮展示能够提供更好的用户体验。另外还需要拷贝模版和下载模版的需求。 安装依赖和配置 安装 highlight.js 和 @highligh...", "content_html": "\n代码块组件主要用于显示 Vagrantfile 模版，而 Vagrantfile 中的实际内容其实是 Ruby 脚本。使用 highlight.js 对模版内容进行高亮展示能够提供更好的用户体验。另外还需要拷贝模版和下载模版的需求。
\n安装 highlight.js 和 @highlightjs/vue-plugin
yarn add highlight.js @highlightjs/vue-plugin注册插件的方式有两种：
\n第一种，全局注册——在 main.ts 文件中导入相关依赖，调用 app.use() 接口来注册插件
import 'highlight.js/styles/github-dark.css' \nimport 'highlight.js/lib/common' \nimport hljsVuePlugin from '@highlightjs/vue-plugin' \n\nconst app = createApp(App) \napp.use(router) \napp.use(hljsVuePlugin) \n\napp.mount('#app')第二种，局部注册——在 CodeBlock.vue 文件（手动创建）中导入相关依赖，手动获取组件
<template>\n <!-->省略的模版内容<-->\n <highlightjs \n :language=\"language\" \n :code=\"code\" \n class=\"rounded-xl bg-gray-800 text-sm text-white p-4\" \n />\n</template> \n \n<script setup lang=\"ts\"> \nimport 'highlight.js/styles/github-dark.css' \nimport 'highlight.js/lib/common' \nimport hljsVuePlugin from '@highlightjs/vue-plugin' \n \nconst highlightjs = hljsVuePlugin.component; \n\n// 其他功能代码\n</script>实际使用视具体情况而定，全局注册比较简单，注册之后项目中任何需要展示代码的地方都可一使用 highlightjs 这个组件；局部注册仅在 CodeBlock.vue 文件中可用，如果其他地方没有代码展示需要，仅在 CodeBlock.vue 文件内使用会更好。不建议两种方式同时存在。
组成 UI 的元素仅两个按钮和一个 highlightjs 组件，样式采用 TailwindCSS，图标则由 Lucide 提供，具体可以查看这篇内容。代码大致如下：
<template> \n <div class=\"relative group\"> \n <div \n class=\"absolute top-5 right-5 flex gap-2 z-10 opacity-0 group-hover:opacity-100 transition-opacity\" \n > \n <button \n class=\"p-2 bg-gray-700 hover:bg-gray-600 rounded text-white\" \n @click=\"copyCode\" \n :title=\"copied ? 'Copied!' : 'Copy code'\" \n > \n <component :is=\"copied ? Check : ClipboardCopy\" class=\"w-4 h-4\" /> \n </button> \n \n <button \n class=\"p-2 bg-gray-700 hover:bg-gray-600 rounded text-white\" \n @click=\"downloadCode\" \n title=\"Download code\" \n > \n <Download class=\"w-4 h-4\" /> \n </button> \n </div> \n \n <highlightjs \n :language=\"language\" \n :code=\"code\" \n class=\"rounded-xl bg-gray-800 text-sm text-white p-4\" \n /> \n </div> \n</template> \n\n<script setup lang=\"ts\"> \nimport {ref} from 'vue' \nimport { ClipboardCopy, Check, Download } from 'lucide-vue-next' \n \nimport 'highlight.js/styles/github-dark.css' \nimport 'highlight.js/lib/common' \nimport hljsVuePlugin from '@highlightjs/vue-plugin' \n \nconst highlightjs = hljsVuePlugin.component; \n \nconst props = defineProps({ \n code: { type: String, required: true }, \n language: { type: String, default: 'javascript' }, \n filename: { type: String, default: '' }, \n})\n</script>这里组件注册使用的是局部注册的方式。基础外观完成了，下面就是主要交互功能了。
\n具体的代码其实并不需要自己去写，只需要告诉 AI 需求，就能够完成我想要的功能。
\n<script setup lang=\"ts\"> \n// 省略的内容\n\nconst copied = ref(false) \nconst copyCode = async () => { \n try { \n await navigator.clipboard.writeText(props.code) \n copied.value = true \n setTimeout(() => (copied.value = false), 1500) \n } catch (err) { \n console.error('Copy failed:', err) \n } \n} \n \nconst downloadCode = () => { \n const blob = new Blob([props.code], { type: 'text/plain;charset=utf-8' }) \n const extensionMap: { [key: string]: string } = { \n ruby: 'rb', \n cpp: 'cpp', \n python: 'py', \n bash: 'sh', \n } \n const ext = extensionMap[props.language] || 'txt' \n const filename = props.filename || `code.${ext}` \n \n const link = document.createElement('a') \n link.href = URL.createObjectURL(blob) \n link.download = filename \n link.click() \n URL.revokeObjectURL(link.href) \n} \n</script>完整代码参考这里
\n编辑 AboutView.vue 内容如下：
<template> \n <div class=\"about flex flex-col justify-center py-8\"> \n <CodeBlock :code=\"code\" language=\"ruby\" filename=\"Vagrantfile\" /> \n </div> \n</template> \n\n<script setup lang=\"ts\"> \nimport CodeBlock from '@/components/CodeBlock.vue' \n\nconst code = \n 'Vagrant.configure(\"2\") do |config|\\n' + \n ' config.vm.box = \"ubuntu-focal-qt\"\\n' + \n ' config.vm.box_url = \"http://192.168.5.114:9321/api/ubuntu-focal-desktop-en-qt\"\\n' + \n '\\n' + \n ' config.vm.provider \"virtualbox\" do |vb|\\n' + \n ' vb.gui = true\\n' + \n ' vb.cpus = 4\\n' + \n ' vb.memory = \"2048\"\\n' + \n ' end\\n' + \n '\\n' + \n ' config.vm.provision \"shell\", inline: <<-SHELL\\n' + \n ' apt-get update\\n' + \n ' SHELL\\n' + \n 'end' \n</script>![\"vue-code-block-demo\"](\"https://images.mtfh.cc/2025/07/29-262337a8d8655187ee15d7a342311a7a.gif\")
网络教程和一些书籍上提供的组件库多以 Element Plus 为主。了解 TailwindCSS 之后发现它更符合我的品味，另外还发现了 Tailwind Plus 替代 —— Shadcn-Vue。
\n图标库使用 AI 推荐 lucide-vue-next，话又说回来 Shadcn-Vue 自带的也许省事儿点。
TailwindCSS 提供一组原子化的 CSS 样式类来构建复杂的 UI 组件，这些原子化的样式涵盖了布局、字体、动画、交互和响应式布局，还有主题配置等等内容。用得好的话，会非常强。
\n# 通过 yarn 安装 tailwindcss 和 @tailwindcss/vite\nyarn add tailwindcss @tailwindcss/viteTailwindCSS 安装完成后需要在 vite 配置中激活 TailwindCSS 插件，并在主样式文件中引入样式
\nvite.config.ts 配置如下：
\nimport tailwindcss from '@tailwindcss/vite'\n\nexport default defineConfig({ \n plugins: [ \n tailwindcss()\n ]\n})main.css 主样式文件导入内容：
\n@import \"tailwindcss\";Shadcn-Vue 是一个由社区主导的 shadcn/ui 移植项目。shadcn/ui 专为 React（基于 Tailwind CSS）设计的 UI 组件库，没有 Vue3 的原生支持。Shadcn-Vue 的诞生便是源于 Vue 生态系统对它的需求。
\n安装依赖前需要编辑两个文件。首先，编辑 tsconfig.json
{ \n // 省略已有内容\n // ...\n \n \"compilerOptions\": { \n \"baseUrl\": \".\", \n \"paths\": { \n \"@/*\": [ \n \"./src/*\" \n ] \n } \n } \n}再编辑 tsconfig.app.json 这个文件
{\n \"compilerOptions\": {\n // path 属性在 tsconfig.app.json 文件中默认存在\n // 所以之需要添加 baseUrl 即可\n \"baseUrl\": \".\",\n \"paths\": {\n \"@/*\": [\n \"./src/*\"\n ]\n }\n }\n}另外根据官方文档说明，需要对 vite.config.ts 进行配置。但是脚手架默认生成的内容是有路径解析的配置。
\n\n\n当前项目：
\n\n
\n- \n
create-vue版本3.17.0- \n
Vue版本3.5.17- \n
Vite版本7.0.0。
为保障后续步骤的正常进行，应该检查一下这项配置。
\n/* 注释的内容是官方文档提供的配置 */\n/* 未注释的是默认已存在配置 */\n\n//import path from 'node:path'\nimport { fileURLToPath, URL } from 'node:url'\n\nexport default defineConfig({ \n\t// ...\n \n resolve: { \n alias: {\n //'@': path.resolve(__dirname, './src'),\n '@': fileURLToPath(new URL('./src', import.meta.url)) \n }, \n }, \n})执行以下命令进行安装，然后根据需要选择组件进行添加。
\n# 安装初始化库\nyarn dlx shadcn-vue@latest init\n# 添加组件\nyarn dlx shadcn-vue@latest add button\n\n官方给出的
\nyarn安装命令使用的是npx，使用该命令执行后，包管理变成npm了？根据
\nVue3脚手架使用经验，试了yarn dlx命令，成功且尚未发现问题。
安装并添加组件后，工程目录下会多些东西。components.json 、lib/utils.ts 和 components/ui/*
![\"components-dir-tree\"](\"https://images.mtfh.cc/2025/07/16-a8bef86aa521097b756732c3bd8e510a.png\")
在已有 AboutView.vue 文件编辑如下内容
<template> \n <div class=\"about\"> \n <h1>This is an about page</h1>\n <!-- 添加的内容，使用了 TailwindCSS 的样式类 --> \n <div class=\"flex w-full max-w-sm items-center gap-1.5\"> \n <Input type=\"text\" :placeholder=\"name\" v-model=\"name\" /> \n <Button @click=\"sayHello\">你好！</Button> \n </div> \n </div> \n</template> \n\n<!-- 添加的内容，使用组合式 API -->\n<script setup lang=\"ts\"> \nimport { ref } from 'vue' \nimport { Button } from '@/components/ui/button' \nimport { Input } from '@/components/ui/input' \n \nconst name = ref(\"\"); \n \nconst sayHello = () => { \n alert(`Hello ${name.value}!`); \n}\n</script> \n \n<style> \n@media (min-width: 1024px) { \n .about { \n min-height: 100vh; \n display: flex; \n align-items: center; \n } \n}\n</style>![\"components-demo\"](\"https://images.mtfh.cc/2025/07/16-1dd508609662f0a1828675a09bb2ee56.gif\")
Lucide 是一个开源图标库，提供 1000 多个矢量 (SVG) 文件，用于在数字和非数字项目中显示图标和符号。该库旨在通过提供多个官方软件包，帮助设计师和开发者更轻松地将图标融入到项目中，从而更轻松地在项目中使用这些图标。
\n安装 lucide-vue-next
yarn add lucide-vue-next编辑 AboutView.vue 内容如下
<template>\n <div class=\"about\">\n\t\t<!-- ... -->\n <div class=\"flex w-full max-w-sm items-center gap-1.5\">\n\n <User color=\"black\" :size=\"32\" />\n\t\t\t<!-- ... -->\n </div>\n </div>\n</template>\n\n<script setup lang=\"ts\">\n// ...\nimport { User } from 'lucide-vue-next'\n\n// ...\n</script>![\"icon-sample\"](\"https://images.mtfh.cc/2025/07/16-991012962f4dda7e09460c0aabf798b2.png\")
具体的图标名称在这里搜索。
\nLucide 图标默认以 Vue 组件方式提供，在用作状态图标时需要单独对其大小进行设置，不太方便，将来能否改用其他方式——以类名方式使用的图标，比如 UnoCSS ？
\n根据官方文档，使用 Vue3 脚手架能够很轻松地搭建起 Vue 项目。唯一遇到的问题就是 yarn 对 node module 处理方式上的问题（如果使用其他包管理工具请忽略）。
\nyarn4+ 默认使用 PnP 模式来处理 node modules ，但是这样在执行 package.json 的脚本和 IDE 错误提示都存在问题。最简单的解决方法就是——在项目根目录下添加 .yarnrc.yml 文件并添内容如下：
\nnodeLinker: node-modules以下是项目搭建说明。
\nWindows 直接在官网下载最新的 LTS 版本安装。
\n![\"download-node-js\"](\"https://images.mtfh.cc/2025/07/14-946edf17192bb21eae5871373a34aa4b.png\")
Mac 可以使用 Homebrew 安装，但需要「魔法」就不提供具体说明了——各显神通吧。
\nLinux 的不同发行版本有 apt、yum 或 pacman 等包管理器，根据具体系统版本使用相应的包管理器安装即可。另外，如果考虑需要用到不同的 node 版本可以选择 nvm。
\n下面是 Linux 使用 nvm 安装 nodejs 的说明：
\n# 如果没有 git 先安装 git\n# apt install -y git\n# pacman -Syu git\n# dnf install -y git\nyum install -y git\n\n# 下载并安装 nvm:\nexport NVM_DIR=\"$HOME/.nvm\" && (\n git clone https://gitee.com/mirrors/nvm-sh.git \"$NVM_DIR\"\n cd \"$NVM_DIR\"\n git checkout `git describe --abbrev=0 --tags --match \"v[0-9]*\" $(git rev-list --tags --max-count=1)`\n) && \\. \"$NVM_DIR/nvm.sh\"\n\n# 安装 Node.js:\nnvm install 22\n\n# 验证 node 版本\nnode -v\nnvm current\n\n# 启用 yarn:\ncorepack enable yarn\n\n# 验证 yarn 版本\nyarn -v安装完成后，添加如下内容到 ~/.bashrc、 ~/.bash_profile、 ~/.zshrc 或 ~/.profile 。仅需要添加内容到其中某一个文件末尾即可，主要目的是为了 Shell 重启后 nvm 命令还能够正常使用（类似于 Windows 中配置 Path 环境变量）。
export NVM_DIR=\"$HOME/.nvm\"\n[ -s \"$NVM_DIR/nvm.sh\" ] && \\. \"$NVM_DIR/nvm.sh\" # This loads nvm\n[ -s \"$NVM_DIR/bash_completion\" ] && \\. \"$NVM_DIR/bash_completion\"这种方式适用于大多数 Linux 发行版本（也支持 Mac ），除了安装步骤有点麻烦外暂未发现其他问题。
\n由于某些原因不能使用默认的安装脚本，只好采用克隆镜像仓库的方式进行安装了。
\n这算是前端工程化，首次创建工程前的基操了。
\nyarn4+ 版本命令：
\n# 查询当前使用的镜像源\nyarn config get npmRegistryServer\n\n# 设置为淘宝镜像源\nyarn config set npmRegistryServer -H https://registry.npmmirror.com\n\n# 还原为官方镜像源\nyarn config set npmRegistryServer -H https://registry.yarnpkg.comyarn 1.x 版本命令：
\n# 查询当前使用的镜像源\nyarn config get registry \n\n# 设置为淘宝镜像源\nyarn config set registry https://registry.npmmirror.com/ \n\n# 还原为官方镜像源\nyarn config set registry https://registry.yarnpkg.com/yarn dlx create-vue@latest执行命令后需要根据提示完成以下几个步骤：
\n切换到工程目录，使用命令或者打开 IDE 运行项目。
\n使用命令启动项目：
\n# 切换到工程目录\ncd vboxes-ui\n\n# 安装 npm 包\nyarn\n\n# 启动开发服务器\nyarn dev根据提示打开网页地址，如图：
\n![\"vite-dev-server-output\"](\"https://images.mtfh.cc/2025/07/14-5ac25ceb641c3224fec584aa868cca2b.png\")
![\"vue3-start-up\"](\"https://images.mtfh.cc/2025/07/14-d83e6d19d6585a7ca115b157ea9d032b.png\")
没问题后就可以直接提交内容到 Git 仓库了。初始化 Git 仓库并创建提交：
\n# 初始化版本仓库\ngit init\n\n# 添加项目下的文件到暂存区\ngit add -A\n\n# 提交修改\ngit commit -m \"Init: vboxes-ui\"推送内容到远程仓库：
\n\n\nGithub、Gitee、GitCode、GitLab or Gitea ？
\n如果不考虑网络因素，当然首选 Github。Git 私有仓库方案 Gitea 比较好，GitLab 功能丰富，但也吃资源啊。
\n
先在平台创建空的版本仓库，拷贝仓库地址，为本地仓库添加远程仓库，再推送本地分支
\n# 添加远程仓库\n# git remote add <remote name> <remote url>\ngit remote add origin git@gitea.mtfh.cc:mtfhx/vboxes-ui.git\n\n\n# 关联远程分支(当前分支首次推送时)\n# git push -u <remote name> <branch name>\n# 同： git push --set-upstream <remote name> <branch name>\ngit push -u origin main \n\n# 推送当前分支\n# git push <remote name> <branch name>\n# git push <remote name> [<current branch>]\n# git push [<default remote>] [<current branch>]\ngit pushtree -a -L 2 --prune -P 'node_modules|.*|*'\n\n# 输出：\n# .\n# ├── .editorconfig\n# ├── env.d.ts\n# ├── eslint.config.ts\n# ├── .gitattributes\n# ├── .gitignore\n# ├── index.html\n# ├── node_modules\n# │ └── .yarn-integrity\n# ├── package.json\n# ├── .prettierrc.json\n# ├── public\n# │ └── favicon.ico\n# ├── README.md\n# ├── src\n# │ ├── App.vue\n# │ └── main.ts\n# ├── tsconfig.app.json\n# ├── tsconfig.json\n# ├── tsconfig.node.json\n# ├── vite.config.ts\n# ├── yarn.lock\n# └── .yarnrc.yml项目文件说明（由 ChatGPT 生成）：
\n| 路径 / 文件 | 说明 |\n|
\n", "image": "https://images.mtfh.cc/2025/07/14-946edf17192bb21eae5871373a34aa4b.png", "date_published": "2025-07-14T06:02:09.000Z", "date_modified": "2025-10-29T08:50:15.000Z", "authors": [], "tags": [ "前端", "Vue" ] }, { "title": "基于 Vue3 的 VBoxes-UI 搭建", "url": "https://blog.mtfh.cc/posts/%E5%89%8D%E7%AB%AF/VBoxes%20UI/%E5%9F%BA%E4%BA%8E%20Vue3%20%E7%9A%84%20VBoxes-UI%20%E6%90%AD%E5%BB%BA.html", "id": "https://blog.mtfh.cc/posts/%E5%89%8D%E7%AB%AF/VBoxes%20UI/%E5%9F%BA%E4%BA%8E%20Vue3%20%E7%9A%84%20VBoxes-UI%20%E6%90%AD%E5%BB%BA.html", "summary": "基于 Vue3 的 VBoxes-UI 搭建 vboxes-ui 是 vboxes 服务的网页 UI 负责展示从 vboxes 服务请求到的环境数据。而 vboxes 通过分析目录下的所有 .box 文件并将其归类到不同的环境当中去，然后提供不同的接口供网页的数据查询与展示、Vagrant CLI 的数据请求和 .box 文件下载。 vboxe-ui ...", "content_html": "\nvboxes-ui 是 vboxes 服务的网页 UI 负责展示从 vboxes 服务请求到的环境数据。而 vboxes 通过分析目录下的所有 .box 文件并将其归类到不同的环境当中去，然后提供不同的接口供网页的数据查询与展示、Vagrant CLI 的数据请求和 .box 文件下载。
vboxe-ui 采用的是 Vue3 框架，配合 Schade-Vue 和 TailwindCSS 的组件与样式创建的一个简单前端网页，目前还处在开发中。
\n\n\n完整项目开发周期可能持续一个月以上，设置一些关键节点能够很好的维持项目的推进。比如完成 vboxes 关键接口或完成 vboxe-ui 创建（等待接口测试）等等。设置节点也方便记录与总结。一口气完成中大型的项目的开发目前来看有点吃力，不仅考验耐力也考验体力[汗]。
\n
以下是已完成内容的实现记录。
\n通过接口请求到的数据是一组相同的数据格式，根据 Vue 的设计思路只需要定义其中一个显示组件，完整数据集的展示直接套用这个组件即可。VMBoxCard 需要展示数据格式参考如下：
\n{\n \"name\": \"ubuntu-focal-desktop-en-qt\",\n \"date\": 1750553587,\n \"author\": \"vboxes\",\n \"description\": \"Ubuntu Focal Desktop Environment for Qt Development\",\n \"site\": \"http://127.0.0.1:9321/api\",\n \"url\": \"http://127.0.0.1:9321/api/ubuntu-focal-desktop-en-qt\",\n \"vagrantfile\": \"Vagrant.configure(\\\"2\\\") do |config|\\n config.vm.box = \\\"ubuntu-focal-qt\\\"\\n config.vm.box_url = \\\"http://127.0.0.1:9321/api/ubuntu-focal-desktop-en-qt\\\"\\n\\n config.vm.provider \\\"virtualbox\\\" do |vb|\\n vb.gui = true\\n vb.cpus = 4\\n vb.memory = \\\"2048\\\"\\n end\\n\\n config.vm.provision \\\"shell\\\", inline: <<-SHELL\\n apt-get update\\n SHELL\\nend\"\n}通过上面的 json 数据再结合 AI 就能很轻松地搞定（实际调试和改进花了不少功夫[笑哭]）。
\n\n\nAI 可能并不能一次就能做到我们想要的，需要提供必要的提示，然后修改测试。所以 AI 尚且还不能完全接替人工开发。如果从开发者的角度考虑，反而能够为开发者节省大量的时间——不论是设计、实现、问题的排查都比传统的人工加搜索引擎高效得多。因此它更像是个更高级的搜索引擎。
\n
为了优化 VMBoxCard 组件对 Vagrantfile 文件内容的展示和业务需求（代码拷贝和下载），实现了 CodeBlock 组件，完整的 VMBoxCard 组件代码如下：
\n<template> \n <div \n class=\"rounded-2xl shadow p-6 bg-white space-y-4 cursor-pointer hover:ring-2 hover:ring-blue-300 transition\" \n @dblclick=\"expanded = !expanded\" \n > \n <h2 class=\"text-2xl font-semibold text-gray-800\">{{ box.name }}</h2> \n \n <div class=\"flex flex-wrap items-center gap-x-6 text-sm text-gray-500\"> \n <div class=\"flex items-center gap-1\"> \n <UserRound class=\"inline-block w-4 h-4 mr-1\" /> {{ box.author }} \n </div> \n <div class=\"flex items-center gap-1\"> \n <Calendar class=\"inline-block w-4 h-4 mr-1\" /> {{ formattedDate }} \n </div> \n <div class=\"flex items-center gap-1\"> \n <Globe class=\"inline-block w-4 h-4 mr-1\" /> \n <a :href=\"box.site\" target=\"_blank\" class=\"underline break-all\">{{ box.site }}</a> \n </div> \n </div> \n \n <p class=\"text-gray-600 leading-relaxed\">{{ box.description || '无描述信息' }}</p> \n \n <p class=\"text-xs italic text-gray-400\">💡 单击卡片查看或隐藏 Vagrantfile</p> \n <Transition name=\"fold\"> \n <div \n v-if=\"expanded\" \n class=\"overflow-hidden transition-all duration-500 ease-in-out\" \n > \n <CodeBlock :code=\"box.vagrantfile\" language=\"ruby\" filename=\"Vagrantfile\" /> \n </div> \n </Transition> \n </div> \n</template> \n \n<script setup lang=\"ts\"> \nimport { ref, computed } from 'vue' \nimport CodeBlock from './CodeBlock.vue' \nimport { UserRound, Calendar, Globe } from 'lucide-vue-next' \n \nconst { box } = defineProps({ \n box: Object \n}) \n \nconst expanded = ref(false) \n \nconst formattedDate = computed(() => { \n const date = new Date(box.date * 1000) \n return date.toLocaleDateString() \n}) \n</script>通过向服务请求数据，然后使用 v-for 关键字迭代数据集即可，向 VMBoxCard 传递数据可以通过 :box 属性完成，该属性已在 VMBoxCard 组件中定义。
因为接口比较简单，直接使用 fetch() ，内容如下：
<template> \n <div class=\"grid gap-6\">\n <VMBoxCard v-for=\"box in boxes\" :key=\"box.name\" :box=\"box\" />\n </div>\n</template>\n\n<script setup lang=\"ts\">\nimport { ref } from 'vue' \nimport VMBoxCard from './VMBoxCard.vue' \n \nconst boxes = ref<object[]>([]) \n \nfetch('/api') \n .then((response) => response.json()) \n .then((data) => { \n boxes.value = data.infos \n }) \n .catch((error) => console.error('Error fetching data:', error)) \n</script>测试过程中接口地址开和发服务器地址不一致（二者非同一个进程，甚至不在同一台设备上），会出现浏览器同源策略的限制，导致无法获取到接口数据情况。解决同源限制的方式有很多，这里使用的是代理的方式。
\n编辑 vite.config.js 配置文件，添加指向接口服务反向代理即可解决该问题了。配置文件示例如下：
\nimport { defineConfig } from 'vite'\n// 省略的包引用\n \n// https://vite.dev/config/ \nexport default defineConfig({ \n // 省略的内容\n \n server: { \n proxy: { \n '/api': { \n target: 'http://127.0.0.1:9321', \n changeOrigin: true, \n //rewrite: (path) => path.replace(/^\\/api/, ''), \n } \n } \n } \n})运行服务端，等待数据解析完成，最终呈现效果如下
\n![\"Screenshot](\"https://images.mtfh.cc/2025/07/10-e7a528f1e37cd2964eb5f2e0569a8110.png\")
题外话——尝试使用模版文件来启动环境，成功运行 [开心]。
\n![\"Screenshot](\"https://images.mtfh.cc/2025/07/10-0e49ef5b791ce21e2ff2cec5b3e25fea.png\")
目前的网页部分页仅仅只是完成了基础信息的展示，虽然网页端的核心功能仅限于数据展示，但必然不仅仅是列表信息，除此之外还有搜索与过滤、帮助、文件列表和 .box 文件下载。这只是开始，更多功能还需 vboxes 服务的配合来完成。
\n在此之前博客关于页内容始终是空白的，刚好自己也有查看博客改进记录的想法。「Vuepress Theme Hope」主题中的时间线功能仅展示文章发布历史，但是我希望能够看到博客修改记录（也就是 Git 提交历史），方便我快速浏览整个网站所做的修改。虽然 Gitea 本来就可以查看历史，但是把需要关注的内容收集到一块岂不更好？同时还能填补关于页的空白，何乐不为？
\n在 .vuepress 目录里创建 plugins 目录用于存放所有的插件目录（目前只有一个）。然后创建 git-history 目录，这个目录里所有文件便是该插件的全部内容了。完成后的目录结构如下：
\n![\"Screenshot](\"https://images.mtfh.cc/2025/05/31-e019b94b2bf2bb025ca510fa3093b85e.png\")
git-history 目录下的 index.ts 文件，提供插件的定义和导出。内容如下:
\n// src/index.ts\nimport { path } from '@vuepress/utils';\nimport type { Plugin } from '@vuepress/core';\nimport { prepareGitData } from './prepareGitData.js';\nimport pathModule from 'path';\n\nconst OUTPUT_FILE = pathModule.resolve(__dirname, './git-data.json');\n\nconst gitHistoryPlugin = (): Plugin => (app) => {\n return {\n name: 'vuepress-plugin-git-history',\n\n onPrepared() {\n prepareGitData(app.dir.source(), OUTPUT_FILE);\n },\n\n clientConfigFile: path.resolve(__dirname, './client/clientConfig.ts'),\n };\n};\n\nexport default gitHistoryPlugin;clientConfig.ts 文件用于注册 Vue 组件，并向 Vue 组件提供历史数据。大致内容如下：
\n// src/client/clientConfig.ts\nimport { defineClientConfig } from '@vuepress/client';\nimport RepoHistory from './components/RepoHistory.vue';\nimport gitData from '../git-data.json';\n\nexport default defineClientConfig({\n enhance({ app }) {\n app.component('RepoHistory', RepoHistory);\n app.provide('gitData', gitData);\n }\n});完成上述插件定义之后，需要去 vuepress 的配置文件使用插件。.vuepress 目录里的 config.ts 内容如下：
\n// 省略其他导入\nimport gitHistoryPlugin from './plugins/git-history/index.js'\n\nexport default defineUserConfig({\n // 省略其他配置\n \n plugins: [\n gitHistoryPlugin()\n ]\n});然后便是面向 AI 编程了[笑]。
\n\n\n最初并未想到可以直接在 .vuepress 目录下直接编写插件。原计划在项目根目录创建一个名叫 vupress-plugin-git-history 的 NPM 包项目，以一个独立的软件包视角去考虑这个问题。但是这样发现如何本地测试代码成为关键问题。参考了别人的指导并分析 tsconfig.json 配置之后发现事实并不需要如此麻烦。
\n\n\"include\": [\n \"src/.vuepress/**/*.ts\",\n \"src/.vuepress/**/*.vue\"\n],这两段内容告诉我放在 .vuepress 下的任何 Ts 和 Vue 组件都会被解析。将测试代码移动到 .vuepress 目录之后，是能够奏效的。
\n
版本历史插件核心功能便是展示博客仓库主分支的提交历史，并过滤掉文章相关的提交历史。另外方便查看具体的文件修改，提供了 Gitea Commit 超链接。具体的功能列表如下：
\n接下来详细介绍功能实现细节。每一个功能的前提都需要完整的提交记录，这点在之前给官方的 git 插件打补丁时有所了解。通过 node 执行相应的 git 命令可以很轻松地获取完整的提交记录，然后就是解析和过滤了，这个先不作具体分析。
\n解析出的数据首先存到 json 文件中去，然后 Vue 组件通过「客户端配置」将数据导入。查看 index.ts 和 clientConfig.ts 可以知道，插件调用 prepareGitData() 函数将数据写到指定的 json 文件，然后客户端调用 app.provide() 将数据提供给组件。Vue 组件内容如下：
<template>\n <div class=\"history-container\">\n <h1>Version History</h1>\n <div class=\"timeline\">\n <div v-for=\"(group, index) in groupedCommits\" :key=\"index\" class=\"timeline-group\">\n <div class=\"timeline-label\">{{ group.label }}</div>\n <div v-for=\"commit in group.commits\" :key=\"commit.hash\" class=\"timeline-entry\">\n <div class=\"commit-dot\"></div>\n <div class=\"commit-content\">\n <a class=\"commit-message\" target=\"_blank\" :href=\"`${gitData.repoUrl}/commit/${commit.hash}`\">{{ commit.message.short }}</a>\n <div class=\"commit-meta\"> {{ commit.author }} · {{ formatDate(commit.date) }}</div>\n <ul v-if=\"commit.message.description\">\n <li v-for=\"item in commit.message.description\"> {{ item }}</li>\n </ul>\n </div>\n </div>\n </div>\n </div>\n </div>\n</template>\n\n<script lang=\"ts\" setup>\nimport { computed, inject } from 'vue'\nimport type { GitCommit, GitData } from '../../node/prepareGitData.js'\n\nconst gitData = inject<GitData>('gitData', { repoUrl: \"\", commits: [] });\n\nconst formatDate = (dateStr) => {\n const date = new Date(dateStr)\n return date.toLocaleDateString()\n}\n\nconst groupedCommits = computed(() => {\n const groups = {}\n for (const commit of gitData.commits) {\n const year = new Date(commit.date).getFullYear()\n if (!groups[year]) groups[year] = []\n groups[year].push(commit)\n }\n return Object.entries(groups)\n .sort((a, b) => b[0] - a[0]) // 倒序\n .map(([year, commits]) => ({\n label: year,\n commits\n }))\n})\n</script>Vue 组件主要两件事儿，对提交的记录按年份分组；拼接 Gitea Commit 超链接。知道需要哪些数据之后，再来看 prepareGitData.ts 如何定义并解析数据。prepareGitData.ts 代码及解析如下：
\n提交记录的数据定义（应该把它们单独拿出来）。
\nexport interface GitMessage {\n tag: string;\n short: string;\n description: string[];\n}\n\nexport interface GitCommit {\n hash: string;\n author: string;\n date: string;\n message: GitMessage;\n}\n\nexport interface GitData {\n repoUrl: string;\n commits: GitCommit[];\n}获取远程仓库地址，并将 git 协议转换为 https。这里可以改进一下先判断当前协议，再考虑需不需要转换。
\nimport { execSync } from 'child_process';\n\nfunction getRemoteRepoUrl(repo: string) {\n try {\n const logs = execSync(\n `git remote get-url ${repo}`,\n {encoding: 'utf-8'}\n );\n const match = logs.trim().match(/^git@([^:]+):(.+?)\\.git$/);\n\n const domain = match[1];\n const path = match[2];\n return `https://${domain}/${path}`;\n }\n catch (e) {\n return \"\";\n }\n}获取提交记录并以 GitCommit 数组形式返回。首先获取每个记录时需要完整哈希，用于拼接 Gitea Commit 超链接。
\n其次由于每条提交记录需要有详细描述，因此在分割时就不能简单地把换行符作为分隔符了，这里参考了官方 git 插件的做法。
\n然后详细描述在记录的时候约定使用 Markdown 形式的无序或有序列表，这里为了方便组件渲染，将它拆解为字符串数组。需要注意的是详细描述可能为空字符串，这时的 description 字段应该是空数组，而不是 [""] 。
最后根据提交描述约定，比如 “Posts: 2025-04-09 14:03:58” 、“Feature: 关于页添加版本历史” ，使用 ": " 分隔符拆解出提交类型和描述信息即可。
\nimport { execSync } from 'child_process';\n\nconst SPLIT_CHAR = '[GIT_LOG_COMMIT_END]';\nconst RE_SPLIT = /\\[GIT_LOG_COMMIT_END\\]$/;\n\nfunction getRepoHistory(): GitCommit[] {\n try {\n const logs = execSync(\n `git log --pretty=format:\"%H|%an|%ad|%s|%b${SPLIT_CHAR}\" --date=short`,\n {encoding: 'utf-8'}\n );\n return logs\n .replace(RE_SPLIT, '')\n .split(`${SPLIT_CHAR}\\n`).map(line => {\n const [hash, author, date, message, content] = line.split('|');\n const description: string[] = content === \"\" ? [] : content.trim().split('\\n');\n const [tag, short] = message.split(': ');\n return {hash, author, date, message: {tag, short, description}};\n });\n } catch {\n return [];\n }\n}过滤掉文章记录以及写到文件。根据前面提到的「描述约定」，只需要筛选出非 Posts 提交类型即可。
\n\nimport fs from 'fs';\n\nfunction filterPosts(commits: GitCommit[]): GitCommit[] {\n return commits.filter(commit => commit.message.tag?.toLowerCase() !== 'posts');\n}\n\nexport function prepareGitData(sourceDir: string, outputFilePath: string) {\n const gitData: GitData = { repoUrl: getRemoteRepoUrl(\"origin\"), commits: filterPosts(getRepoHistory()) };\n fs.writeFileSync(outputFilePath, JSON.stringify(gitData, null, 2));\n}最后得到的 json 数据大致如下：
\n {\n \"repoUrl\": \"https://gitea.mtfh.cc/mtfhx/vuepress-starter\",\n \"commits\": [\n {\n \"hash\": \"b153bf72c70712a856d2a32983d6b3069c770394\",\n \"author\": \"Happilys\",\n \"date\": \"2024-11-12\",\n \"message\": {\n \"tag\": \"Update\",\n \"short\": \"删除一些不需要的内容\",\n \"description\": [\n \"1. 删除示例文件\",\n \"2. 删除一些不需要的注释\",\n \"3. 取消导航栏自动隐藏功能\",\n \"4. 先不使用搜索功能\"\n ]\n }\n }\n ]\n}至此这个插件所需要的功能基本完成。
\n过去我理解的是一个完整的作品，必然需要成体系化的打包出来。比如说这个插件，我就应该将它作为一个独立的插件打包成一个 npm 包，后续迭代都基于这个 npm 包。但工作几年后，有很多软件、作品并不能走完完整的生命周期。有时候一个工具可能只是单纯的几行代码，想起来的时候就拷贝过来，后来随着需求和技术的迭代也许再也用不上了。这种情况下，去把这些代码打包成插件或软件，便显得非常多余了。
\n因此在这件事上，我会改变过去的思维习惯，以需求为核心——关注功能本身吧。至于需不需要打包出来，如果这玩意真的能够被大多数人所认可，再打包也不迟。
\n首先 UI 这块不满意。本来计划等到 UI 完善之后再发布，但是不论是 UI 设计和实现上自身能力都不能达到自己所期望的样子，如果任何事情都等到自己达到相应的能力再去执行的话，就会失去很多机会——最现实的问题就是时间线会无限拉长，最后导致计划「难产」。索性就以当下的状态展示出来，给自己时间学习然后再去改进。
\n当下历史记录并不多，因此随手划一下就到底了，也就不需要分页或懒加载的方式来应对数据问题。但是将来修改的记录变多，不管是 UI 交互上还是背后的数据处理上都需要做相应的改进。像翻最早的记录要划啦半天，加载数据需要耗费数秒时间这些事是不能够的。数据的积累可能需要半年至一年的时间吧，所这件事不急。
\n开头的 「Version History」看起来挺扎眼的。博客的默认语言是中文，但总有许多英文出现的地方。一些地方是固定内容不作翻译，但还有很多地方其实是需要翻译为中文的。对了，博客目前没做国际化支持，所以语言方面都挺随意的。后续不管是插件还是博客本身，需要对语言进行统一管理，至少支持中英两种语言支持。
\n「Anki 是一款让记忆变得轻而易举的软件。与传统学习方式相比，它的效率要高得多，你可以大幅缩短学习时间， 或者显著扩充学习量。」—— 选自 Anki 中文文档，更多内容参考这里。
\n考虑到将来学习任务依赖该软件来辅助记忆。PC 端制作卡片，移动端学习，如果仅仅依靠手动导出再导入的话就比较麻烦了。因此选择部署同步服务来完成任务，应用启动就会自动同步数据，可以节省很多时间。
\nAnki 官方免费的同步服务 Anki Web，不过有时间限制——在一段时间不使用的话，就会清除数据。以下为服务部署大致流程：
\n根据官方文档描述，Anki 的同步服务和客户端绑定在一起的，拥有 PC 客户单即可使用同步服务。下载 Anki Linux 平台客户端，Anki 最新版本 2.25.04，但是对 GLIBC 版本要求比较高，Rocky 9 的 GLIBC 版本为 2.34
\n![\"compare-glibc-version\"](\"https://images.mtfh.cc/2025/04/09-ee13d1628bd662fc5009bb27fb2857dd.png\")
所以这里选择倒退一个次版本号使用 2.24.11，Linux 平台有 Qt5 和 Qt6 两个版本，都可以。安装包默认使用 zstd 压缩的，因此需要先安装 zstd ，没有 tar 命令的话也要安装 tar
\n# 安装 zstd 和 tar\nsudo dnf install -y zstd tar\n\n# 解压软件包\ntar -Izstd -xvf anki-24.11-linux-qt5.tar.zst直接运行 Anki 会出现缺少库的问题，安装 X11 Server 即可。Linux 下的桌面环境一般是由 X11 提供的（除此之外还有 Wyland），而部署的服务镜像一般不带桌面环境。
\nsudo dnf install -y xorg-x11-server-Xorg\n\n\n anki-missing-libgl-dependency 如果参考上面的报错，开始想到的是缺少 libGL ， 安装
\nmesa-libGL就可以搞定。但是再次执行依然缺库，看到缺少的库名反倒是提醒了我。\n anki-missing-libXcomposite-dependency 当我再次在虚拟机中测试的时候，缺少的库可能不只有这两个，所以实际部署的时候还需要根据实际情况来判断
\n想把同步服务给拿出来，就不用安装 X11 Server 了。
\n
执行解压包内自带的安装脚本，默认安装路径在 /usr/local/share，可执行文件在 /usr/local/bin
\n![\"anki-missing-libgl-dependency\"](\"https://images.mtfh.cc/2025/04/09-4e3fd836ff53c4bb3f8f10b94e78d232.png\")
![\"anki-missing-libXcomposite-dependency\"](\"https://images.mtfh.cc/2025/04/09-6e41972d8faeb8587f97832213a522e0.png\")
sudo ./install.sh官方文档中 Linux 平台服务启动方式如下：
\nSYNC_USER1=user:pass anki --syncserverSYNC_USER1 变量用来设置登录的用户名和密码，增加用户可以设置 SYNC_USER2 、SYNC_USER3 等以此类推。SYNC_HOST 和 SYNC_PORT 可以设置监听主机 IP 和端口，默认 0.0.0.0:8080 。
客户端登录设置
\n![\"login-sync-server-step-1-5\"](\"https://images.mtfh.cc/2025/04/09-cf99de54d03036eb0df00307ebd60578.png\")
![\"login-sync-server-step-6-8\"](\"https://images.mtfh.cc/2025/04/09-3fafc3ded4fff74bada13fdf43b70211.png\")
登录成功同步服务会输出如下内容
\n![\"anki-sync-server-log\"](\"https://images.mtfh.cc/2025/04/09-ed432cc9ab9b77ce7490e8b5d579e407.png\")
方便服务管理，给 Anki 写了 Systemd 配置，参考如下：
\nDescription=Anki Sync Server\nAfter=syslog.target\nAfter=network.target\n\n[Service]\nRestartSec=2s\nType=simple\nUser=anki\nGroup=anki\nWorkingDirectory=/home/anki\nExecStart=/usr/local/bin/anki --syncserver\nRestart=always\nEnvironment=SYNC_USER1=username:password SYNC_HOST=127.0.0.1 SYNC_PORT=8081\n\n[Install]\nWantedBy=multi-user.target创建好文件，放到 /etc/systemd/system 目录下即可。由于配置里的执行用户和组使用的是 anki 用户，因此启动前需要添加 anki 用户
\n# 创建用户及家目录（创建用户时默认创建同名用户组）\nuseradd -m anki服务相关的控制命令
\n# 启动服务\nsystemctl start anki\n\n# 服务状态\nsystemctl status anki\n\n# 停止服务\nsystemctl stop anki\n\n# 激活/禁用开机自启\nsystemctl enable anki\nsystemctl disable anki\n\n# 查看服务日志\njournalctl -u anki站点内的所有服务都是通过 Ningx 代理出去的，这样可以做到将一个顶级域名下的各二级域名映射到不同的服务上去，不同的服务由端口区分。比如 gitea.mtfh.cc 对应的就是 Gitea 服务，blog.mtfh.cc 对应的就是当前博客。另外还可以通过 Nginx 来支持 https 协议。
\nNginx 配置参考
\nserver {\n listen 80;\n server_name anki.mtfh.cc;\n return 301 https://$server_name$request_uri;\n}\n\nserver {\n listen 443 ssl;\n server_name anki.mtfh.cc;\n\n ssl_certificate /etc/nginx/certificates/anki.mtfh.cc.pem;\n ssl_certificate_key /etc/nginx/certificates/anki.mtfh.cc.key;\n\n ssl_session_timeout 5m;\n ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE:ECDH:AES:HIGH:!NULL:!aNULL:!MD5:!ADH:!RC4;\n ssl_protocols TLSv1 TLSv1.1 TLSv1.2;\n ssl_prefer_server_ciphers on;\n\n location / {\n proxy_pass http://127.0.0.1:8081;\n proxy_set_header Host $host;\n proxy_set_header X-Real-IP $remote_addr;\n proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;\n proxy_set_header X-Forwarded-Proto $scheme;\n }\n}SSL 证书可以去购买或者去某某云白嫖吧，Couldflare 也有。设置完成后客户端中的自托管服务设置修改为对应的域名即可。
\n上一篇提到 plugin-git 获取 git 子模块信息时，不能正确获取时间问题。于是根据源码对 plugin-git 插件进行一番修改之后，成功获取文章的修改时间信息。在此对 yarn 补丁功能的使用做些记录。
\n为某个软件包创建补丁，支持二级包名，比如 @vuepress/plugin-git 。它会提取软件包中的文件到临时目录，用户在临时目录修改之后，使用 patch-commit 子命令提交修改。
yarn patch <package>生成 patch 文件并注册到 package.json 文件当中，path 参数为上条命令创建的临时目录。除了 package.json ，生成的补丁文件也需要提交到版本仓库。
yarn patch-commit -s <path>更新补丁，该命令不同于第一条命令（不带 -u 参数），生成临时目录中的文件会根据已有的补丁文件作出相应的修改。而不带 -u 参数生成的临时目录中的文件则是软件包原本的样子，即使 package.json 包含补丁信息。
\nyarn patch -u <package>这是一个具体的打补丁的例子，其他软件包可以参考这个方法。相关步骤如下：
\n第一步，修改代码只需要在 node_modules 目录找到 plugin-git 的软件包目录，然后修改其中的文件即可。这些修改能够直接生效，然后调试、修改、再调试……
\n![\"modify-plugin-git-source-code\"](\"https://images.mtfh.cc/2025/04/01-ec6c334f937492a219cb712d16848c28.png\")
第二步，准备软件包——执行下面的命令，会把软件包放到临时目录下，软件包中的内容不会有任何修改，就是它原本的样子。
\nyarn patch @vuepress/plugin-git![\"yarn-patch-stdout\"](\"https://images.mtfh.cc/2025/04/01-262b68f5b3fadcad94b4f272b6f9201d.png\")
![\"temp-directory-source-code\"](\"https://images.mtfh.cc/2025/04/01-e3ac8ab00b106f953fb740d832becad0.png\")
第三步，提交修改——把 node_modules 中修改的文件替换到刚才生成的文件下，就可以执行下面的命令——根据临时目录中所做的修改生成 patch 文件到 .yarn/patches 目录下；在 package.json 中记录修改，当执行 yarn install 时会根据 package.json 中的记录自动修改文件。最后应用补丁（只不过临时目录的修改也是从 node_modules 中拷贝过去的——不会发生变化罢了）。
# 拷贝文件\ncp node_modules/@vuepress/plugin-git/lib/node/utils/getUpdatedTime.js /private/var/folders/tf/vp9nb9m13ys_c96f3jkkdgx40000gn/T/xfs-7d8e5614/user/lib/node/utils/\n\n# 提交更新\nyarn patch-commit -s /private/var/folders/tf/vp9nb9m13ys_c96f3jkkdgx40000gn/T/xfs-7d8e5614/user\n\n# 应用修改\nyarn install![\"patchfile-and-package-dot-json\"](\"https://images.mtfh.cc/2025/04/01-129c0c66409eed2c935188eb87ed8dad.png\")
第四步，更新补丁有两种方式，第一种是在已有的修改上再进行修改；第二种则是无视已经做过的修改，直接基于原有的内容修改。
\n先讨论第一种方式。在完成第三步之后，如果需要改进前面的内容，可以执行以下命令。生成的临时目录中的文件内容是根据前面操作修改过的内容。
\nyarn patch -u @vuepress/plugin-git同上面步骤提交之后，package.json 会更新原来记录和生成一个新的补丁文件。
\n![\"patch-update\"](\"https://images.mtfh.cc/2025/04/01-5bf15f9ac75e91395a690dd75720fa65.png\")
第二种方式和软件初次打补丁方式相同，但是在提交更新前需要清除现有的补丁（记得备份 node_modules 中修改过的文件），否则部署时就会报错。
\n![\"yarn-apply-patch-error\"](\"https://images.mtfh.cc/2025/04/01-5e3ac6b44d4a53712a02281295490e91.png\")
删除掉 package.json 文件中 resolutions 字段对应的内容，再执行 yarn install 即可清除补丁，另外 .yarn 目录中的补丁也应该同步删除。
使用 Gitea Actions 来自动化部署 Vuepress 二月份已经整理出来，但部署的时候一直存在文章修改时间在同一天的问题。
\n![\"time-issue-on-git-shallow-copy\"](\"https://images.mtfh.cc/2025/03/20-e768c2ffbe9b8c3ab0a1352a835a799d.png\")
另外 Vuepress 中的 plugin-git 插件是不能够获取 git 子模块中的文件修改时间，只能自己查看源码，打补丁。Vuepress 初始设计也许就没有计划给文档的内容独立出一个（私有）版本仓库，可是我希望将博客的主体框架和内容分开，于是只好自己实现了。第一版修改的内容如下
\ndiff --git a/lib/node/utils/getCommits.js b/lib/node/utils/getCommits.js\nindex 18e0f5602df72dec54020f4847d34ace1c309e0d..1c19ce921ad2d127213c78a499a5e8d89728bcb3 100644操作系统 Rocky Linux 9
\n安装 Git、 Node 环境和 yarn4+
\nsudo dnf install -y git\n\nsudo dnf module install -y nodejs:22\n\nsudo npm install -g corepack\n\ncorepack enable\n\nyarn init -2\n\nnpm 默认全局安装位置没权限，但也不建议使用
\nsudo命令（待解决）
yarn init -2 初始化失败，可以采取离线安装
下载 Act Runner 二进制包
\n获取注册令牌
\n![\"gitea-act-runner-registration-token\"](\"https://images.mtfh.cc/gitea-act-runner-registration-token.png\")
Act Runner 一共有三个注册级别：实例级别、组织级别、存储库级别。这里用存储库级别，因为这个 Act Runner 当前仅用于 Vuepress 的构建和部署任务。不同注册级别区别如下：
\n创建配置文件，注册 Runner 并运行
\n# 生成配置\n./act_runner generate-config > config.yaml\n\n# 注册 Runner\n./act_runner register --no-interactive --instance https://gitea.mtfh.cc --token XXXxxxXXx --name vuepress-builder --config config.yaml\n\n# 启动 Runner \n./act_runner daemon --config config.yaml使用 systemd 管理 Act Runner， 配置示例
\n[Unit]\nDescription=Gitea Act Runner\nAfter=syslog.target\nAfter=network.target\n\n[Service]\nRestartSec=2s\nType=simple\nUser=happilys\nGroup=happilys\nWorkingDirectory=/home/happilys\nExecStart=/home/happilys/act_runner daemon --config /home/happilys/config.yaml\nRestart=always\n\n[Install]\nWantedBy=multi-user.target创建 .gitea/workflow/xxx.ymal 文件（Gitea 从该文件中获取任务，Action 语法同 Github Actions）如下：
name: Build docs automatically \nrun-name: ${{ gitea.actor }} 🚀 \non: \n push: \n branches: \n - main \n \njobs: \n Build-Docs-and-Deploy-It: \n runs-on: linux-amd64 \n steps: \n - name: Check out repository code \n uses: https://gitea.com/actions/checkout@v4 \n with: \n ssh-key: ${{ secrets.DEPLOYKEY }} \n ssh-known-hosts: ssh-keyscan gitea.mtfh.cc \n submodules: true \n - run: yarn install \n - run: yarn docs:build \n - run: cp -r ./src/.vuepress/dist/* /var/www/html\n\n\n
actions/checkout@v4由于某些原因不能直接从 Github 获取，根据官方文档使用 Gitea 官方仓库
关于脚本中 secrets.DEPLOYKEY 变量的配置如下：
ssh-keygen 一路回车ssh-keygen -t ed25519 -C \"deploy@mtfh.cc\" -f ~/Downloads/id_ed25519![\"gitea-deploy-ssh-key-gen\"](\"https://images.mtfh.cc/gitea-deploy-ssh-key-gen.png\")
\n2. Actions 密钥管理添加密钥，添加上一步生成的私钥（文件名为 id_rsa）
![\"gitea-actions-add-secrets\"](\"https://images.mtfh.cc/2025/02/10-cfbda933fc7e56e680a5e815ce98fa71.png\")
为需要访问的仓库添加部署密钥
\n![\"gitea-repository-add-deploy-key\"](\"https://images.mtfh.cc/gitea-repository-add-deploy-key.png\")
action/checkout@v4 如果配置 ssh-key 默认走 git 协议，所以虽然 vuepress-starter 是公开仓库，也许要添加部署密钥
![\"blog-repositories\"](\"https://images.mtfh.cc/)
提交并推送
\n![\"10-c0989361694c2500010e4e67d9c27e95.png\"](\"https://images.mtfh.cc/2025/02/10-c0989361694c2500010e4e67d9c27e95.png\")
准备安装 PicGo-Core 需要 Node 环境，使用 NVM 或二进制安装包
\n使用 npm 全局安装
\nnpm install -g picgo安装 rename-file 插件
\npicgo install rename-file添加图床设置，以七牛云为例
\npicgo set uploader根据命令行提示，完成后配置文件大致如下；插件相关配置需要手动编辑，内容同下。picgo-plugin-rename-file 配置参考
{\n \"picBed\": {\n \"uploader\": \"qiniu\",\n \"current\": \"qiniu\",\n \"qiniu\": {\n \"accessKey\": \"xxxxx-xxxxxxx-xxxxx-xxxx-xxx-xxxx-xxx\",\n \"secretKey\": \"xxxxx-xxxxxxx-xxxxx-xxxx-xxx-xxxx-xxx\",\n \"bucket\": \"notes-album\",\n \"url\": \"https://images.mtfh.cc\",\n \"area\": \"cn-east-2\",\n \"options\": \"\",\n \"path\": \"\"\n }\n },\n \"picgoPlugins\": {\n \"picgo-plugin-rename-file\": true\n },\n \"picgo-plugin-rename-file\": {\n \"format\": \"{y}/{m}/{d}-{hash}\"\n }\n}七牛云 AccessKey 和 SecretKey 获取——前往个人中心-密钥管理，新增密钥
\n![\"10-41d5158c821c899c9e5c4876f3a27d6e\"](\"https://images.mtfh.cc/2025/02/10-41d5158c821c899c9e5c4876f3a27d6e.png\")
bucket 即对象存储空间名称；url 为资源访问地址，CDN 加速域名和源站域名都可以，这里用源站域名因为 CDN 域名配置 https 要钱 🤣
![\"10-021feee7e0e78ddf01952d474677273b\"](\"https://images.mtfh.cc/2025/02/10-021feee7e0e78ddf01952d474677273b.png\")
area 存储空间区域代码，更多内容请参考存储区域_产品简介_对象存储 - 七牛开发者中心
| 存储区域 | 区域 Region ID |\n|
\n", "image": "https://images.mtfh.cc/2025/02/10-41d5158c821c899c9e5c4876f3a27d6e.png", "date_published": "2025-02-14T13:23:16.000Z", "date_modified": "2025-02-14T13:23:16.000Z", "authors": [], "tags": [] }, { "title": "Windows 远程桌面", "url": "https://blog.mtfh.cc/posts/Windows%20%E8%BF%9C%E7%A8%8B%E6%A1%8C%E9%9D%A2.html", "id": "https://blog.mtfh.cc/posts/Windows%20%E8%BF%9C%E7%A8%8B%E6%A1%8C%E9%9D%A2.html", "summary": "Windows 远程桌面 服务端 Win10 专业版 Win10 家庭版 客户端 Win10 Mac Win10远程桌面服务 Win10专业版才有远程桌面，直接到设置里开启就可以：win10-settings-remote-desktop 防火墙设置 远程桌面默认3389端口，需要授权之后才能从局域网的另一台主机登录（外网要做端口映射，没固定IP还要动...", "content_html": "\nWin10专业版才有远程桌面，直接到设置里开启就可以：![\"win10-settings-remote-desktop\"](\"https://images.mtfh.cc/win10-settings-remote-desktop.png\")
防火墙设置
\n远程桌面默认3389端口，需要授权之后才能从局域网的另一台主机登录（外网要做端口映射，没固定IP还要动态域名）。
\n![\"win10-defender-firewall\"](\"https://images.mtfh.cc/win10-defender-firewall.png\")
专业版可能是这样：
\n![\"windows-remote-desktop\"](\"https://images.mtfh.cc/windows-remote-desktop.png\")
非专业版就不能在设置里直接打开了。官方描述非专业版并不支持远程桌面，但非专业版是拥有该特性的。因此在非专业版上使用远程桌面的话就需要这个—— RDP Wrapper Library
\n![\"github-rdp-wrapper-library-release-page\"](\"https://images.mtfh.cc/github-rdp-wrapper-library-release-page.png\")
C:\\Program Files\\RDP Wrapperinstall.bat，然后执行update.bat，完成之后运行RDPConf.exe![\"rdp-wrapper-configuration\"](\"https://images.mtfh.cc/rdp-wrapper-configuration.png\")
RDPCheck.exe测试NOTE
\nwin+r --> mstsc![\"windows-remote-desktop-mstsc\"](\"https://images.mtfh.cc/windows-remote-desktop-mstsc.png\")
![\"apple-appstore-microsoft-remote-desktop\"](\"https://images.mtfh.cc/apple-appstore-microsoft-remote-desktop.png\")
准备：
\n\n创建虚拟机：设置虚拟机名称，选择虚拟机存储路径，选择准备好的镜像
\n\n\n虚拟机名称随意，这里使用的命名规则为
\n<系统名>-<版本号>-<环境(server/desktop)>-<语言(zh/en)>-prototype
\n虚拟机存储路径保证拥有足够的空间，可以在创建时修改或者修改全局设置
![](\"http://images.mtfh.cc/packaging-generic-linux-env-01.png\")
硬件设置：内存 2G，核心数分配 2 核即可
\n\n核心数分配单核也可以，不过部分 Linux 系统会出现出现内核 Panic 无法启动的情况
\n
![](\"http://images.mtfh.cc/packaging-generic-linux-env-02.png\")
硬盘设置：动态分配 50G
\n\n50G 的空间主要用来安装应用并不承担用户数据负载，实际的数据在使用过程中直接与宿主机共享
\n
\n❓Windows 与 Linux 虚拟机文件共享时文件系统不一致问题
![](\"http://images.mtfh.cc/packaging-generic-linux-env-03.png\")
概览：
\n![](\"http://images.mtfh.cc/packaging-generic-linux-env-04.png\")
启动虚拟机进入系统安装界面
\n", "image": "http://images.mtfh.cc/packaging-generic-linux-env-01.png", "date_published": "2024-11-12T14:44:49.000Z", "date_modified": "2024-11-29T01:43:22.000Z", "authors": [], "tags": [] }, { "title": "Win 11 或 Win 10 开启 SSH 远程", "url": "https://blog.mtfh.cc/posts/Win%2011%20%E6%88%96%20Win%2010%20%20%E5%BC%80%E5%90%AF%20SSH%20%E8%BF%9C%E7%A8%8B.html", "id": "https://blog.mtfh.cc/posts/Win%2011%20%E6%88%96%20Win%2010%20%20%E5%BC%80%E5%90%AF%20SSH%20%E8%BF%9C%E7%A8%8B.html", "summary": "Win 11 或 Win 10 开启 SSH 远程 一、以管理员身份运行 Powershell 以获取当前是否安装 SSH 服务 执行可能结果如下： 二、以管理员身份执行如下命令来安装 SSH 服务 执行结果： 三、启动 SSH 服务，并开放对应端口 四、将默认的 CMD 改为 Powershell !!! Note：此命令需要保证 Powershel...", "content_html": "\n一、以管理员身份运行 Powershell 以获取当前是否安装 SSH 服务
Get-WindowsCapability -Online | Where-Object Name -like 'OpenSSH*'执行可能结果如下：
\n![](\"http://images.mtfh.cc/win11-ssh-remote-get-windows-capability.png\")
二、以管理员身份执行如下命令来安装 SSH 服务
\n# Install the OpenSSH Server\nAdd-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0执行结果：
\n![](\"http://images.mtfh.cc/win11-ssh-remote-add-windows-capability.png\")
三、启动 SSH 服务，并开放对应端口
\n# Start the sshd service\nStart-Service sshd\n\n# Auto start, OPTIONAL but recommended:\nSet-Service -Name sshd -StartupType 'Automatic'\n\n# Confirm the Firewall rule is configured. It should be created automatically by setup. Run the following to verify\nif (!(Get-NetFirewallRule -Name \"OpenSSH-Server-In-TCP\" -ErrorAction SilentlyContinue | Select-Object Name, Enabled)) {\n Write-Output \"Firewall Rule 'OpenSSH-Server-In-TCP' does not exist, creating it...\"\n New-NetFirewallRule -Name 'OpenSSH-Server-In-TCP' -DisplayName 'OpenSSH Server (sshd)' -Enabled True -Direction Inbound -Protocol TCP -Action Allow -LocalPort 22\n} else {\n Write-Output \"Firewall rule 'OpenSSH-Server-In-TCP' has been created and exists.\"\n}四、将默认的 CMD 改为 Powershell
\n\n!!! Note：此命令需要保证 Powershell 7 已安装并且路径正确或自行替换正确的 Powershell 路径
\n
New-ItemProperty -Path \"HKLM:\\SOFTWARE\\OpenSSH\" -Name DefaultShell -Value \"C:\\Program Files\\PowerShell\\7\\pwsh.exe\" -PropertyType String -Force执行结果：
\n![](\"http://images.mtfh.cc/win11-ssh-remote-new-item-property.png\")
管理员用户公钥需放置在服务器上的一个名为 administrators_authorized_keys 的文本文件中，此文件存在于 C:\\ProgramData\\ssh ， 并且该文件上的 ACL 需要配置为仅允许访问管理员和系统。
icacls.exe \"C:\\ProgramData\\ssh\\administrators_authorized_keys\" /inheritance:r /grant \"Administrators:F\" /grant \"SYSTEM:F\"sudo sed -e 's|^metalink=|#metalink=|g' \\\n -e 's|^gpgcheck=1|gpgcheck=0|g' \\\n -e 's|^baseurl=http://repo.openeuler.org|baseurl=https://mirrors.nju.edu.cn/openeuler|g' \\\n -i.bak /etc/yum.repos.d/openEuler.repo\nsudo dnf makecachesudo dnf update -y\nsudo reboot重启后删除老内核
\nsudo dnf install -y tar make gcc gcc-c++ kernel-devel\n\n# VBoxAddition runtime\nsudo dnf install -y libXt libXmu点击 VirtualBox 设备菜单栏中 “安装增强功能”
\nsudo mount /dev/cdrom /srv && cd /srv\nsudo ./VBoxLinuxAdditions.run