技术

本文持续更新 堆、栈 它们是程序运行时，两块用途完全不同的内存区域。 栈（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文件夹以下的位置： ...

还在手忙脚乱地在服务器和客户端之间传图片？还在为博客图片引用失效而头疼？其实这些都多余了！ 拥有图床服务，就等于拥有了一个多端同步的媒体库——不仅能存图片，还能存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仓库（操作流程一致）。 ...

引言： 为什么需要给 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 端口映射配置 ...