Blog

CI/CD 与 GitHub Actions 自动化部署实战

Tue, 15 Sep 2026 17:20:00 +0800

CI/CD（持续集成与持续交付/部署）是一种现代软件工程方法论，通过在代码仓库中自动化执行构建、测试与部署流水线，实现从代码提交到线上生产环境的无人值守闭环。

1. CI/CD 简介

在传统的网站与前后端项目运维中，最普遍的人工操作流程往往是：本地编写代码 → 本地执行编译构建打包 → 打开 FTP/SFTP 传输软件（如 FileZilla、WinSCP 或服务器文件管理器） → 拖拽上传并覆盖服务器目标目录。

这一原始模式存在三个显著工程痛点：

操作机械繁琐：每次细微的代码更新都要手动重复“构建-传输-覆盖”流程，严重打断研发心流。
环境配置耦合：本地开发环境的私有配置（如本地调试域名或测试环境变量）容易在打包时误带入生产，污染线上运行环境。
残留冗余废弃文件：手动文件覆盖仅处理“新增”和“替换”，一旦在本地删除了旧文件或重构了路由目录，服务器目录中残存的废弃历史文件无法自动清理。

CI/CD 正是为了将这一繁琐、易出错的人工运维流程彻底解脱为无人值守的自动化闭环。

1.1 什么是 CI 与 CD

CI/CD 并非单一软件，而是一种敏捷软件工程实践方法，通常由两个紧密衔接的阶段组成：

阶段	英文全称	核心职责	项目映射举例
CI	Continuous Integration （持续集成）	代码频繁合并至主干，并在云端隔离环境自动执行语法检查、依赖安装、单元测试与编译打包，尽早暴露冲突与语法缺陷。	代码推送到主分支后，云端自动拉取代码并运行构建命令进行编译与产物完整性验证。
CD	Continuous Delivery （持续交付）	产物构建测试通过后，自动打包为可随时发布的标准交付包（Release/Artifact），等待人工确认后上线。	编译产物打包存入云端交付物仓库待命，由运维或负责人点击确认发布。
CD	Continuous Deployment （持续部署）	无任何人工干预，只要前面的集成验证通过，新版本立即自动推向真实的生产服务器，实时生效。	编译产物无需人工点击，直接由云端通过 SSH/rsync 增量覆盖生产服务器的部署目录。

2. GitHub Actions 核心概念

GitHub Actions 是 GitHub 官方集成的 CI/CD 自动化平台。它免去了自建 Jenkins 调度节点的高昂维护成本，直接在代码托管仓库内以 YAML 声明式语法编排流水线。

2.1 核心组成要素

GitHub Actions 的运行逻辑基于五个核心抽象概念：

概念/组件	对应配置语法	描述与核心职责
Workflow	name / 文件名	工作流，存放在 .github/workflows 目录下，定义一次完整的自动化任务集合。
Event	on	触发器，定义何时激活工作流（如 push、pull_request 或手动 workflow_dispatch）。
Jobs	jobs	任务单元，由一个或多个 Job 组成。不同 Job 默认并行执行，也可声明依赖串行运行。
Runner	runs-on	运行容器/虚拟机，平台动态分配的纯净环境（如 ubuntu-latest），任务完成后自动销毁。
Steps / Action	steps / uses	步骤与动作，Job 内部由多个 Step 顺序执行，可直接复用开源社区沉淀的 Action 模块。

足迹

Sun, 06 Sep 2026 21:30:00 +0800

步履所及，皆为生活与记忆的印记。

Nginx配置防盗链

Fri, 14 Aug 2026 00:00:00 +0800

我们在日常浏览网页时，偶尔会遇到图片裂开的情况；若试着在新标签页中单独打开该图片的链接，浏览器可能会弹出一个 403 Forbidden（禁止访问） 的错误提示。这通常意味着：当前网页并未在自己的服务器上托管这张图片，而是直接在外链中引用了其他站点的资源。被引用的源站为了保护自身的服务器资源与出口带宽，通过 Nginx 识别出了此类未经授权的外部请求，并主动返回了 403 拒绝访问。

这种用来防范外部网站直接引用本站静态资源的保护机制，就是我们常说的 Nginx 防盗链（Anti-Hotlinking）。

1. 原理浅析：HTTP Referer

浏览器在加载网页内的图片、音视频等资源时，遵循 HTTP 协议规范，通常会在请求头中自动附带一个 Referer 字段，用于告知服务端“这个资源请求是从哪个网页发起的”。

例如，当用户在第三方网站 https://other-site.com 浏览时，页面加载了本站的图片，浏览器向本站发出的请求大致如下：

1GET /logo.png HTTP/1.1
2Host: your-domain.com
3Referer: https://other-site.com/page.html

Nginx 正是通过内置的 ngx_http_referer_module 模块，提取请求头中的 Referer 并与我们设定的白名单进行比对，从而判断请求来源是否合规。

不过，Referer 可能因为浏览器隐私策略、Referrer-Policy、代理或浏览器扩展而缺失，也可以被客户端伪造。因此，Referer 防盗链适合做粗粒度限制，不应作为身份认证或强安全边界。

注意事项：不要把 Referer 白名单当成搜索引擎认证。因为搜索引擎抓取图片时不一定会携带 Referer。本例保留 none，已经允许无来源头的正常请求；如果确实遇到特定爬虫无法访问，应先结合实际请求日志排查，再按业务需要增加白名单。仅凭 Referer 域名无法可靠证明请求来自搜索引擎，也不能单独保证 SEO 效果。

2. 解决方案

为了兼顾系统安全与业务体验，针对未经许可的外部引用，Nginx 通常有两种主流的配置策略：

2.1 直接返回 403 状态码（更轻量、最省带宽）

发现请求来源不合规时立即切断响应，不给对方传输多余数据，这是大多数生产环境的首选方案。

 1# 图片与多媒体资源防盗链配置
 2location ~* \.(gif|jpg|jpeg|png|bmp|webp|avif|svg|mp4|mov)$ {
 3 # 仅对 URL 带版本指纹的静态资源使用 immutable
 4 # 使用单个 Cache-Control 头，避免与 expires 重复设置缓存策略
 5 expires off;
 6 add_header Cache-Control "public, max-age=2592000, immutable";
 7
 8 # 流量很大时可关闭；如需审计或排查盗链，请保留日志或改用条件日志
 9 access_log off;
10
11 # 合法 Referer 白名单配置：
12 # - none: 允许直接在浏览器地址栏打开或从书签访问（无 Referer）
13 # - server_names: 自动匹配本 server 声明的所有合法域名
14 # - *.example.com: 放行 example.com 下的子域名
15 valid_referers none server_names *.example.com;
16
17 # 非法来源直接返回 403 阻断
18 if ($invalid_referer) {
19 return 403;
20 }
21}

核心参数说明：

Nginx 快速入门

Thu, 13 Aug 2026 22:00:00 +0800

1. Nginx 简介

在现代 Web 架构中，Nginx 往往是流量到达服务器的第一道门面。它兼具极高的吞吐能力与轻量资源消耗，常用于静态站点分发与后端服务网关接入。

1.1 什么是 Nginx

Nginx 是一款开源、高性能的 HTTP 服务器与反向代理服务器，核心架构基于单 Master 多 Worker 的异步非阻塞事件驱动模型（Linux 环境下使用 epoll）。

其核心能力：

静态资源直出：高效托管 HTML、CSS、JS 及各类多媒体文件，直接经由内核零拷贝响应，释放后端算力。
反向代理与流量分发：作为内部集群的前置入口，对外暴露统一端口，无感转发后端请求。
虚拟主机路由：支持基于单个端口配置多个域名（Server Name），实现单机多站点的精细隔离。
平滑热升级：内置优秀的信号处理机制，修改配置与更新二进制无需停机，实现零感知运维。

2. Nginx 安装与启动

2.1 包管理器安装

(1) 系统包管理器（推荐日常使用）

Ubuntu / Debian：

1sudo apt update
2sudo apt install -y nginx

CentOS / RHEL：

1sudo yum install -y epel-release
2sudo yum install -y nginx

macOS：

Git 常用命令速查与协作工作流全指南

Fri, 17 Jul 2026 17:35:00 +0800

1. 仓库初始化（Getting a Git Repository）

1.1 工作区 / 暂存区 / 仓库

区域	时机	存储位置
工作区（Working Directory）	add 前	磁盘文件系统
暂存区（Staging Area / Index）	add 后、commit 前	.git/index
本地仓库（Local Repository）	commit 后	.git/objects
远程仓库（Remote Repository）	push 后	远端服务器

1.2 初始化与远端配置

命令	说明	示例
git init	将当前目录初始化为 Git 仓库	git init
git clone	克隆远端仓库到本地	git clone git@github.com:user/repo.git
git remote add origin	为本地仓库绑定远端地址	git remote add origin git@github.com:user/repo.git
git remote add upstream	关联上游原始仓库	git remote add upstream git@github.com:original/repo.git
git remote set-url	修改已有远端地址	git remote set-url origin git@github.com:user/repo-v2.git
git remote -v	查看所有已配置的远端	git remote -v

文章归档

About

Fri, 19 Jun 2026 23:19:26 +0800

关于我

现处广州,大三在读,全栈开发者

关于博客

本站是由我个人建立的博客，在这里，我会分享一些学习心得，技术，所见和所闻。在互联网盛行和 AI 高速发展的今天，记录成为了一种难能可贵的坚持。许多声音来得太快，太满，还未来得及分辨内心真正的回响，新的浪潮就已经覆盖了旧的痕迹。所以我想留下这样一个地方。不为喧哗，不为匆忙，只是安静地把走过的路、想过的事、学到的东西，一点一点写下来。也许它们并不宏大，却都是某一段时间里，我认真生活、认真思考过的证明。

Docker知识点详解

Thu, 18 Jun 2026 21:30:00 +0800

Docker 是一个基于 Linux 内核能力实现的开源应用容器引擎，依托 命名空间（Namespaces） 与 控制组（cgroups） 实现轻量级进程隔离，支持将应用程序及其依赖项统一打包为标准化容器镜像，实现跨环境的敏捷交付与一致性运行。

1. 概述与核心机制

1.1 核心特性与虚拟化差异

容器技术与传统虚拟机（VM）在底层实现上有本质区别：

进程级轻量隔离：容器共享宿主机的操作系统内核，不需要像虚拟机那样虚拟化完整的 Guest OS 与虚拟硬件，秒级启动且系统资源开销极小。
独立的文件系统视图：容器内部拥有独立的用户态文件系统环境（例如 /bin、/etc、/usr、/app），能够独立执行 Linux 用户态程序与服务进程。
环境交付一致性：通过将代码、运行依赖与环境变量整体封装，实现“一次构建，随处运行”，消除开发、测试与生产环境不一致的痛点。

1.2 Windows 与 WSL2 协同运行模式

在 Windows 环境下，Docker Desktop 并非直接运行于 Windows 原生内核之上，而是深度集成并依赖 WSL2（Windows Subsystem for Linux 2）提供的真实 Linux 内核环境：

架构协同关系：Windows 充当宿主操作系统；WSL2 虚拟机实例提供 Linux 内核调用支持；Docker Desktop 统一管理 Docker 守护进程引擎与图形化控制台。
最佳工程实践：建议将项目代码与挂载文件直接存放在 WSL 的 Linux 本地文件系统内（如 /home/user/…），避免跨跨系统 9P 文件协议读写带来的显著性能损耗。

2. 架构与核心概念

Docker 采用标准的 C/S（客户端/服务端）架构，客户端工具与后端守护进程通过 REST API、UNIX 套接字或网络接口进行交互。

2.1 架构角色与核心概念

角色/组件	描述与核心职责
Docker Client	命令行交互工具（docker CLI），负责向服务端分发构建、运行与管理指令。
Docker Daemon (dockerd)	常驻后台的守护进程，负责管理镜像、容器、存储卷与虚拟网络等核心对象。
镜像（Image）	包含了应用程序及其完整运行依赖的只读层叠模板，用于生成容器运行时实例。
容器（Container）	镜像的可运行实例，在镜像只读层之上附加读写层，具备隔离的网络与运行时环境。
镜像仓库（Registry）	集中存储与分发容器镜像的中心服务，分为公有仓库（如 Docker Hub）与私有仓库（如 Harbor）。
Dockerfile	声明镜像构建流程的文本配置文件，逐层定义基础环境、依赖安装与启动参数。
Docker Compose	用于定义和编排多容器协同运行的工具，通过声明式 YAML 文件管理全栈服务。

2.2 Dockerfile 与 Compose 的职责划分

两者处于不同层级的交付链路中，职责边界清晰：

Harness 工程架构深度解析

Tue, 09 Jun 2026 20:30:00 +0800

从架构视角深入解读 Harness 的设计哲学，帮助工程师建立对现代 CI/CD 平台的认知框架

一、Harness 到底是什么

一句话：Harness 是一个构建在 Kubernetes 之上的、以 Delegate 为核心执行引擎的、SaaS 化的软件交付平台。

这句话里有三个关键词，每一个都值得展开。

1. 构建在 Kubernetes 之上

Harness 的控制平面（Control Plane）是一组微服务，运行在 Kubernetes 集群中。这意味着：

弹性伸缩是天然能力，不是事后补丁
多租户隔离通过 K8s 的 namespace 和资源配额实现
服务治理依赖 K8s 原生的服务发现和负载均衡

这不是什么了不起的事——几乎所有现代 SaaS 产品都跑在 K8s 上。但关键在于，Harness 把 K8s 的能力向下暴露给了用户：你的 Pipeline 可以直接操作 K8s 集群进行部署，而不是通过一层中间转换。

2. Delegate 是核心执行引擎（重点）

这是理解 Harness 最关键的一个概念。

Delegate 是一个运行在你基础设施中的进程，负责执行 Pipeline 中的所有任务。它不是 Harness 帮你跑的——它跑在你的环境里。

为什么要这样设计？因为软件交付涉及的操作，绝大多数都需要访问内网资源：代码仓库、制品库、K8s 集群、数据库、云账号。如果这些操作全部由 Harness 的 SaaS 控制平面来执行，就意味着你的内网资源必须对 Harness 开放——这在安全合规层面几乎不可接受。

Delegate 的架构解决了这个问题：

┌─────────────────────────────────────────────────────┐
│ Harness SaaS控制平面 │
│ (Pipeline 编排、状态管理、UI、API) │
└──────────────────────┬──────────────────────────────┘
 │ 出站连接（Delegate 主动拉取任务）
 │ ← 不需要入站端口暴露
┌──────────────────────▼──────────────────────────────┐
│ 你的基础设施 │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ Delegate │ │ Delegate │ │ Delegate │←可部署多个 │
│ └────┬─────┘ └────┬─────┘ └────┬─────┘ │
│ │ │ │ │
│ ┌───▼───┐ ┌────▼───┐ ┌────▼───┐ │
│ │K8s集群 │ │代码仓库 │ │云账号 │ │
│ └───────┘ └────────┘ └────────┘ │
└─────────────────────────────────────────────────────┘

核心设计要点：

Superpowers 使用指南

Sat, 30 May 2026 20:30:00 +0800

如果只先记住一个结论，那么可以记这句：

Superpowers 不是单纯的“代码增强插件”，而是一套把软件开发最佳实践内化为可执行工作流的方法论插件。

它的价值不在于“帮你多补几行代码”，而在于通过一组技能系统，把设计、计划、执行、测试、审查、调试和收尾这些环节串成一个更稳定的开发闭环。

本文会系统回答几个问题：

Superpowers 到底是什么
它和普通代码辅助工具有什么本质区别
它的完整工作流怎么跑
什么时候该自动触发，什么时候适合手动调用
使用中最容易踩的坑是什么

1. Superpowers 到底是什么

Superpowers 是一个面向 Claude Code 的开发流程插件。它不是把一堆零散命令简单打包，而是把软件工程中的一整套高质量实践，组织成可自动触发、可组合、可审查的工作流。

和常见“你提需求，我给代码”的工具相比，它有几个明显不同点：

它会优先帮助你澄清需求，而不是立刻开写
它强调计划拆解，而不是一次性生成大段实现
它默认引入 TDD、代码审查和系统化调试
它允许通过子代理并行处理任务
它把“验证是否真的完成”看得和“写出代码”同样重要

换句话说，Superpowers 关注的不只是产出代码，而是产出一个更可控、更可验证的开发过程。

2. 核心理念是什么

Superpowers 背后最重要的不是某个命令，而是它坚持的几条工程原则。

2.1 测试驱动开发优先

它默认推崇 TDD，也就是经典的 RED -> GREEN -> REFACTOR 循环：

先写一个失败的测试
再写最少的代码让测试通过
最后在测试保护下重构

这会强迫开发从“想当然实现”切换到“先定义预期行为，再补实现”。

2.2 系统化优于临时应对

遇到问题时，它更倾向于：

明确定位问题
收集证据
找根因
用流程和验证收束结果

而不是简单地“试一下这个改法能不能过”。

2.3 简单性优先于复杂炫技

Superpowers 的方法论倾向非常明确：复杂度不是能力的证明，能把问题拆到足够小、足够清楚，才是真正可维护的工程能力。

2.4 验证优先于宣称

“已经修好了”“应该可以了”“理论上没问题”这类表述，在它的工作流里都不算真正完成。必须通过测试、审查、验证或复现消除，结果才算站得住。

3. 它和普通代码辅助工具有什么不同

可以用下面这张表快速理解它的定位：

维度	普通代码辅助工具	Superpowers
主要目标	更快生成代码	更稳地完成完整开发流程
默认行为	直接根据需求写实现	先设计、再计划、再执行
测试态度	可有可无	默认强制引入 TDD
代码审查	往往依赖人工补充	工作流内建审查机制
调试方式	偏经验式试错	强调系统化根因分析
适用对象	单次编码任务	需要流程质量保证的开发任务

所以，Superpowers 更像是“开发过程的组织者”，而不只是“生成代码的助手”。

Java核心面试题与八股知识点速记

Sun, 03 May 2026 11:00:00 +0800

Java 作为现代企业级分布式系统与微服务架构的基石语言，其核心底层机制、集合实现、JVM 运行时原理以及 JUC 并发编程是技术面试与工程实践中最关键的核心基线。本文对高频核心考点进行系统化模块解构与深度剖析，剔除表层快餐记忆，直击底层源码设计与设计权衡。

1. Java 基础语法与核心机制

1.1 面向对象思想与对象创建

面向对象与面向过程是两种截然不同的程序设计范式，在系统建模与工程演进中承担不同职责：

面向过程（POP）：核心以算法步骤为中心，将业务需求拆解为按顺序调用的函数序列。其主要优势在于调用开销低、性能高，常用于底层操作系统开发或单片机固件；缺点在于业务逻辑高度耦合，维护与扩展成本高。
面向对象（OOP）：核心以现实世界或业务概念的模型实体为中心，通过类与对象将数据（属性）与行为（方法）高度聚合，具备三大核心特征： (1) 封装：隐藏对象内部实现细节，仅对外暴露安全受控的访问接口，保护内部数据一致性。 (2) 继承：子类复用并扩展父类的属性与方法，建立代码复用机制，同时构建类型多态体系。 (3) 多态：父类引用指向子类具体实现，在程序运行时动态绑定（动态分派）具体调用的实例方法，是实现低耦合与设计模式的基础。

Java 中创建对象实例的底层途径主要包含四种方式：

new 关键字：最基础的方式，编译器生成 new 字节码指令分配内存，并调用对应的构造函数完成初始化。
反射机制：通过 Class.newInstance() 或 Constructor.newInstance() 动态获取构造器并创建对象，常用于框架依赖注入与动态代理。
对象克隆：目标类实现 Cloneable 接口并重写 clone() 方法，通过 JVM 底层内存拷贝直接生成新对象，不调用任何构造函数。
反序列化机制：借助 ObjectInputStream 将字节流反序列化为内存对象实例，同样不依赖构造函数执行。

在对象拷贝场景中，浅拷贝与深拷贝存在本质区别：

浅拷贝（Shallow Copy）：仅克隆基本数据类型的字段值；对于引用类型字段，仅复制对象引用的内存地址，新旧对象依然共享同一个底层堆对象实例。
深拷贝（Deep Copy）：不仅复制基本数据类型，还会递归克隆所有引用对象，在堆内存中完整重建整棵对象关系树，新旧对象完全隔离独立。深拷贝通常通过手动重写 clone()、序列化反序列化（如 Jackson/Kryo）或拷贝构造器实现。

1.2 核心关键字底层剖析

Java 语言关键字直接影响类的继承结构、内存分配以及字段行为：

(1) final 关键字的作用边界：

修饰类：表明该类为最终类，不可被任何类继承，其所有成员方法隐式声明为 final（例如 String、Integer 等不可变类，确保安全性与不可篡改性）。
修饰方法：锁定方法逻辑，禁止任何子类重写（Override），但子类依然可以继承使用；JIT 编译器可据此进行内联展开优化。
修饰变量：作为常量使用，必须在声明时或构造器执行完毕前完成显式赋值，赋值后引用地址不可变。若修饰的是引用类型，仅保证指针指向不变，所指向对象内部的状态与属性仍然可变。

(2) static 关键字的加载行为：

修饰变量与方法：归属于类元信息本身而非特定对象实例。在 JVM 类加载的准备阶段完成空间分配并赋零值，在初始化阶段执行显式赋值，全局仅存在一份内存，可直接通过类名访问。
修饰代码块：静态代码块在类初次被主动使用、执行类构造器方法（clinit）时按书写顺序触发，生命周期内仅执行一次，常用于初始化重量级系统资源。
静态导包：通过 import static 语法直接导入指定类的公共静态成员，调用时无需携带类名前缀。

(3) instanceof 关键字与类型模式匹配：

Kafka集成与Spring Boot实战详解

Sun, 26 Apr 2026 16:45:00 +0800

Apache Kafka 是一个高吞吐、分布式的流处理平台与开源消息引擎，依托 追加日志（Commit Log）、零拷贝（Zero-Copy） 与 分区并发模型 实现海量事件的持久化存储与低延迟流转。

本文深入介绍 Spring Boot 与 Kafka 的工程集成方案，涵盖本地环境准备、核心依赖配置、生产者与消费者开发、JSON 对象序列化以及分布式事务消息等实践。

1. 什么是 Kafka

Apache Kafka 是一个分布式事件流平台，核心基于发布与订阅（Pub/Sub）模式构建，具备高并发、高吞吐、可水平扩展与高容错等企业级特征。

1.1 核心特性

发布订阅与消息持久化：基于追加日志（Commit Log）组织数据，所有写入均为磁盘顺序 I/O，支持消息长期持久化与多组独立消费。
实时流式数据处理：支持毫秒级流式数据接入与处理，可与 Flink、Spark Streaming 等大数据计算框架深度协同。
高吞吐与水平扩展：通过分区（Partition）将主题数据分散在多个 Broker 节点，支持集群无损横向伸缩与并行高并发读写。
高可用与多副本机制：提供 Leader 与 Follower 多副本冗余，配合 ISR（In-Sync Replicas）机制保障节点故障时数据不丢失。

1.2 核心应用场景

在分布式与微服务架构中，Kafka 通常充当事件中枢或数据传输管道，广泛应用于以下业务场景：

微服务间异步解耦：将非核心链路业务（如短信通知、权益发放、统计分析）解耦为异步事件驱动，降低服务间调用耦合与故障扩散风险。
海量日志收集与监控：作为 ELK（Elasticsearch + Logstash + Kibana）或 ClickHouse 的前置缓冲区，汇聚全链路访问日志与系统监控指标。
流数据管道与同步：捕获关系型数据库变更数据（CDC），实时同步并分发至搜索引擎、数据仓库或缓存集群。
流量削峰填谷：在秒杀或大促等突发流量高峰期暂存高并发请求，下游根据自身承载能力匀速拉取消费，保护核心数据库。

2. 环境准备

在开始集成开发之前，请确保本地或服务器已完成基础运行环境与服务的安装部署。

2.1 依赖环境要求

JDK：JDK 1.8 或更高版本（推荐 JDK 17 / 21）。
Spring Boot：Spring Boot 2.7.x 或 3.x。
构建工具：Maven 3.6+ 或 Gradle 7+。
Kafka 服务端：Kafka 2.8+（含内置 Zookeeper 或 KRaft 模式）。

2.2 启动本地 Kafka 与 Zookeeper

(1) 访问 Kafka 官方下载页面 获取二进制解压包，解压后进入程序根目录。

RabbitMQ集成与Spring Boot实战详解

Thu, 23 Apr 2026 15:20:00 +0800

RabbitMQ 是一个基于 AMQP（Advanced Message Queuing Protocol） 协议构建、由 Erlang 语言编写的高性能企业级消息中间件，依托 交换机（Exchange）、绑定键（Routing Key） 与 灵活的路由分发机制 实现分布式架构下高并发、高解耦与高可靠的消息流转。

本文深入介绍 Spring Boot 与 RabbitMQ 的工程集成方案，涵盖本地环境准备、核心依赖配置、拓扑结构集中声明、生产者与消费者开发、手动确认与限流以及死信延时队列等实践。

1. 什么是 RabbitMQ

RabbitMQ 是一个支持多协议、功能完备的企业级分布式消息引擎，基于 Erlang 语言的高并发 Actor 模型与轻量级进程机制构建，具备低延迟、高可靠性保障、灵活的路由策略与完善的可视化管理能力。

1.1 核心特性

灵活的路由模型与消息持久化：基于交换机（Exchange）与绑定（Binding）解耦生产与消费端，支持 Direct、Topic、Fanout 等多种路由策略，并提供交换机、队列与消息三层持久化机制。
完善的可靠性投递与确认机制：提供生产者发布确认（Publisher Confirm）、返回监听（Return Callback）与消费者手动应答（Manual Ack），保障消息在全链路传输过程中不丢失。
流量削峰与服务限流（QoS Prefetch）：支持在 Channel 通道级别与消费者级别配置 prefetchCount 预取阈值，下游根据自身承载能力拉取并处理消息，防止突发流量压垮消费者。
丰富的死信机制与延迟任务支持：通过死信交换机（DLX / Dead Letter Exchange）与队列/消息 TTL 组合，优雅解决消费异常兜底、重试收容与延时任务调度需求。

1.2 核心应用场景

在分布式与微服务架构中，RabbitMQ 通常充当解耦中枢与缓冲管道，广泛应用于以下业务场景：

微服务间异步解耦：将核心业务与非核心流程（如注册成功后的邮件发送、短信通知、优惠券发放）解耦为异步事件驱动，降低服务间调用时延与系统雪崩风险。
流量削峰填谷：在秒杀大促、抢购活动等短时瞬时流量冲击下充当缓冲区，将瞬时高并发请求暂存至队列中，后端服务按照既定消费速率匀速处理，保护底层数据库。
延时任务与超时订单取消：利用队列的 x-message-ttl 配合死信交换机（DLX），或集成延时交换机插件（rabbitmq_delayed_message_exchange），实现未支付订单 30 分钟超时自动关单、定时状态同步等延迟处理场景。
异常重试与死信收容：对于消费端业务异常、重试耗尽或非法报文，自动转发至死信队列（DLQ）进行隔离归档，配合告警通知并提供人工排查补偿机制。

2. 环境准备

在开始集成开发之前，请确保本地或服务器已完成基础运行环境与服务的安装部署。

2.1 依赖环境要求

JDK：JDK 1.8 或更高版本（推荐 JDK 17 / 21）。
Spring Boot：Spring Boot 2.7.x 或 3.x。
构建工具：Maven 3.6+ 或 Gradle 7+。
RabbitMQ 服务端：RabbitMQ 3.8+（需匹配 Erlang/OTP 对应运行时版本）。

2.2 启动本地 RabbitMQ 与服务管理

(1) Windows 服务运维命令（需以管理员权限打开 PowerShell）：

LLM Wiki：面向 Agent 工程的知识编译层

Sat, 04 Apr 2026 10:54:03 +0800

如果只先记住一个结论，那么可以记这句：

LLM wiki 不是“让 AI 帮你整理笔记”，而是把项目知识从原始资料提升为 Agent 可消费、可引用、可演化的知识中间层。

这个判断的关键在于，问题并不只是“资料有没有被存下来”，而是“资料是否已经被整理成 Agent 可以稳定工作的形状”。在这件事上，RAG 和 LLM wiki 处理的根本不是同一层问题。Andrej Karpathy 提出的 llm-wiki.md 范式给出的也不是一个笔记软件教程，而是一种把知识从原始材料编译成可维护工作上下文的思路。

本文想讨论的是三个问题：

LLM wiki 到底是什么
它和 RAG 的边界到底在哪里
如果要把它落到工程实践里，最小实现应该长什么样

1. Agent 真正缺的不是“更多文档”，而是知识编译层

很多仓库并不缺文档。

README、ADR、issue、PR、聊天记录、代码注释、发布记录，甚至临时会议纪要，往往已经足够多。问题在于，这些材料大多是围绕“人怎么理解系统”自然长出来的，而不是围绕“Agent 应该如何进入系统、命名概念、定位事实、拼装上下文”组织出来的。

这会带来几个很典型的摩擦：

资料很多，但没有稳定入口
术语存在，但定义分散甚至漂移
同一个问题需要每次重新检索和重新拼接上下文
原始资料适合追溯事实，不适合直接充当工作层

所以 LLM wiki 试图解决的，不是“把一堆东西再存一遍”，而是另一件更具体的事：

它的价值不在存储，而在预编译；不在收集，而在把知识变成可持续复用的中间表示。

Karpathy 在原始 gist 里把这件事描述得很清楚：系统并不直接依赖原始材料回答问题，而是先把原始材料经过整理，沉淀成持续更新的 wiki 层，并由 schema 约束其结构与工作流，再把它作为后续查询和工作的主上下文层。来源

2. 与 RAG 的绝对区分：一个是运行时召回，一个是离线知识编译

很多讨论会把 LLM wiki 和 RAG 混在一起，但这两者并不是同义替换。

RAG 的经典定义来自 Lewis 等人的论文 Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks：模型在生成前，先从外部知识源检索相关内容，再把检索结果并入生成过程。论文链接

LeetCode Hot 100 题解合集

Mon, 16 Mar 2026 14:30:00 +0800

索引

哈希

难度	题号	题目	题解
简单	1	两数之和	题解
中等	49	字母异位词分组	题解
中等	128	最长连续序列	题解

双指针

难度	题号	题目	题解
简单	283	移动零	题解
中等	11	盛最多水的容器	题解
中等	15	三数之和	题解

滑动窗口

难度	题号	题目	题解
中等	3	无重复字符的最长子串	题解
中等	438	找到字符串中所有字母异位词	题解

子串

难度	题号	题目	题解
中等	560	和为 K 的子数组	题解

普通数组

难度	题号	题目	题解
中等	53	最大子数组和	题解
中等	56	合并区间	题解
中等	189	轮转数组	题解
中等	238	除自身以外数组的乘积	题解

矩阵

难度	题号	题目	题解
中等	73	矩阵置零	题解
中等	54	螺旋矩阵	题解
中等	48	旋转图像	题解
中等	240	搜索二维矩阵 II	题解

链表

难度	题号	题目	题解
简单	160	相交链表	题解
简单	206	反转链表	题解
简单	234	回文链表	题解
简单	141	环形链表	题解
简单	21	合并两个有序链表	题解
中等	142	环形链表 II	题解
中等	2	两数相加	题解
中等	19	删除链表的倒数第 N 个结点	题解
中等	24	两两交换链表中的节点	题解
中等	148	排序链表	题解
中等	146	LRU 缓存	题解
中等	138	随机链表的复制	题解

二叉树

难度	题号	题目	题解
简单	94	二叉树的中序遍历	题解
简单	104	二叉树的最大深度	题解
简单	226	翻转二叉树	题解
简单	543	二叉树的直径	题解
简单	108	将有序数组转换为二叉搜索树	题解
中等	102	二叉树的层序遍历	题解
中等	98	验证二叉搜索树	题解
中等	230	二叉搜索树中第 K 小的元素	题解
中等	199	二叉树的右视图	题解
中等	114	二叉树展开为链表	题解
中等	105	从前序与中序遍历序列构造二叉树	题解
中等	437	路径总和 III	题解
中等	236	二叉树的最近公共祖先	题解

图论

难度	题号	题目	题解
中等	200	岛屿数量	题解
中等	994	腐烂的橘子	题解
中等	207	课程表	题解
中等	208	实现 Trie (前缀树)	题解

回溯法

难度	题号	题目	题解
中等	46	全排列	题解
中等	78	子集	题解
中等	17	电话号码的字母组合	题解
中等	39	组合总和	题解
中等	22	括号生成	题解
中等	79	单词搜索	题解
中等	131	分割回文串	题解

二分查找

难度	题号	题目	题解
简单	35	搜索插入位置	题解
中等	74	搜索二维矩阵	题解
中等	34	在排序数组中查找元素的第一个和最后一个位置	题解
中等	33	搜索旋转排序数组	题解
中等	153	寻找旋转排序数组中的最小值	题解

栈

难度	题号	题目	题解
简单	20	有效的括号	题解
中等	155	最小栈	题解
中等	394	字符串解码	题解

堆

难度	题号	题目	题解
中等	215	数组中的第K个最大元素	题解
中等	347	前 K 个高频元素	题解

贪心算法

难度	题号	题目	题解
简单	121	买卖股票的最佳时机	题解
中等	55	跳跃游戏	题解
中等	45	跳跃游戏 II	题解
中等	763	划分字母区间	题解

动态规划

难度	题号	题目	题解
简单	70	爬楼梯	题解
简单	118	杨辉三角	题解
中等	198	打家劫舍	题解
中等	279	完全平方数	题解
中等	322	零钱兑换	题解
中等	139	单词拆分	题解
中等	300	最长递增子序列	题解
中等	152	乘积最大子数组	题解
中等	416	分割等和子集	题解

多维动态规划

难度	题号	题目	题解
中等	62	不同路径	题解
中等	64	最小路径和	题解
中等	5	最长回文子串	题解
中等	1143	最长公共子序列	题解
中等	72	编辑距离	题解

技巧

难度	题号	题目	题解
简单	136	只出现一次的数字	题解
简单	169	多数元素	题解
中等	75	颜色分类	题解
中等	31	下一个排列	题解
中等	287	寻找重复数	题解

哈希

方法代码	核心作用	代码示例 / 返回值
hashmap.keys()	获取字典中所有的键 (Key)	[‘aet’, ‘ant’]
hashmap.values()	获取字典中所有的值 (Value)	[[’eat’, ’tea’], [’tan’]]
hashmap.items()	同时获取所有的键和值，常用于循环	for key, val in hashmap.items():
hashmap.get(key, default)	安全获取值，若键不存在则返回设定的默认值	hashmap.get(“aet”, [])
hashmap[key] = value	新增或修改指定的键值对	hashmap[“aet”] = [“eat”]
hashmap.pop(key)	删除指定的键，并返回它对应的值	words = hashmap.pop(“aet”)
hashmap.clear()	清空字典里的所有内容	hashmap.clear()
hashmap.update(dict2)	将另一个字典的数据合并到当前字典中	hashmap.update(other_dict)
key in hashmap	判断某个键是否在字典中 (返回布尔值)	if “aet” in hashmap:
len(hashmap)	统计并返回字典中键值对的总数量	count = len(hashmap)

1. 两数之和

题目描述

给定一个整数数组nums和一个整数目标值target，请你在该数组中找出和为目标值target的那两个整数，并返回它们的数组下标。你可以假设每种输入只会对应一个答案，并且你不能使用两次相同的元素。你可以按任意顺序返回答案。

Home Links

Mon, 01 Jan 0001 00:00:00 +0000

Blog

CI/CD 与 GitHub Actions 自动化部署实战

1. CI/CD 简介

1.1 什么是 CI 与 CD

2. GitHub Actions 核心概念

2.1 核心组成要素

足迹

Nginx配置防盗链

1. 原理浅析：HTTP Referer

2. 解决方案

2.1 直接返回 403 状态码（更轻量、最省带宽）

Nginx 快速入门

1. Nginx 简介

1.1 什么是 Nginx

2. Nginx 安装与启动

2.1 包管理器安装

Git 常用命令速查与协作工作流全指南

1. 仓库初始化（Getting a Git Repository）

1.1 工作区 / 暂存区 / 仓库

1.2 初始化与远端配置

Archives

文章归档

About

关于我

关于博客

Docker知识点详解

1. 概述与核心机制

1.1 核心特性与虚拟化差异

1.2 Windows 与 WSL2 协同运行模式

2. 架构与核心概念

2.1 架构角色与核心概念

2.2 Dockerfile 与 Compose 的职责划分

Harness 工程架构深度解析

一、Harness 到底是什么

1. 构建在 Kubernetes 之上

2. Delegate 是核心执行引擎（重点）

Superpowers 使用指南

1. Superpowers 到底是什么

2. 核心理念是什么

2.1 测试驱动开发优先

2.2 系统化优于临时应对

2.3 简单性优先于复杂炫技

2.4 验证优先于宣称

3. 它和普通代码辅助工具有什么不同

Java核心面试题与八股知识点速记

1. Java 基础语法与核心机制

1.1 面向对象思想与对象创建

1.2 核心关键字底层剖析

Kafka集成与Spring Boot实战详解

1. 什么是 Kafka

1.1 核心特性

1.2 核心应用场景

2. 环境准备

2.1 依赖环境要求

2.2 启动本地 Kafka 与 Zookeeper

RabbitMQ集成与Spring Boot实战详解

1. 什么是 RabbitMQ

1.1 核心特性

1.2 核心应用场景

2. 环境准备

2.1 依赖环境要求

2.2 启动本地 RabbitMQ 与服务管理

LLM Wiki：面向 Agent 工程的知识编译层

1. Agent 真正缺的不是“更多文档”，而是知识编译层

2. 与 RAG 的绝对区分：一个是运行时召回，一个是离线知识编译

LeetCode Hot 100 题解合集

索引

哈希

双指针

滑动窗口

子串

普通数组

矩阵

链表

二叉树

图论

回溯法

二分查找

栈

堆