技术 on Jamaisvu's blog

gilang八股文

Wed, 22 Apr 2026 04:24:04 +0800

本文持续更新

堆、栈

它们是程序运行时，两块用途完全不同的内存区域。

栈（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+ 最新版）

小切片快速扩容，大切片平缓扩容，避免内存浪费

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文件夹以下的位置：

图床服务保姆级教程 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 端口映射配置