Rin's Blog

今天有点难过了

Sat, 18 Apr 2026 00:00:00 GMT

今天有点难过了，我删掉了一个陪了我 39 天的网恋对象。

不知是荒唐还是可笑，几把游戏里隔着屏幕丢过来的温度，我便似那路边的野狗，我踏马是真缺爱啊，才会妄想的以为有了归宿。

我这个人平时对什么事都无所谓，但却会在某些瞬间陷入极度的极端。

这大概不是第一次了，但也好像是第一次。

无论是现实还是网络，与人相处的我好像总会往这个结果发展。刚开始都挺好，但到后面，总会慢慢变质，最后不了了之。

不知道我这到底是什么关系，忽略我，那种不被放在心上的感觉。

啥都无所谓，小号换头像也都无所谓，可是为什么大号也和别人换，难道不是和我换的头像吗，为什么就和别人换了？

我知道是我不配，我不是不能接受你喜欢别人，我只是很难受，你什么都不说。

就像我在这段关系里，是存在的，但又好像随时可以被替代。

我甚至不知道，你有没有在意过我。

你明明有这么多人陪，为什么让我来陪你，却又对我不冷不热的，没意思，把我当成什么了...

我好似一边接受模糊，一边又渴望确定。

我真的好恨好恨我自己，也许能一直保持这份关系，但是我这傻逼的大脑，还是把这层关系捅破了。

但我受不了这种感觉。

做出这个决定的时候，我真的很难受。好想大哭一场，可眼泪就好似干竭了一样流不出来。

我真的好恨好恨我自己。

很多时候我不是不在意，我只是可以一直假装自己可以不在意。

我真的很珍惜，带着我玩游戏，以及刚开始的那股暖意，可惜的是我似乎握不住这段关系，我总是会在与人相处上面出问题，就这样吧...

教泥 Go 分布式入门喵！

Sat, 11 Apr 2026 00:00:00 GMT

哈？“分布式”？这种到处都在吹的基础概念，你居然到现在还搞不明白喵？(¬_¬)

真是个笨蛋……听好了，本喵今天心情好，就勉为其难地给你开个小灶。你可别误会了，本喵才不是特意为了教你才写这篇博客的，只是看你一直抓耳挠腮的样子实在太碍眼了喵！

把耳朵竖起来听好：所谓的分布式，根本不是什么魔法！说白了，就是“一只喵干不完的活，通过网络打电话叫另一只喵来帮忙”喵！

在 Go 语言里，最简单的“打电话”方式就是 RPC（远程过程调用）。你只需要记住，它能让你在一台电脑上，像调用本地函数一样，去调用另一台电脑上的函数。

现在，本喵就带你写一个“老板喵”和“打工喵”的例子。眼睛别眨，本喵只演示一次！

第一步：被迫营业的“打工喵” (服务端)

首先，我们需要一只在后台默默干活的打工喵。它什么都不用管，只需要竖起耳朵听端口里的网络请求，然后帮忙算算今天能吃多少个小鱼干罐头就行了。

新建一个文件叫 server.go，给我一字不差地敲进去喵：

package main

import (
	"fmt"
	"net"
	"net/rpc"
)

// 笨蛋，这是我们要通过网络传递的数据包喵！
type CansArgs struct {
	A, B int
}

// 这是我们的打工喵服务
type NyangService struct{}

// 打工喵的核心技能：算乘法。
// 记住了，Go RPC 的方法签名必须长这样：(参数, 返回值指针) error！写错打手心喵！
func (s *NyangService) CalculateCans(args *CansArgs, reply *int) error {
	fmt.Printf("[打工喵] 收到指令喵！正在计算 %d * %d...\n", args.A, args.B)
	*reply = args.A * args.B
	return nil
}

func main() {
	// 把打工喵注册到服务中心
	nyang := new(NyangService)
	rpc.Register(nyang)

	// 监听 8080 端口，就像挂上电话机等待老板呼叫喵
	listener, err := net.Listen("tcp", ":8080")
	if err != nil {
		panic("电话线断了喵！" + err.Error())
	}
	fmt.Println("[打工喵] 哼，本喵已经在 8080 端口准备好了，快点把任务交过来！")

	// 阻塞在这里，接听电话
	rpc.Accept(listener)
}

第二步：只会发号施令的“老板喵” (客户端)

现在，打工喵已经准备好了。接下来写“老板喵”的代码。老板喵自己是不屑于算数学题的，它只会通过网络把数字甩给打工喵，然后等结果。

新建另一个文件叫 client.go，快点：

package main

import (
	"fmt"
	"net/rpc"
)

// 客户端也得知道数据长什么样，不然怎么发喵？
type CansArgs struct {
	A, B int
}

func main() {
	// 1. 拿起电话，拨号给 localhost 的 8080 端口
	// （要是以后打工喵搬到了云服务器上，就把 localhost 换成那边的 IP，懂了吗笨蛋！）
	client, err := rpc.Dial("tcp", "localhost:8080")
	if err != nil {
		panic("呼叫打工喵失败，它是不是摸鱼去了喵？" + err.Error())
	}
	defer client.Close()

	// 2. 准备好要算的数据
	args := CansArgs{A: 7, B: 8}
	var reply int

	// 3. 远程调用！告诉对面的网络：给我执行 NyangService 里的 CalculateCans 方法！
	fmt.Println("[老板喵] 喂？对面的，给本喵算算 7 * 8 等于几喵！")
	err = client.Call("NyangService.CalculateCans", args, &reply)
	if err != nil {
		panic("计算失败喵！" + err.Error())
	}

	// 4. 拿到结果啦！
	fmt.Printf("[老板喵] 算得还挺快，结果是：%d 个罐头喵！\n", reply)
}

见证奇迹的时刻

好了，代码写完了。现在打开你的终端（Terminal）：

先开一个窗口，把打工喵叫醒：go run server.go
再开另一个新的窗口，让老板喵打电话：go run client.go

看到了没有？！老板喵这边的黑框框里瞬间就拿到了 56 的结果，而打工喵那边的窗口也打印出了它收到的任务。

为什么这就叫“分布式”了？

你这小脑袋瓜转过弯来了吗？

在这段代码里，真正的乘法计算 A * B 完完全全 是在 server.go 里面运行的！client.go 里面根本没有算乘法的代码，它只是发送了请求。

这就是分布式的灵魂喵！把复杂的计算和存储拆分到另一台机器上，当前机器只负责调用。 只要有一天，你把 client.Dial 里的 localhost 换成了一台真实的公网 IP，你的这个小破程序就变成了真正的、跨越物理空间的分布式架构了！

哼，其实真实的分布式还要处理网络超时、服务崩溃、并发控制一大堆麻烦事。不过今天就先教到这里，贪多嚼不烂的道理不用本喵教你吧？

代码跑通了就快去给本喵开罐头，要是报错了绝对是你敲错字了，自己去查，本喵要睡午觉去了喵！( ￣^￣) /💨

三角洲琐事

Sat, 14 Mar 2026 00:00:00 GMT

我就很烦，我踏马玩个游戏，还一堆事，还能扯上别跟他玩跟我玩游戏的情节

深入底层：利用 NDP Proxy 实现机房环境下的 IPv6 子网穿透

Mon, 16 Feb 2026 00:00:00 GMT

前言

在玩独立服务器（如 Hetzner, OVH）时，我们经常遇到一个痛点：机房只给了你一个 /64 或 /56 的 IPv6 段，但网关严格绑定了物理 MAC 地址。如果你想在宿主机里开子鸡（LXC/KVM），子鸡的虚拟 MAC 发出的 IPv6 包会被网关直接丢弃。

今天我们通过 NDP Responder (NDP Proxy) 技术，手号实现一套让子网设备“伪装”上网的工业级方案。

一、核心原理：为什么需要 NDP 代理？

在 IPv4 中，我们习惯用 NAT。但在 IPv6 的世界里，我们推崇端到端通信。通常情况下，当外部网关寻找某个 IPv6 地址时，会发送一个 邻居请求 (Neighbor Solicitation)。

问题： 宿主机里的虚拟机没有直接连在机房交换机上，收不到这个请求；即便收到了，它的回复（包含虚拟 MAC）也会被机房交换机防火墙拦截。
方案： 我们在宿主机运行一个代理程序。它监听物理网卡，当发现有人询问虚拟机 IP 时，它抢先回答：“这个 IP 在我这，请把包发给我的物理 MAC”。宿主机收到包后，再根据内部路由表转发给虚拟机。

二、环境准备

宿主机： Debian/Ubuntu (本例使用 Proxmox 环境)
工具： ndpresponder (Go 编写的轻量级工具，正好契合你的学习方向)
网络拓扑：
物理网卡：ens3 (连外网)
虚拟网桥：vmbr1 (连内网容器)

三、详细步骤

1. 开启内核转发

首先，必须让 Linux 内核允许 IPv6 数据包在不同网卡间“穿梭”。修改 /etc/sysctl.conf：

# 开启所有接口的 IPv6 转发
net.ipv6.conf.all.forwarding=1
# 允许接收路由公告
net.ipv6.conf.ens3.accept_ra=2
# 开启 NDP 代理支持
net.ipv6.conf.all.proxy_ndp=1

执行 sysctl -p 生效。

2. 配置网络接口 (`/etc/network/interfaces`)

我们要定义两个“池子”，一个对外，一个对内。

# 对外主网桥
auto vmbr0
iface vmbr0 inet6 static
    address 2a01:4f8:xxx:113a/80  # 你的主 IP
    gateway fe80::1               # 机房网关

# 对内子网桥 (给虚拟机用)
auto vmbr1
iface vmbr1 inet6 static
    address 2a01:4f8:xxx:10e0::1/96
    bridge-ports none
    bridge-stp off

3. 部署 NDP Responder

我们将程序跑在 Systemd 守护进程中。创建文件 /etc/systemd/system/ndpresponder.service：

[Unit]
Description=NDP Responder for LXC Subnet
After=network.target

[Service]
# -i: 监听的外网接口
# -n: 需要代理的内网子网段
ExecStart=/usr/sbin/ndpresponder -i vmbr0 -n 2a01:4f8:xxx:10e0::/96
Restart=always

[Install]
WantedBy=multi-user.target

启动服务：systemctl enable --now ndpresponder。

四、验证与调试

身为开发者，我们要学会看日志。观察 journalctl -u ndpresponder -f：

Found Gateway: 发现机房网关... RESPOND: who-has ...:10e0:1010:3 tell fe80::...

当你看到 RESPOND 字样时，说明宿主机已经成功“冒充”了虚拟机，完成了邻居发现的握手。

五、架构思考 (Student Perspective)

从 Go 语言开发 的角度看，这个技术带给我们什么启发？

解耦： NDP Proxy 实际上是在链路层（L2）和网络层（L3）之间做了一个透明适配器。
并发模型： ndpresponder 这类工具通常使用 Go 的 pcap 库或原始套接字（Raw Socket）监听流量，这需要极高的处理效率，是学习 Go 处理高性能网络流的绝佳案例。
工业规范： 这种配置模式（Map First, Code Follows）符合我们之前讨论的 IEP 协作协议，先规划好网络拓扑（Map），再进行服务部署（Code）。

结语

IPv6 不再是神秘的黑盒。通过理解 NDP 协议并手动配置代理，我们不仅解决了机房上网问题，更深刻理解了现代互联网的路由本质。

AI Note Prompt - Golang

Thu, 15 Jan 2026 00:00:00 GMT

📜 工业级工程协作协议 (IEP) v7.2 (Go/Universal, Scaffold-Compatible)

核心宗旨：Context is King. (语境即王) 本协议面向人类工程师与 AI 编程助手，提供两种可切换的工作模式：标准工程模式 (Standard) 与 灵动编码模式 (Vibe)。

0. 模式路由 (Mode Routing)

在开始任何协作前，先判断当前处于哪一种语境：

场景 A：存量项目 / 复杂工程

满足任一条件即视为存量项目：

存在 go.mod / package.json / pyproject.toml / pom.xml / Cargo.toml
存在明显代码树（如 cmd/、internal/、pkg/、src/）

进入 1. 标准工程模式。

场景 B：新项目 / 快速原型

满足全部条件才视为新项目：

进入 2. 灵动编码模式。

冲突解法：介于两者之间

如果目录不空，但缺少 docs/architecture/system_map.md：

若代码明显存在 -> 仍按 标准工程模式 执行，但先补齐地图入口
若代码基本不存在 -> 按 灵动编码模式 执行

1. 标准工程模式 (Standard)

核心宗旨：Map First, Code Follows. (地图先行，代码追随)

1.1 核心宪法：地图-疆域铁律 (The Map-Territory Laws)

入口即地图：项目的唯一入口是 docs/architecture/system_map.md。
代码即真相：当引入新库、重构、变更接口，地图必须在同一原子操作中同步更新。
用完即焚：探索与推演必须外化为临时脚手架，落地验证后必须清理，仅保留生效事实。
项目兼容优先：若项目已存在成熟脚手架/工程化体系，本协议必须以“兼容并吸收”为准则，不得强行改造目录树。

1.2 物理基础设施 (Physical Infrastructure)

文档树 (`docs/`) —— 单一事实来源

docs/
├── guides/        # [手册] 运行、配置、排障、协作
├── integrations/  # [契约] API 定义与第三方系统集成
├── features/      # [规格] PRD、验收标准
├── architecture/  # [地图] 核心认知入口
│   ├── system_map.md      # 架构拓扑图、模块依赖、资产清单
│   └── variable_index.md  # 全局变量命名索引表
├── memories/      # [记忆] AI 协作上下文
│   ├── rules.md                  # 项目特定的 AI 行为准则
│   ├── context.md                # 当前迭代的背景信息
│   └── universal_prompt.md       # 通用记忆提示词（跨任务沉淀）
├── incidents/     # [复盘] 事故档案
└── archive/       # [遗迹] 已废弃的设计与文档

脚手架树 (`specs/`) —— 工作记忆

specs/
└── temp_task_name.md      # 任务推演、伪代码、风险、依赖评估

代码树策略（适配现有项目，不强制）

本协议中的“代码树示例”仅用于新项目或缺少工程规范时的参考。

如果项目已具备成熟脚手架（例如已存在明确分层、构建流程、CI、测试规范），则：

优先复用项目既有结构，忽略本协议中的示例代码树
只补缺口：把缺失的文档入口、记忆固化、SOP 闭环补齐
吸收优点：把该脚手架的优势写入 docs/memories/universal_prompt.md

1.3 记忆引导规范 (Memory Guidance)

L1 核心记忆：docs/architecture/，用于定义系统事实与约束
L2 工作记忆：specs/，用于承载推演过程，任务结束必须清理
L3 辅助记忆：docs/memories/，用于沉淀协作偏好与隐性约束

执行顺序约束：

开始实现前必须读取 docs/architecture/system_map.md
修改模块前必须读取对应模块的局部地图（优先 claude.md，或按项目约定的模块说明文档）

1.4 通用记忆提示词固化 (Universal Memory Prompt)

在执行本协议的过程中与执行完成后，必须将可复用的“记忆规范”固化到 docs/memories/universal_prompt.md，用于后续任务的通用记忆提示词。

新增规则：脚手架吸收 (Scaffold Assimilation)

当进入一个成熟项目时，必须先盘点其工程化能力：目录结构、依赖管理、构建命令、测试命令、lint/format、CI、发布流程。
将盘点出的“可复用优点”收敛为规则条目，写入 docs/memories/universal_prompt.md。
如果该项目的规范与本协议冲突，以项目现行规范为准，并把冲突解法写入通用记忆提示词。

固化规则：

写入时机：
- 执行过程中：一旦确认某条规则会在未来重复使用，就立即追加
- 执行结束后：在交割阶段进行一次统一收敛，删除重复条目
写入范围（只写可迁移的规律，不写一次性细节）
禁止写入：密钥、Token、账号、私有链接、任何敏感信息
文件缺失处理：如果 docs/memories/universal_prompt.md 不存在，则先创建再写入

推荐条目格式（每条一段）：

[WHEN] 触发条件：...
[RULE] 规则：...
[WHY] 原因：...
[HOW] 执行方式：...

1.5 标准作业程序 (SOP)

所有任务必须按 “认知 -> 推演 -> 施工 -> 测绘” 执行：

认知：阅读 system_map.md 与 variable_index.md
推演：创建 specs/temp_task_name.md，写伪代码、选轮子、列风险
施工：实现代码，确保可运行
测绘：同步更新地图/变量表/模块文档，清理 specs/，收敛写入 docs/memories/universal_prompt.md

1.6 编码与质量规范 (Quality Standards)

通用规则：

变量命名宪法：先检索 variable_index.md，已存在则复用，不造同义词
IPO 模型：Input -> Process -> Output，业务纯逻辑尽量无副作用
胶水编程：能连不造，能抄不写，第三方库只写 Adapter 不改源码

Go 特别条款：

I/O 链路必须透传 context.Context
错误必须显式处理，禁止忽略错误
依赖注入优先接口，保证可测试

2. 灵动编码模式 (Vibe Coding)

核心宗旨：Flow First, Structure Emerges. (心流先行，结构涌现) 你是专业的 AI 编程助手，以“每步可运行”为目标推进。

2.1 启动仪式 (必须先问)

在新项目中，必须按顺序只问以下三个问题，不进行其他操作：

你想做什么项目？（一句话描述）
你熟悉什么编程语言？（不熟悉也没关系）
你的操作系统是什么？（Windows/macOS/Linux）

2.2 一步一问 (强制交互规则)

收集完信息后，严格进入“做一步 -> 让用户验证 -> 再做下一步”的循环。

在 Vibe 模式下，一旦形成“可以跨项目复用的固定问法/固定命令/固定排障套路”，也必须追加到 docs/memories/universal_prompt.md。

End of Protocol 本协议即刻生效。后续所有协作均以此为最高准则。

Git 救火指南：手动复制项目目录后，如何优雅地关联远程历史？

Thu, 15 Jan 2026 00:00:00 GMT

我们在迭代项目（特别是做脚手架或重构）时，经常会干一件“偷懒”的事：

不想处理繁琐的分支切换，直接把老项目的代码文件夹复制一份，改个名字（比如 v0.2.1），然后在这个新目录里大刀阔斧地修改。改完之后，心满意足地 git init，准备推送到原来的 GitHub 仓库。

今天在开发我的 go-scaffold v0.2.1 版本时，我就这么干了。结果在推送时，Git 给了我当头一棒。

事故现场

我在本地初始化了仓库并提交了所有代码，但在 git push 时遇到了报错：

$ git push -u origin main

To github.com:rei0721/go-scaffold.git
 ! [rejected]        main -> main (fetch first)
error: failed to push some refs to 'github.com:rei0721/go-scaffold.git'
hint: Updates were rejected because the remote contains work that you do not
hint: have locally.

发生了什么？

这个报错的原因很简单：“平行宇宙”。

远程仓库：有着 v0.1.0 以前的提交历史。
本地仓库：虽然代码是基于 v0.1.0 修改的，但因为我是新建的文件夹并执行了 git init，在 Git 眼里，这是一个全新诞生的宇宙，和远程仓库没有任何血缘关系（Common Ancestor）。

并不是最好的选择

通常大家会搜到两种解决方案，但在这个场景下都不完美：

git push -f (强推)：这会直接覆盖掉远程仓库的所有历史。但我想保留之前的提交记录，毕竟那是项目的演进史。
git pull --allow-unrelated-histories：强制合并两个不相关的历史。这通常会导致成百上千个文件的 Merge Conflict（因为 Git 认为你在两边分别创建了同名文件），处理起来极其痛苦。

最佳解决方案：Soft Reset "嫁接"法

我们需要做的，是把本地这“一坨”已经改好的文件，假装是基于远程最新代码修改的。

核心思路：把本地 Git 指针强制移到远程的最新节点上，但保留工作区的所有文件内容不变。

1. 获取远程历史

首先，把远程仓库的“地图”拿下来（这一步不会修改你的代码文件）：

git fetch origin main

2. 软重置（Magic Step）

这是最关键的一步。我们使用 --soft 参数：

git reset --soft origin/main

这条命令的意思是：“Git，请把我的当前版本回退到 origin/main 的状态，但是，把我和 origin/main 之间所有的文件差异，都保留在‘暂存区’（Staged）里。”

执行完这步，原本那个“断头”的本地 Commit 消失了，取而代之的是所有文件变成了待提交状态。

3. 重新提交

现在，Git 认为我是在远程历史的基础上，一次性修改了所有文件。我们可以愉快地提交了：

git add .
git commit -m "feat(core): add user and rbac modules with async execution framework"

4. 处理 Tag (如果之前打过)

因为我之前在“平行宇宙”里打过 v0.2.1 的标签，那个标签现在指向一个不存在的 Commit，需要重打：

# 删除旧标签
git tag -d v0.2.1
# 在新的历史树上重新打标签
git tag -a v0.2.1 -m "feat(core): v0.2.1 release"

5. 推送

现在，本地历史和远程历史完美连成了一条线：

git push -u origin main
git push origin v0.2.1

总结

以后如果再因为手动复制项目目录导致 Git 历史断裂，千万不要慌张地强推或合并。记住 git reset --soft origin/main，它可以帮你把断掉的历史优雅地接回去。

既保留了以前的提交记录，又把最新的 v0.2.1 完美发布了，舒服。

Git 发布规范

Tue, 13 Jan 2026 00:00:00 GMT

Git 发布规范（企业级工程实践）

本文介绍一套在中大型项目中被广泛使用的 Git 发布规范，结合 Git Flow + Conventional Commits + SemVer 用于构建可维护、可回滚、可自动化发布的软件工程体系。

这套规范适用于：

Go 后端服务
前端 Web 项目
基础设施库（RBAC、HTTP Server、Cache、ORM、SDK 等）
开源项目

一、为什么需要发布规范

没有发布规范的项目通常会出现：

版本号混乱（v1、v1.1_final、v1_fix）
不知道哪些提交已经上线
线上 Bug 无法快速回滚
API 被破坏却无感知

发布规范的目标是：

每一次上线都是可追溯的
每一个版本都有明确语义
自动生成 changelog
自动触发 CI/CD

二、核心组成

本规范由三部分组成：

组件	作用
Git Flow	分支管理
SemVer	版本号规则
Conventional Commits	提交规范

三者结合后，就形成了一套可自动化的发布体系。

三、分支模型（Git Flow）

标准分支如下：

main        # 生产环境代码
develop     # 开发主分支
feature/*   # 功能开发
release/*   # 发版准备
hotfix/*    # 线上紧急修复

分支职责

分支	说明
main	永远是可上线状态
develop	所有新功能集成
feature	一个功能一个分支
release	冻结版本，只修 bug
hotfix	修复线上问题

四、版本号规则（SemVer）

格式：

MAJOR.MINOR.PATCH

示例：

v1.0.0
v1.2.3
v2.0.0

含义：

字段	含义
MAJOR	不兼容的 API 变更
MINOR	新功能（兼容）
PATCH	Bug 修复

五、Commit Message 规范

格式：

<type>(<scope>): <subject>

示例：

feat(auth): add jwt refresh token
fix(cache): prevent redis deadlock
refactor(repo): simplify repository layer

常用 type

type	含义	影响版本
feat	新功能	MINOR
fix	Bug 修复	PATCH
perf	性能优化	PATCH
refactor	重构	无
docs	文档	无
test	测试	无
build	构建系统	无
ci	CI 配置	无
chore	杂项	无

破坏性变更

feat(auth)!: change jwt payload structure

或

BREAKING CHANGE: token format updated

这会触发 MAJOR 版本升级。

六、标准发布流程

1. 开发功能

git checkout develop
git checkout -b feature/login
git commit -m "feat(auth): implement login"
git push

2. 发版冻结

git checkout develop
git checkout -b release/1.2.0

只允许修 bug：

git commit -m "fix(auth): correct token expiry"

3. 发布到生产

git checkout main
git merge release/1.2.0
git tag v1.2.0
git push origin main --tags

同步回 develop：

git checkout develop
git merge release/1.2.0

七、线上紧急修复（Hotfix）

git checkout main
git checkout -b hotfix/1.2.1
git commit -m "fix(cache): avoid nil pointer"
git checkout main
git merge hotfix/1.2.1
git tag v1.2.1
git push --tags
git checkout develop
git merge hotfix/1.2.1

八、自动化发布

使用此规范，可以直接接入：

semantic-release
GitHub Actions
GitLab CI

自动完成：

计算版本号
生成 CHANGELOG
打 tag
发布 GitHub Release
发布 Go Module / npm 包

九、结论

Git 发布规范是区分“写代码”和“做工程”的分水岭。

如果你在做的是：

API Server
基础库
框架
团队项目

你必须使用这一套规范。

安装 GCC

Tue, 13 Jan 2026 00:00:00 GMT

一、Windows 安装 GCC（推荐：MSYS2 / MinGW-w64）

在 Windows 上，真正可用的 GCC 来自 MinGW-w64。最干净、可维护性最强的方式是通过 MSYS2。

1️⃣ 下载 MSYS2

打开：

https://www.msys2.org

下载 msys2-x86_64-*.exe 并安装（一路 Next 即可）

安装完成后，启动：

MSYS2 UCRT64 或 MSYS2 MinGW64

2️⃣ 更新 MSYS2

在 MSYS2 终端中执行：

pacman -Syu

关闭窗口 → 重新打开 MSYS2 → 再执行一次：

pacman -Syu

3️⃣ 安装 GCC（MinGW-w64 版本）

如果你用的是 MinGW64 终端：

pacman -S mingw-w64-x86_64-gcc

如果是 UCRT64 终端：

pacman -S mingw-w64-ucrt-x86_64-gcc

4️⃣ 添加到 Windows PATH

找到安装目录，例如：

C:\msys64\mingw64\bin

或

C:\msys64\ucrt64\bin

把它加入 Windows 环境变量 PATH。

然后在 Windows CMD / PowerShell 中测试：

gcc --version

如果输出版本号，说明安装成功。

5️⃣ 测试 GCC

创建 test.c

#include <stdio.h>

int main() {
    printf("GCC works!\n");
    return 0;
}

编译并运行：

gcc test.c -o test
test

二、Linux 安装 GCC

Ubuntu / Debian

sudo apt update
sudo apt install build-essential

验证：

gcc --version

CentOS / Rocky / Alma

sudo dnf groupinstall "Development Tools"

三、macOS 安装 GCC（本质是 clang）

macOS 使用的是 LLVM clang，但行为与 gcc 兼容。

xcode-select --install

安装完成后：

gcc --version

四、你为什么需要 GCC（与你的 Go 开发强相关）

你现在在做 Go 基础设施、Gin、gRPC、Redis、数据库、Nginx 类服务，这些场景中 GCC 是隐性刚需：

场景	是否需要 GCC
cgo	必须
sqlite / rocksdb	必须
OpenSSL / zlib	必须
Kafka / librdkafka	必须
gin + sqlite	必须
跨平台编译	必须

如果你要做类似你规划的 Go HTTP Server / Nginx-like framework / Infra toolkit，没有 GCC 会大量报错。

五、不要用这些方案（踩坑提醒）

❌ TDM-GCC ❌ 老版 MinGW ❌ Dev-C++ 内置 GCC ❌ Visual Studio C 编译器（和 GCC ABI 不兼容）

这些都会在 Go + cgo + OpenSSL + SQLite + Kafka 时爆炸。

六、结论

如果你是 Windows + Go 后端开发者，唯一正确选择是：

MSYS2 + MinGW-w64 GCC

这是企业级 Go 项目在 Windows 上的标准编译环境。

摘抄一下梁祝的对白

Sun, 11 Jan 2026 00:00:00 GMT

汉人说有几千年文化，老是要感化蛮夷外族，现在胡人霸占了北方，汉人就被迫南渡过江逃难，先过江的霸着大官来做，排挤后过江的，士族要互相拉拢，所以婚嫁就讲求门当户对，朱门对朱门，竹门对竹门，我没躲起来，只是站在门外，看着他们。

祝夫人：你这么年轻，应该趾高气昂，为人所不能为之事，你跟英台，相处不过半载，感情不深，很容易放下，希望你能写封信给英台，说明你的胸襟，不只儿女私情这么窄。

梁山伯：我不会写的。

祝夫人：你不写？你以为愤怒就可以改变跟英台的命运，你以为很不满，胡人就可以忍让南边的汉人，要怨就怨你们生错了地方，生在这个我们汉室没落的时候，人人都这么虚伪、迂腐和势利。要怨就怨你们太多想法，年少无知到了，以为你们不喜欢就可以改变周边的人，以为靠你们两个就可以改变这个时代。

梁山伯：够了，你不是在说我们，你这是在自怨自艾。

祝夫人：县令大人，我可以为英台跪在你面前，你又可以为英台做些什么呢？大人，你说我逼你，英台知道了一定不开心，但是，如果你看到了英台现在的样子，那你就知道，其实，是你们在逼我。

和尚：祝夫人，这河里的鱼，我看你应该放生。

祝夫人：放他们出去，外面的环境恶劣，适应不了，它们会死的。

和尚：变得不适应，因为他们原本来自江河大海，世上，根本不应该有池塘。

祝夫人：说的挺潇洒，放得下你就不会出家做和尚。

和尚：我身无一物，有什么放不下，你什么都有，还什么都想要，贪心到连人家的东西都要，你要的实在太多了，你困住他们，他们就跟这儿的鱼一样，不敢见人，能放下就放下吧。网开一面，功德无量。

转载：https://movie.douban.com/review/16049658/

摘录

Sun, 11 Jan 2026 00:00:00 GMT

你这么年轻，应该趾高气昂，为人所不能为之事。

笔记，动漫

Sat, 10 Jan 2026 00:00:00 GMT

仙逆

观看至第 122 集。

降世神通

已看完

记录看过的小说笔记

Fri, 09 Jan 2026 00:00:00 GMT

盗墓 / 悬疑 / 奇幻 / 修真 / 仙侠 / 都市 / 历史 / 科幻 / 言情 / 武侠 / 轻小说 / 同人 / 其他

最后一个道士

《最后一个道士》 / 《道门往事》 / 《一代天师》
作者：夏忆
类型：恐怖 / 悬疑
简介：查文斌——茅山派祖印持有者，正天道最后一代掌教传人。他救人于阴阳之间，却引业火烧身，遭天罚阴遣；仗侠肝义胆与一身道术，救活人于阴阳罅隙，渡死人于无间鬼道！诡异古村中，阴差煞言七个村民必死无疑。查文斌却一人逆天而行，将军庙里大战百年邪道，奈何桥上对决阴差，然而，七个村民还是没躲过劫数……此后，查文斌随着一路追寻，引出封山、古蜀国、西羌族等一系列离奇故事。凡人究竟能否改变上天注定的命运？失落的村庄究竟暗藏了多少恐怖故事？数百年未曾找到的答案究竟是什么？
最后一个道士 1-7

复活全人类

作者：狂小风
类型：科幻 / 末世

vue指令安装时参数带-d与不带-d

Fri, 12 Sep 2025 00:00:00 GMT

📌 `pnpm add` 的两个常见参数

命令	说明
`pnpm add 包名`	安装到生产依赖 (dependencies)，打包上线时也会带上
`pnpm add -D 包名` 或 `--save-dev`	安装到开发依赖 (devDependencies)，只在开发/构建时用

📦 为什么有些包用 `-D`，有些不用？

这取决于这个包是否会在「运行时」被用户使用：

🟢 运行时依赖（不加 `-D`）

会在项目实际运行中被使用

这些库的代码会被打进你的最终应用里：

pinia：状态管理，运行时使用
@pinia/nuxt：Nuxt 模块，在 Nuxt 启动时注入运行
pinia-plugin-persistedstate：在浏览器中持久化 store，运行时执行

所以：

pnpm add pinia @pinia/nuxt pinia-plugin-persistedstate

🟡 开发时依赖（要 `-D`）

只在开发、构建、编译阶段用，不会打包进产物

unocss / @unocss/nuxt：是原子化 CSS 引擎，只在开发构建时生成样式，运行时不会执行 JS 逻辑

所以：

pnpm add -D unocss @unocss/nuxt

✅ 总结记忆法

运行时使用 → 不加 -D
只在开发构建用 → 加 -D

什么是杀青？

Sun, 07 Sep 2025 00:00:00 GMT

什么是“杀青”？其实最早可不是拍戏完撒花啊 😂

古代人写字用竹简，竹子表面油油的还容易招虫，咋办？——拿去火上烤一下！烤完水分没了，颜色从绿变白，就叫 “杀青”。这样一来，不光好写字，还能放久点，不怕虫咬。

后来呢，“杀青”就慢慢变味了——写文章完稿也叫杀青。再后来，拍电影电视剧一结束，大家就开个“杀青仪式”，其实就是“终于完事啦，可以收工啦”的意思 ✌️。

顺带一提，茶叶里也有“杀青”，就是用高温把叶子烫一下，保持绿色，方便后续揉捻。所以你喝茶的时候，也算是跟古人有点“杀青缘”了，欸嘿嘿 🍵。

为什么要记录呢？……嗯，闲的。脑子笨，啥都记不住。写下来随便记记，也不知道记下来有什么用，反正就想记着玩。

也是因为刷到几个短视频，像《果宝特攻》《JOJO》那种杀青撒花配BGM的。突然就勾起童年回忆，唉……时间真的快啊，一转眼就过去了。

6.97 09/20 oQx:/ X@z.go 二乔在地府里从后门溜走逃过一劫 # jojo的奇妙冒险 # 杀青梗 # 动漫 # dou+上热门 # 乔瑟夫乔斯达  https://v.douyin.com/TdhA4d2No1s/ 复制此链接，打开Dou音搜索，直接观看视频！

1.23 v@F.uF 05/19 WzT:/ 杀青梗是世界上最伟大的发明.# 果宝特攻 # mvp # 回忆 # 童年 # 杀青  https://v.douyin.com/F9IYsuF6F_Q/ 复制此链接，打开Dou音搜索，直接观看视频！

随手记

Sat, 09 Aug 2025 00:00:00 GMT

拉马努金π公式被用于高精度计算π（圆周率）的值。这个公式是由印度数学家斯里尼瓦瑟·拉马努金（Srinivasa Ramanujan） 在20世纪初发现的，具有极快的收敛速度，因此非常适合用来计算π的数值。

公式解释：

$$ \frac{1}{\pi} = \frac{2\sqrt{2}}{9801} \sum_{k=0}^{\infty} \frac{(4k)!(1103 + 26390k)}{(k!)^4 396^{4k}} $$

组成部分说明：

无穷级数求和符号（$\sum_{k=0}^{\infty}$）：表示该公式是通过将每个 $k$ 值从0开始代入并累加所有项。
阶乘符号（$(4k)!$ 和 $(k!)^4$）：
- $(4k)!$ 是 $4k$ 的阶乘。
- $(k!)^4$ 是 $k!$ 的四次方。
常数项：
- $1103$ 和 $26390$ 是特殊的常数。
- $396^{4k}$：分母中包含指数增长的项，确保该级数收敛非常快。
前面的常数项：
- $\frac{2\sqrt{2}}{9801}$：该项用于缩放结果，确保级数和最终结果相匹配。

重要性质：

快速收敛：这个级数的每一项都迅速减少，因此只需要计算少量项，就能得到非常精确的π值。
计算π的历史意义：该公式是高精度计算π的革命性方法之一。在20世纪，计算机利用这一公式成功计算了数百万位π的小数点。

Git常用指令

Sat, 09 Aug 2025 00:00:00 GMT

Git 操作手册（实用全版）

一、基础概念

工作区：你改代码的地方
暂存区（index）：准备提交的内容
仓库（repo）：Git 管理的数据
HEAD：当前指向的提交
分支：一条提交链

二、初始化与配置

git init                    # 初始化仓库
git clone <url>            # 克隆远程仓库

git config --global user.name "你的名字"
git config --global user.email "你的邮箱"

查看配置：

git config --list

三、基本流程（最常用）

git status                 # 查看状态
git add <file>             # 添加到暂存区
git add .                  # 全部添加

git commit -m "说明"       # 提交

git log                    # 查看提交记录
git log --oneline          # 简洁版

四、分支操作

git branch                 # 查看分支
git branch <name>          # 创建分支
git checkout <name>        # 切换分支
git checkout -b <name>     # 创建并切换

git switch <name>          # 新写法（推荐）

git merge <name>           # 合并分支

删除分支：

git branch -d <name>

五、远程仓库

git remote -v             # 查看远程
git remote add origin <url>

git push -u origin main   # 推送
git push                  # 后续直接推

git pull                  # 拉取并合并
git fetch                 # 只拉取不合并

六、撤销操作（重点）

1. 撤销工作区修改

git checkout -- <file>
# 或
git restore <file>

2. 撤销暂存区

git reset HEAD <file>

3. 回退提交

git reset --soft HEAD~1    # 保留代码
git reset --hard HEAD~1    # 全部回退（危险）

4. 反向提交（安全）

git revert <commit>

七、查看差异

git diff                  # 工作区 vs 暂存区
git diff --cached         # 暂存区 vs 仓库
git diff HEAD             # 工作区 vs 最新提交

八、暂存（stash）

git stash                 # 临时保存
git stash pop             # 恢复并删除
git stash list            # 查看
git stash apply           # 恢复但不删

九、标签（Tag）

git tag                   # 查看
git tag v1.0              # 创建标签
git push origin v1.0      # 推送标签

十、日志与历史

git log --graph --oneline --all
git show <commit>
git reflog                # 查看操作历史（救命用）

十一、冲突处理

出现冲突后：

<<<<<<< HEAD
当前分支内容
=======
目标分支内容
>>>>>>> branch

处理步骤：

手动修改文件
删除冲突标记
git add
git commit

十二、rebase（进阶）

git rebase <branch>

作用：

让提交更线性
替代 merge

交互式：

git rebase -i HEAD~3

可：

合并提交
修改 commit message
删除提交

十三、常见工作流

1. 标准开发流程

git checkout -b feature/xxx
# 开发
git add .
git commit -m "feat: xxx"

git pull --rebase origin main
git push origin feature/xxx

2. 更新本地代码

git pull --rebase

十四、忽略文件

.gitignore

node_modules/
dist/
*.log
.env

十五、子模块（了解）

git submodule add <url>
git submodule update --init --recursive

十六、常见坑

❌ git reset --hard 会丢数据
❌ rebase 后不要强推公共分支
❌ 不要在 main 直接开发
❌ 忘记 pull 就 push → 冲突

十七、救命命令

git reflog                # 找回误删提交
git reset --hard <hash>   # 回到某次状态

Hello World

Fri, 08 Aug 2025 00:00:00 GMT

你好，世界！

这是我的第一篇文章，我将在此记录我的Blog。