Posts

本文持续更新 堆、栈 它们是程序运行时，两块用途完全不同的内存区域。 栈（Stack）—— 函数的临时小抽屉 每个函数运行时，都会在栈上占一小块空间； 函数里的局部变量、参数默认都往栈上放； 函数一结束，栈空间自动清空，变量直接销毁； 速度极快，几乎零开销； 不需要 GC 垃圾回收。 特点：自动申请、自动释放，快、小、临时。 堆（Heap）—— 全局公共大仓库 一块共享的大内存； 放那些函数结束后还需要活着的变量； 不会自动销毁，靠 Go 的 GC 来回收； 分配慢、寻址慢、有 GC 开销。 特点：手动 / 编译器决定分配，GC 回收，慢、大、持久。 在栈还是堆 直接用 Go 自带的逃逸分析命令看： 1go build -gcflags="-m" main.go 输出里会出现两种关键行： does not escape → 变量在 栈 上 escapes to heap → 变量逃逸到 堆 上 slice 数据结构 slice是引用类型，共享内存地址 切片扩容 只有append才会触发扩容！手动make只是新建切片。 扩容会彻底替换底层数组： 计算新的容量（按增长规则） 在堆上新建一个更大的底层数组 把旧数组的所有数据完整拷贝到新数组 切片指针指向新数组，更新 len/cap 旧数组如果没有其他引用，会被 GC 自动回收 容量增长规则（Go 1.18+ 最新版） 小切片快速扩容，大切片平缓扩容，避免内存浪费 ...

这是博主开源到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 写一个系统服务即可，以下为示例: ...

环境介绍 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文件夹以下的位置： ...

从简开始 相信不少人刚开始折腾内核的时候，都是一脸茫然的，要配置的内容太多，对新手不友好。所以我们从最简单的方法做起，力求先把内核跑起来，然后再慢慢拓展。 搞代理的前提是你需要去各大机场订阅节点，或者你自己拥有节点。通常机场会给你提供一个订阅链接🔗，复制下来。 下载内核 先去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 的基础运行参数、网络入口（端口）、全局模式等，是软件启动的 基础设置。 ...

基本区别 许多小白第一次接触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 请求，目的是让企业微信执行 “推送消息” 的动作。 ...