Jamaisvu's blog

Hugo API：快速发布你的hugo文章!

Mon, 06 Oct 2025 03:00:08 +0800

这是博主开源到github的另一个项目，此处贴的是使用文档。如果是跟我一样使用hugo建站并且苦于如何发布的小伙伴们，我强力推荐这个api，你会用上的！！

✿✿✿来支持一波吧✿✿✿

👇👇👇

grayfalcon666/hugo_api: Quickly publish posts for your Hugo blog!

preview：

一个用 Go 编写的轻量级 API 服务，支持通过 表单提交（直接复制 Markdown）快速创建 Hugo 静态博客文章，自动生成 Front Matter 并触发 Hugo 构建，无需手动操作文件或执行命令。

🌟 核心功能

发送文章与动态：
- /api/hugo/create-post
- /api/hugo/create-moment
外置config文件: 可自定义文章发布路径、密钥、api监听端口号
自动处理：
- 生成 Hugo 标准 Front Matter（标题、时间、标签、分类等）
- 自动触发 Hugo 构建，发布后立即生效

🚀 快速开始

1. 克隆仓库到本地

2. 配置 `config.json`

在项目根目录创建 config.json 文件，按实际环境填写配置：

1{
2  "api_key": "your-strong-secret-key",  
3  "hugo_content_path": "/home/user/blog/content/posts", 
4  "hugo_moment_path": "/home/user/blog/content/moments",
5  "hugo_project_path": "/home/user/blog",  
6  "hugo_exec_path": "/usr/local/bin/hugo",  
7  "listen_addr": ":8080" 
8}

3. 编译与启动

1# 编译（生成可执行文件）
2go build -o hugo-api hugo-api.go
3
4# 启动服务
5./hugo-api

后台运行

linux 写一个系统服务即可，以下为示例:

为immich配置机器学习与硬件加速

Mon, 06 Oct 2025 02:27:29 +0800

环境介绍

OS: Ubuntu 24.04.2 LTS
GPU: NVIDIA GeForce GTX 1050 Ti
immich: docker compose部署
date: 2025-10-05
network: need proxy

模型下载

下载地址： immich-app/XLM-Roberta-Large-ViT-H-14__frozen_laion5b_s13b_b90k at main

下载须知：

给下载目标路径的目录预留充足磁盘空间，>20GB。
需安装git-lfs（管理git大文件的拓展）

 1sudo apt-get install git-lfs
 2
 3df -h ~/path  # 查看仓库所在分区的空间
 4
 5#若目录下磁盘空间不足，迁移到别的目录，以下是迁移指令
 6rsync -av 原路径 目标路径
 7# `-a`：归档模式，保留文件权限、时间戳等所有属性
 8# `-v`：显示复制进度
 9
10rm -rf ~/path
11
12#断点续连
13git restore --source=HEAD :/

把下载来的模型放在clip文件夹以下的位置：

在windows上使用mihomo裸核

Fri, 03 Oct 2025 17:08:45 +0800

从简开始

相信不少人刚开始折腾内核的时候，都是一脸茫然的，要配置的内容太多，对新手不友好。所以我们从最简单的方法做起，力求先把内核跑起来，然后再慢慢拓展。

搞代理的前提是你需要去各大机场订阅节点，或者你自己拥有节点。通常机场会给你提供一个订阅链接🔗，复制下来。

下载内核

先去mihomo仓库，根据你的电脑下一个适合的内核版本（去参考官方文档），我下的是这个版本:

获取配置

在任意位置建一个文件夹，就叫mihomo吧。在该位置打开cmd，输入

1curl -k -H "User-Agent: Clash" -o config.yaml "你的订阅链接"

添加-k参数跳过证书验证（仅临时测试使用）
-H "User-Agent: Clash" 的作用是将请求头中的用户代理标识为 Clash，部分机场可能会根据此标识返回适配的配置格式。

如果机场支持连接转换成clash格式的话，此时你的mihomo文件夹下会出现一个新的config.yaml文件，打开看一下，这个就是机场给你配好的基础配置。

运行内核

是不是很简单?这个配置已经足够内核正常运行了，我们接着把它跑起来。

打开powershell，输入

1.\mihomo-windows-amd64.exe -d .\ -f config.yaml

-d .\ 用于指定程序的工作目录
-f config.yaml 用于指定配置文件路径

第一次运行需要拉取geoip文件，可能需要给powershell设置代理才能拉取成功（实在不行暂时用客户端吧，开个tun模式）

在性能管理器里检查一下，发现内核正在运行，说明内核启动成功：

开启代理

启动了内核之后的最后一步：我们要到系统设置中手动开启系统代理：

至此，我们学会了如何使用裸核mihomo开启代理，不管那些有的没的，至少我们已经可以成功运行啦。

要想在windows的终端使用代理，就在当前会话输入 set http_proxy=http://127.0.0.1:7890，如图所示：我们已经与google正常连通。

更进一步

现在我们用的完全是机场给我们的配置，当然会有很多细节处没有匹配我们的个人需求，所以我们需要自己去改进一下这个配置，当然如果你觉得这样已经够用，那么不必接着往下看。

自己写规则最主要的目的显然是为了能够让一些自己的服务器或者一些特殊地址能够直连\走代理，其实整个代理配置说白了就是 规定了谁要走直连，谁要走代理，方便我们使用代理时可以实现全自动化策略调控。

要想自己写配置，我们首先要搞懂mihomo的配置分为哪些部分，每一部分是干什么的。让我带大家初步了解一下mihomo的配置中的几个主要模块：

主要模块

proxy-providers

作用

定义 从哪里获取代理节点，支持在线订阅、本地文件等方式，是代理节点的 “源头”。

常用参数

参数	含义
`url`	代理订阅链接
`path`	订阅内容的本地保存路径
`type`	订阅类型为 `http`（常见类型还有 `file` 本地文件、`clash` 标准格式等）。
`interval`	订阅更新间隔，通常是设定`86400` 秒 = 1 天，即每天自动更新一次代理节点。

全局配置

作用

定义 mihomo 的基础运行参数、网络入口（端口）、全局模式等，是软件启动的 基础设置。

一篇讲清api与webhook

Sun, 28 Sep 2025 23:36:15 +0800

基本区别

许多小白第一次接触webhook的时候常常会与api混淆，那么我们先来看看两者的本质差别在哪：

api

一般用于用户主动发起请求，目标系统返回用户需要的数据、结果。API 用途广泛，涉及查询、修改、执行等

webhook

一般用于用户提前设置好触发条件与通知方式，当符合条件，目标系统会主动给用户推送信息、执行动作，无须用户主动查询。webhook 用途单一，仅用于事件发生时的实时推送通知。

**ps：**webhook 是 API 的一种，所有 webhook 都是 API，但不是所有 API 都是 webhook。

深入了解webhook

webhook的特征

webhook基于HTTP/HTTPS协议，以POST为主，少数用GET

常用 JSON（简洁易解析），也有用 XML、表单（form-data）的场景

下面，我们来看看webhook服务的两边各有什么特点。

provider(提供者)

**谁来当？**通常是 “被触发动作的系统”（比如企业微信消息推送、GitHub、钉钉机器人等）。

做什么？

提供一个 “专属的 webhook 地址”（就是https://qyapi.weixin.qq.com/...?key=xxx 这类 URL），作为接收请求的 “入口”；
定义 “规则”：比如请求必须用什么格式（JSON / 表单）、需要带什么验证信息（比如你的 key）、支持触发哪些动作（比如企业微信只支持 “推送消息”，GitHub 支持 “代码提交通知”）；
收到合法请求后，执行预设动作（比如企业微信把消息推到群里，GitHub 把代码更新信息发给你）。

举例：企业微信就是典型的 “webhook 提供者”—— 它给了你带 key 的 URL，规定了必须发 JSON 格式的请求，并且收到后会执行 “推送消息” 的动作。

caller(调用者)

**谁来当？**通常是 “主动触发动作的一方”（比如本地电脑、服务器脚本、第三方工具等）。

做什么？

知道提供者的 webhook 地址和规则（比如 “必须用 JSON 格式，要带 key”）；
在需要的时候，按照规则构造请求并发送（比如你用 curl 命令发消息内容）；
目的是 “让提供者执行某个动作”（而不是向提供者要数据）。

举例：你用 curl 命令发送请求时，你的本地电脑就是 “webhook 调用者”—— 你按照企业微信的规则发了 JSON 请求，目的是让企业微信执行 “推送消息” 的动作。

excalicloudstore 使用说明

Sat, 27 Sep 2025 22:55:35 +0800

由博主开发的docker镜像，现已发布在dokcer hub上 grayfalcon/excalicloudstore 通过 Docker 单机部署 和 Docker Compose 部署 两种方式，快速使用 grayfalcon/excalicloudstore 镜像（基于 Excalidraw 开发，支持 S3 兼容存储的云端绘图工具）。

一、前提条件

在开始部署前，请确保您的环境已满足以下要求：

安装 Docker Engine（参考：Docker 官方安装文档）
- Linux 系统：需确保 Docker 服务已启动（systemctl start docker）
- Windows/macOS 系统：安装 Docker Desktop 并启动
（可选）安装 Docker Compose（若使用 Compose 部署，参考：Docker Compose 安装文档）
准备好 S3 兼容存储配置（如 AWS S3、七牛云 Kodo、阿里云 OSS 等），需包含：
- 访问密钥（Access Key ID）
- 秘密密钥（Secret Access Key）
- 存储区域（Region）
- 终端节点（Endpoint）
- 存储桶名称（Bucket Name）

二、方式一：Docker 单机部署

适合快速启动单个容器，步骤简单，适合测试或小型场景。

1. 核心部署命令

将以下命令中的 占位符（如 your_access_key_here） 替换为您的实际配置，直接在终端执行：

bash

 1# Linux/macOS 系统（续行符为 \）
 2docker run -d \
 3  -p 8080:80 \  # 宿主机端口:容器内端口（容器内默认80，可修改宿主机端口如 80:80）
 4  --name excalicloudstore \  # 容器名称（可自定义）
 5  --restart unless-stopped \  # 容器意外退出时自动重启
 6  -e PORT=3001 \  # 后端服务端口（容器内固定，无需修改）
 7  -e NODE_ENV=production \  # 环境类型（production 生产环境，development 开发环境）
 8  -e AWS_ACCESS_KEY_ID=your_access_key_here \  # 替换为 S3 访问密钥
 9  -e AWS_SECRET_ACCESS_KEY=your_secret_key_here \  # 替换为 S3 秘密密钥
10  -e S3_REGION=your_s3_region_here \  # 替换为 S3 区域（如 cn-east-1、us-east-1）
11  -e S3_ENDPOINT=your_s3_endpoint_here \  # 替换为 S3 终端节点
12  -e S3_BUCKET=your_s3_bucket_name_here \  # 替换为 S3 存储桶名称
13  -e STORAGE_PATH_PREFIX=Excalidraw/web_canvas/ \  # S3 存储路径前缀（可自定义，如无需求保持默认）
14  -e S3_FORCE_PATH_STYLE=true \  # 强制使用路径风格访问 S3（兼容多数存储服务）
15  -e S3_TLS=false \  # 是否启用 TLS（true 为 HTTPS，false 为 HTTP，根据 S3 配置选择）
16  grayfalcon/excalicloudstore:latest  # 镜像名称（:latest 为最新版本，可指定具体版本如 :v1）

powershell

💻电脑时间管理大师：Manic Time 最易懂的速成教程

Sat, 06 Sep 2025 00:00:00 +0000

引言

博主有段时间特别痴迷记录生活习惯，我曾在 4 月份陷入手动复盘的困境—— 想记录电脑使用习惯却难以坚持：手动记太麻烦、整理数据费时间，一想到复盘流程就头大。直到遇到 Manic Time，这款电脑时间管理软件彻底解决了我的痛点：它能静默在后台运行，从开机到关机全自动记录电脑操作（温馨提示：隐私相关记录还是别记录了哈🤣）。

虽初用时觉得功能繁琐、对新手不友好，但熟悉后才发现它的核心优势 ——无痛自动记录：只需花 10 分钟学基础操作，后续无需手动干预，想看时间习惯时随时调用数据。本文专为和我一样的 “记录新手” 打造，用最直白的步骤，教你掌握 Manic Time 的自动记录核心功能。

正文

1. 核心前置：3 分钟摸清 Manic Time 关键模块

Manic Time 的自动记录逻辑围绕 “时间轴 + 统计” 展开，新手无需学所有功能，先掌握 2 个核心模块即可。

1.1 时间轴：自动记录的 “数据底座”

时间轴是 Manic Time 记录数据的核心载体，3 条关键时间轴分清就好了：

标签时间轴：按自定义标签记录，但无法自动标记，需手动操作（后续会教如何 “变自动”）。
程序时间轴：按使用的程序（如 edge.exe、微信.exe）自动记录，无需手动干预，是 “全自动数据来源”。
自动标记时间轴：支持按规则自动标记标签，可理解为 “能自动工作的标签轴”（核心功能，后续重点用）。

图 1：Manic Time 时间轴面板（3 条核心时间轴，新手重点关注）

1.2 统计信息：让时间分配 “可视化”

统计信息是 “看结果” 的关键，能将时间轴数据转化为直观图表：

点击顶部导航栏「统计信息」，面板会自动汇总所有时间轴数据。
调整「分组依据」：可按 “天” 或 “周” 汇总，方便查看短期 / 长期时间分配。
切换图表类型：建议用 “折线图”，能清晰看到某类活动（如娱乐、工作）的时间变化趋势。

我们做所有自动设置的最终目的，就是让「统计信息」能直接展示 “自定义标签” 的时间数据，比如 “娱乐视频耗时”“工作软件使用时长”，方便快速复盘。

Obsidian 多端同步：用七牛云 + Remotely Save 实现手机与电脑无缝协作

Sat, 06 Sep 2025 00:00:00 +0000

引言：灵感随时记，多端不脱节

Obsidian 的白板功能对梳理编程数据流、搭建知识体系十分友好，但很多时候灵感来袭时我们并不在电脑前，只能用手机临时记录，后续还要手动迁移到电脑端的 Obsidian 中，既繁琐又容易遗漏细节。

如果 Obsidian 能实现多端同步，就能让创作更顺畅：手机随手记下的想法，下次打开电脑时，只需点击同步按钮，就能继续编辑；再结合之前分享的PicGo 图床搭建教程，还能在手机与电脑间快速传输文字和图片。

准备环境：所需工具清单

要实现 Obsidian 多端同步，需准备以下工具：

云存储服务：七牛云对象存储（作为 Obsidian 的远程存储载体）；
笔记应用：Obsidian（需同时安装 PC 端和手机端，建议使用最新版本）；
同步插件：Remotely Save（Obsidian 第三方插件，负责多端数据同步）。

第一步：七牛云对象存储配置

七牛云的「对象存储（Kodo）」是同步的核心 “仓库”，请按以下步骤配置：

1. 注册并完成实名认证

访问七牛云官网，完成账号注册后，务必进行实名认证（个人或企业认证均可，按页面提示提交资料即可）。
⚠️ 实名认证是使用对象存储的必要前提，必须完成！

2. 创建存储空间

实名认证通过后，进入七牛云控制台，操作如下：

点击左侧导航栏「对象存储 Kodo」；
点击「创建空间」，填写相关信息：
- 空间名称：自定义（需保证全局唯一，例如obsidian-sync-2025）；
- 存储区域：选择距离自己最近的区域（后续同步速度更快，区域与 ID 的对应关系见下文表格）；
- 其他选项（如存储类型、访问控制等）：新手保持默认设置即可。

3. 获取访问密钥（AK、SK）

同步 Obsidian 需要 “访问密钥” 来验证身份，步骤如下：

点击控制台右上角头像，选择「密钥管理」；
点击「创建密钥」（若已有密钥，可直接使用）；
保存生成的**AccessKey（AK）**和**SecretKey（SK）**—— 这是后续配置的关键凭证，务必妥善保存！

第二步：Obsidian 与 Remotely Save 同步配置

完成七牛云配置后，需在 Obsidian 中安装并配置「Remotely Save」插件，实现与云存储的连接。

1. 安装 Remotely Save 插件

打开 Obsidian PC 端，依次操作：
设置 → 第三方插件 → 开启「社区插件市场」→ 搜索「Remotely Save」→ 点击「安装」并「启用」。

图床服务保姆级教程 2025白嫖github 彻底释放本地空间!

Sun, 31 Aug 2025 00:00:00 +0000

还在手忙脚乱地在服务器和客户端之间传图片？还在为博客图片引用失效而头疼？其实这些都多余了！

拥有图床服务，就等于拥有了一个多端同步的媒体库——不仅能存图片，还能存GIF、PDF、文本文件等。写博客时无需纠结复杂格式，只需掌握简单的Markdown语法，就能快速搭建便捷又优雅的写作环境。

正文

一、环境准备

本次搭建需用到以下工具，点击名称可直接跳转至对应下载/官网页面：

PicGo：图床上传工具，GitHub官方仓库（可下载最新版）
GitHub仓库：用于存储图片的免费云端空间
Typora：Markdown编辑器，官方下载链接
WordPress：博客发布平台（可选，也可适配其他平台）

二、最终实现效果

截图后按下 Ctrl+C 复制，再到Typora中 Ctrl+V 粘贴，即可自动生成「Markdown语法+图片URL」的内容；发布时全选Typora内容，复制到博客发布页，一键完成发布。

三、详细搭建步骤

1. 创建GitHub仓库（存储图片的“云端硬盘”）

登录GitHub，新建仓库，配置参考下图：
关键注意：仓库必须设置为「Public」，否则图片外链无法公开访问。

2. 创建GitHub Token（授权PicGo操作仓库）

进入GitHub的「Settings → Developer settings → Personal access tokens」，选择**「Generate new token (classic)」**（重点！选“classic”，新版token可能导致PicGo无权访问）：
权限配置：勾选「repo」分类下的所有权限（确保PicGo能上传/管理图片）：
生成Token后立即保存（刷新页面后无法找回）。

3. 配置PicGo（将图片上传到GitHub）

打开PicGo，在左侧选择「图床设置 → GitHub图床」。

关键参数填写（重点是「自定义域名」，根据需求二选一）：

海外服务器/需科学上网：

1https://raw.githubusercontent.com/你的用户名/你的仓库名/refs/heads/你的分支名/

国内服务器（加速访问）：

1https://cdn.jsdelivr.net/gh/你的账户名/你的仓库名@你的分支名/

其他参数：依次填写「GitHub用户名」「仓库名」「分支名（默认main）」「刚才保存的Token」，最后点击「确定」并设为默认图床。

4. 关联Typora（实现“截图即上传”）

打开Typora，进入「文件 → 偏好设置 → 图像」。
配置如下（参考图片）：
- 勾选「插入图片时自动上传」
- 上传服务选择「PicGo」
- 「PicGo路径」选择本地的「PicGo.exe」文件（如D:\PicGo\PicGo.exe）
点击「验证图片上传选项」，提示“成功”即配置完成。

四、测试验证

用Windows截图快捷键 Win + Shift + S 截取任意内容。
切换到Typora，按下 Ctrl+V 粘贴。
若PicGo左下角弹出「上传成功」通知，且Typora中显示图片（而非本地路径），则图床搭建成功！

后记：为什么选GitHub而非国内OSS？

我的WordPress强制开启了HTTPS，而七牛云等国内免费OSS提供的域名多为HTTP，需额外申请SSL证书（且需国内备案域名），流程繁琐。
GitHub自带HTTPS，无需备案且完全免费，虽国内访问速度略慢，但可通过「jsdelivr CDN」加速；若追求更稳定的国内访问，也可替换为Gitee仓库（操作流程一致）。

用Nginx Proxy Manager为WordPress站点设置反向代理

Sat, 30 Aug 2025 00:00:00 +0000

引言：

为什么需要给 WordPress 套反向代理？

有朋友可能会疑惑：WordPress 本身能设置站点 URL 和端口，为什么还要多此一举用反向代理？

核心原因很简单——避免 80/443 端口被博客独占。公网访问中，80（HTTP）和 443（HTTPS）是默认端口，若直接给 WordPress 用，后续想部署其他项目（如个人网盘、后台管理系统）就无法通过二级域名（如 drive.example.com ）复用这两个端口。而用 Nginx Proxy Manager（简称 NPM）做反向代理，能统一管理所有入站流量，通过不同二级域名分配端口，更灵活高效。

📌 说明：本文是博主第一篇技术博客，内容偏向新手友好，若有技术疏漏，欢迎各位大佬留言指正！

一、前置准备：环境与基础要求

在开始前，先确认你的环境是否符合以下条件（仅供参考，非强制但推荐）：

部署环境：Nginx Proxy Manager（NPM）与 WordPress（WP）部署在同一台服务器
容器工具：两者均通过 Docker Compose 部署（需提前安装 Docker 和 Docker Compose，参考 Docker 官方安装指南）
网络环境：服务器已具备公网 IP，且开放必要端口（80、443、81），支持公网访问

二、步骤 1：Docker 配置（端口映射 + 容器网络）

这一步的核心是：让 NPM 和 WordPress 容器能互相通信，同时避免端口冲突。

1.1 配置容器端口映射（关键！）

WordPress 容器有个特殊限制：容器内部必须使用 80 端口（否则无法通过主机IP:端口访问安装界面），因此需在 docker-compose.yml 中指定「宿主机端口:容器 80 端口」，宿主机端口可自定义（如 8000）。

示例：WordPress 端口映射配置

WordPress 的 docker-compose.yml 片段

1services:
2  wordpress:
3    image: wordpress:latest  # 推荐使用官方最新镜像
4    ports:
5      - "8000:80"  # 宿主机 8000 端口 → 容器 80 端口（宿主机端口可改，容器端必须是 80）
6    # 其他配置（如数据库链接、 volumes 等）省略，需自行补充

Nginx Proxy Manager 端口映射配置