今天在使用testify框架写单元测试的时候有这样一个需求： 对于一个方法来说，可能会有很长的上下文链路数据。 按照正常的单元测试流程，这个时候我们需要按照接口的逻辑来事先mock好原始未处理的数据，并且定义最终想要的数据结果。定义好不同的test case 尽可能的覆盖到每一个if else，才可以通过后续的ci 流程。 对于一些特殊的case，我们需要一些特殊的操作：

测试前置处理-> 运行测试代码 -> 测试后处理

需要在测试前后对数据进行预处理，如：事先存入一些数据，测试后再删除这些数据。

这个时候按照官方文档，应该写一个afterEachTest，写在方法TearDownTest，并且绑定在testify默认创建的suit上。

// TearDownTest 在每个测试方法执行后调用，用于清理测试数据
func (ts *LogicsTestSuite) TearDownTest() {
    ts.afterEachTest()
}

这个时候就有奇怪的地方了，我并没有在我的测试方法中手动的运行这个TearDownTest，它究竟是如何运行的呢？

问题分析

其实key就在 https://github.com/stretchr/testify/blob/master/suite/suite.go 这里

简化的源代码如下:

package main

import (
    "fmt"
    "reflect"
    "strings"
)

// ====== 模拟 testify 的接口定义 ======

// 测试套件级别的接口
type SetupAllSuite interface {
    SetupSuite()
}

type TearDownAllSuite interface {
    TearDownSuite()
}

// 每个测试级别的接口
type SetupTestSuite interface {
    SetupTest()
}

type TearDownTestSuite interface {
    TearDownTest()
}

// ====== 模拟你的测试套件 ======

type MyTestSuite struct {
    // 注意：这里不需要显式嵌入任何东西
    testData string
}

// 你实现了这些方法，就等于实现了对应的接口
func (s *MyTestSuite) SetupSuite() {
    fmt.Println("🏠 SetupSuite: 整个测试套件开始前的初始化")
}

func (s *MyTestSuite) TearDownSuite() {
    fmt.Println("🏠 TearDownSuite: 整个测试套件结束后的清理")
}

func (s *MyTestSuite) SetupTest() {
    fmt.Println("  ⚡ SetupTest: 每个测试开始前的准备")
    s.testData = "fresh data"
}

func (s *MyTestSuite) TearDownTest() {
    fmt.Println("  ⚡ TearDownTest: 每个测试结束后的清理")
    s.testData = ""
}

// 测试方法（必须以 Test 开头）
func (s *MyTestSuite) TestMethod1() {
    fmt.Println("    ✅ TestMethod1 执行，测试数据:", s.testData)
}
func (s *MyTestSuite) TestMethod2() {
    fmt.Println("    ✅ TestMethod2 执行，测试数据:", s.testData)
}
// ====== 模拟 testify 的 Run 函数 ======

func RunTestSuite(suite interface{}) {
    fmt.Println("=== testify.Run() 开始执行 ===")
    // 1. 套件级别的钩子
    // 注意：这里是 testify 框架在主动调用！
    if setupAllSuite, ok := suite.(SetupAllSuite); ok {
        setupAllSuite.SetupSuite()
    }
    // 使用 defer 确保最后调用
    if tearDownAllSuite, ok := suite.(TearDownAllSuite); ok {
        defer tearDownAllSuite.TearDownSuite()
    }
    // 2. 通过反射找到所有测试方法
    suiteType := reflect.TypeOf(suite)
    suiteValue := reflect.ValueOf(suite)

    for i := 0; i < suiteType.NumMethod(); i++ {
        method := suiteType.Method(i)

        // 查找以 Test 开头的方法
        if strings.HasPrefix(method.Name, "Test") {
            fmt.Printf("\n--- 执行 %s ---\n", method.Name)
            // 3. 每个测试的钩子调用
            // SetupTest - 测试前
            if setupTestSuite, ok := suite.(SetupTestSuite); ok {
                setupTestSuite.SetupTest()
            }
            // 使用 defer 确保测试后调用
            if tearDownTestSuite, ok := suite.(TearDownTestSuite); ok {
                defer tearDownTestSuite.TearDownTest()
            }
            // 4. 执行实际的测试方法
            method.Func.Call([]reflect.Value{suiteValue})
        }
    }
    fmt.Println("\n=== testify.Run() 执行完成 ===")
}
func main() {
    suite := &MyTestSuite{}
    RunTestSuite(suite)
}

这里采用了模版方法设计模式。 在之前定义了生命周期的相关接口和方法，在Run方法中会使用类型断言来查看是否已经实现了TearDownTest interface，如果实现了，就调用interface中定义的方法。 在go中，对于一个interface ，我们不需要显式的去implement定义它的实现，而是采用非侵入性接口（Implicit Interfaces）+ 结构匹配（Structural Typing）的一种ducking type 的设计方式。 在这里就可以体现这种设计的优势，如果我们使用Java这种需要显式impl的方式那么这里就会这样写：

生命周期定义：

// 定义多个接口
public interface SetupAllSuite {
    void setupSuite();
}

public interface TearDownAllSuite {
    void tearDownSuite();
}

public interface SetupTestSuite {
    void setupTest();
}

public interface TearDownTestSuite {
    void tearDownTest();
}

实现：

public class MyTestSuite implements 
        SetupAllSuite, TearDownAllSuite, 
        SetupTestSuite, TearDownTestSuite {

    private String testData;

    @Override
    public void setupSuite() {
        System.out.println("🏠 SetupSuite: 整个测试套件开始前的初始化");
    }

    @Override
    public void tearDownSuite() {
        System.out.println("🏠 TearDownSuite: 整个测试套件结束后的清理");
    }

    @Override
    public void setupTest() {
        System.out.println("  ⚡ SetupTest: 每个测试开始前的准备");
        testData = "fresh data";
    }

    @Override
    public void tearDownTest() {
        System.out.println("  ⚡ TearDownTest: 每个测试结束后的清理");
        testData = "";
    }

    public void testMethod1() {
        System.out.println("    ✅ TestMethod1 执行，测试数据: " + testData);
    }

    public void testMethod2() {
        System.out.println("    ✅ TestMethod2 执行，测试数据: " + testData);
    }
}

这样一比是不是就可以显著看出区别？

gpt 总结了一个表格如下：

总结

这种设计模式的好处在于，它能够在保持整体流程一致的前提下，允许不同的实现类根据自身需求灵活调整具体的执行细节。 通过将通用逻辑上移到抽象父类中，模板方法模式有效地减少了重复手动调用代码，从而提升系统的可维护性与可扩展性。 对于子类，我们只需关注自身差异化的部分，实现起来更加专注且清晰，同时也避免了因修改整体流程而带来的连锁影响。 这种模式让系统在结构上保持稳定，变化部分被局部化处理，变得类似积木一样“可加载”，使得逻辑更清晰和简洁。

Reference

https://github.com/stretchr/testify https://refactoringguru.cn/design-patterns/template-method

参与了一个内部效率提升项目（边角料项目）后要发到内部的测试机器上。内部的测试机器上并没有配置集群，没有一个专门的ingress或者说是网关来处理请求分发。

并且这个测试机器属于多个部门，导致机器环境很复杂，一台物理机安装有多个nginx，有直接host安装的，也有在容器上运行的。

由于这是一个内部项目，没有必要专门部署一个minio，but 项目需要上传文件，所以就直接保存在server的目录下，简单配置了一下nginx的配置，配置如下:

    location /static/ {
        alias /data/www/nuwa/uploads/;
        # 禁用autoindex（避免目录被列出）
        autoindex off;
        # 设置缓存头（可选）
        expires 30d;
        # 确保允许访问
        satisfy any;
        allow all;
        access_log /var/log/nginx/access_xxx.log;
    }

配置完成并且重启nginx后，前端上传文件成功但是查询返回​​403 Forbidden 错误。

Nginx 返回 403 Forbidden 错误通常表示服务器（Nginx）拒绝了客户端访问所请求资源的请求。这通常是权限或配置方面的问题。

走个弯路

根据以往的经验，403 的问题通常是由于路径配置错误导致的，这里是使用的是alias，来快速过一下alias 和root 的区别。

区别：

来个🌰：

经检查，路径配置正确，上传文件可以正常上传，但是尝试读取的时候会报403，这就很奇怪。

权限&用户问题排查

在检查nginx日志的时候发现如下输出：

2025/07/10 17:50:53 [error] 51412#51412: *1 open() "/data/www/xxx/uploads/2025/07/10/39855bb0-bbbc-43bd-a053-860457276413.png" failed (13: Permission denied), client: 10.66.67.150, server: _,localhost, request: "GET /static/2025/07/10/39855bb0-bbbc-43bd-a053-860457276413.png HTTP/1.1", host: "10.4.20.4:28001"

这里的蛛丝马迹似乎在指明，这是一个由文件访问权限导致的异常。

当讨论到权限问题，用户以及角色问题就很明显是绕不开的话题了。

Nginx 在其运行中通常涉及到两个主要的用户角色，具体使用哪个非特权用户取决于操作系统发行版或安装方式了。

Nginx的用户种类

1. Nginx 进程的运行用户（非特权用户）

这是 Nginx 工作进程 (Worker Processes) 实际运行时所使用的用户，它是出于安全考虑而设置的。

这个用户拥有对网站文件进行读取（r）和对目录进行遍历（x）的权限。

根据不同的操作系统或安装方式，默认的非特权用户通常是以下之一：

这个用户是由 Nginx 配置文件 nginx.conf 中 user 指令 所决定的，通常位于文件顶部：

Nginx

# 示例：Debian/Ubuntu 上的默认配置
user www-data;
worker_processes auto;

如果看到 user 指令设置了哪个用户，那么 Nginx 的工作进程就会以这个用户的身份运行。

2. Master 进程用户（特权用户）

Nginx 启动时，会有一个主进程 (Master Process) 负责读取配置文件、管理工作进程，以及绑定到端口（尤其是低于 1024 的端口，如 HTTP 的 80 端口和 HTTPS 的 443 端口）。

• 这个主进程通常以 root 用户的身份运行。

这是必要的，因为只有 root 用户才有权限绑定到 1024 以下的特权端口。一旦绑定成功，主进程就会创建非特权用户的工作进程来处理实际的客户端请求，以最大限度地保障安全性。

深入权限排查

来检查nginx worker 进程的运行用户

commend: ps aux | grep nginx

可以看到worker process的角色是www-data，通过日志分析输出，基本可以确定问题出在文件权限上。

文件创建和权限继承

在案例中，文件是通过应用上传创建的：

# 创建的目录结构
/data/www/xxx/uploads/2025/07/10/xxx.png

查看文件权限：

-rw-r--r-- 1 root root 2 Jul 10 18:04 test.txt

问题就在这里：

• 文件属主是 root

• nginx worker 进程用户是 www-data

• www-data 属于 other 用户组

• 虽然 other 有读权限（r--），但是nginx访问文件，是需要x权限

Linux目录权限的特殊性

例如

# 创建测试目录
mkdir test_dir
chmod 644 test_dir  # drw-r--r-- 有读权限但无执行权限

# 尝试访问
cd test_dir          # 失败：Permission denied
ls test_dir          # 失败：Permission denied
cat test_dir/file    # 即使知道完整路径也失败

原因：目录的 x 权限控制用户能否：

• 进入目录（cd）

• 访问目录内的文件和子目录

• 查看文件的元数据

没有 x 权限，我们即使有 r 权限也无法访问。

权限链

因此我们访问 /data/www/xxx/uploads/2025/07/10/xxx.png 需要：

/data     (x权限)
└── www   (x权限)
    └── xxx (x权限)
        └── uploads (x权限)
            └── 2025 (x权限)
                └── 07 (x权限)
                    └── 10 (x权限)
                        └── xxx.png (r权限)

任何一个环节缺少 x 权限，就不能正确的访问这个文件。

解决方案

使用ACL实现权限继承

ACL 的主要作用是允许你对文件或目录设置额外的、非标准的权限规则。我们默认的权限规则是通过UGO（user group other）和umask来进行控制的。

umask

在 Linux 中，umask 影响新创建文件权限的机制是固定的，并且遵循 文件基础权限 (666) 减去 umask 值的原则。umask 的值是一个八进制数字，用于屏蔽掉基础权限中的对应位。

Tips： 出于安全考虑，文件系统在创建文件时，默认不会赋予执行 (x) 权限，因此最大权限是 666，而不是 777。

规则：新文件/目录权限=文件/目录基础权限−umask

例如：

ekreke@ekrekes-MacBook-Air study % mkdir tmp
ekreke@ekrekes-MacBook-Air study % ls -alth
total 0
drwxr-xr-x@  6 ekreke  staff   192B Oct 18 17:43 .
drwxr-xr-x@  2 ekreke  staff    64B Oct 18 17:43 tmp
...
drwxr-xr-x@  7 ekreke  staff   224B Jun 13 13:19 ..
ekreke@ekrekes-MacBook-Air study % umask
022

但是这里会有一个问题，权限无法继承，umask 是一个全局或进程级的减法器，它与父目录当前设置的权限是无关的。无论父目录是 777 还是 700，新文件的权限都只取决于当前的 umask。

为了解决这个问题，我们可以使用ACL（Access Control Lists）用来在我们在父目录下创建新文件的时候，自动的分配文件访问所需要的权限，在此之前，我们需要设置一下目录的ugo权限。

# 递归修改所有权：将目录和所有内容的所有权交给Nginx运行用户
sudo chown -R www-data:www-data /data/www/nuwa/uploads

# 确保目录和父目录有执行权限
sudo chmod 775 /data/www/nuwa/uploads

# 确保所有父目录对Nginx work process 有执行权限
sudo chmod +x /data /data/www /data/www/nuwa

ACL设置:

# 1. 安装ACL工具（如果未安装）
sudo apt install acl

# 2. 设置默认ACL，让新创建的文件自动继承权限
sudo setfacl -R -d -m u::rwx,g::rx,o::rx /data/www/nuwa/uploads

# 3. 验证ACL设置
getfacl /data/www/nuwa/uploads

输出应该包含：

default:user::rwx
default:group::r-x
default:other::r-x

这样，给other分配了r，x作为 nginx的work process 就可以正常的访问静态资源了。

为什么会发生这个问题？

这个问题发生的核心原因是权限的错位。

1. 用户身份冲突： 负责上传文件的应用进程是root用户，和负责提供访问服务的 Nginx 工作进程（www-data）不是同一个用户。

2. 权限级别降级： Nginx 进程 (www-data) 无法以文件的“所有者”或“所属组”身份访问，只能被归为“其他用户 (Other)”类别。

3. umask 限制： 文件在创建时，受应用程序当前运行环境的 umask 影响，默认权限被设置为 644 或更严格，屏蔽了“其他用户”所需的读 (r) 权限。

4. 目录遍历受阻： 即使文件有读权限，从根目录到文件的路径链上，任意一级目录对 www-data 用户（“其他用户”）缺少执行 (x) 权限，也会导致 Nginx 无法定位和打开文件。

5. 最重要的一点，我们绑定的静态资源路径是“/data“ 下 而不是 “/var”下。/var 目录是 Linux 文件系统层级标准（FHS）规定的用于存放经常变化文件的地方。默认的权限就是755，包含了O用户的r和x权限。所以说我们正常在/var 目录下绑定资源，很少会遇见这种问题。

最佳实践

1. 预创建目录并设置权限

    # 部署时就设置好，var下是会有nginx所需的默认权限
    sudo mkdir -p /var/www/uploads
    sudo chown -R www-data:www-data /var/www/uploads
    sudo chmod 755 /var/www/uploads
   

2. 使用标准路径

   1. 对于nginx引用的内容，尽量使用 var/www 或 /usr/share/nginx/html

   2. 如果必须使用自定义路径，确保设置了正确的权限。

3. 设置合理的umask

    # 在应用启动脚本中设置
    umask 022  # 新文件权限 644，新目录权限 755
   

Reference

https://linux.vbird.org/linux_basic_train/centos8/unit10.php

这是Learn With Agent 的第一篇博客，这个系列（不知道有没有后续了）是想通过agent辅助进行快速的学习（过概念）掌握一些相关的知识。之后再通过agent辅助开发，应该也能做出来个7788。对于AI还有很多思考，另起一个博客再说吧就。

因为网络和经费原因，这里使用的是CC+GLM 4.6 & Gemini 系列。🈚️广，文字为百分百人类手敲&传统CV大法。

JSX

JSX是React生态中占据很重要的部分，JSX是一种语法拓展，它可以允许用户在js中写类似html的标签结构。 JSX还是一种描述UI的方式。对于react component，JSX像是镜像，而react component更像容器，它的作用就是将JSX渲染成真实的DOM。

// 1. 这是一个 React 组件（函数）
function Welcome(props) {
  // 2. 组件在它的 return 语句中使用了 JSX
  return (
    // 这是 JSX，它描述了一个 <h1> 和一个 <p> 标签的 UI 结构
    <div>
      <h1>Hello, {props.name}!</h1>
      <p>这是 Welcome 组件的内容。</p>
    </div>
  );
  // 3. 这个 JSX 最终会被组件返回
}

JSX 渲染机制

bundle.js 文件

JSX 本质上是 JavaScript 的一个扩展语法。浏览器或 Node.js 环境（在没有额外配置的情况下）并不能直接识别

这样的 JSX 标签。因此，它们必须被转换成普通的 JavaScript 代码。 如果是一个简单的在线demo，比如从cdn中直接引入babel，它会实时运行，并且把jsx转换为React.createElement调用。 在一个CICD流水线中，会通过webpack、vite等工具将所有jsx转换为浏览器可以识别的bundle.js 文件。这个bundle.js文件中已经不含任何 JSX 语法了。

运行时渲染&虚拟dom

转译后的代码进入浏览器后，React库本身会接管整个渲染过程。 React.createElement 调用不会直接生成DOM元素，而是返回一个轻量级的JavaScript对象，我们称之为React元素（React Element）。 主要是因为浏览器操作真实dom会有昂贵的开销，所以说React引入了虚拟dom的概念。 虚拟dom是一个轻量级的JavaScript对象，它描述了真实dom的结构。当组件的状态发生变化时，React会重新渲染组件，并且对比前后两次渲染的虚拟dom差异，只更新必要的部分到真实dom中。它存在的唯一目的就是为了提高性能，尤其是在需要频繁更新UI的应用中。

Components

react中组件的作用

react中组件的主要作用就是封装ui以及交互逻辑。和后端的microservices很像，组件的主要作用除了用就是为了复用 :)

一个简单的组件的例子：

    const Avatar = ({ imageUrl, name }) => {
      return (
        <div className="grandchild-component">
          <h5>📸 头像组件 (组件)</h5>
          <img
            src={imageUrl || `https://picsum.photos/seed/${name}/50/50.jpg`}
            alt={`${name}的头像`}
            style={{width: '50px', height: '50px', borderRadius: '50%'}}
          />
        </div>
      );
    };

一个页面往往由多个组件构成，这也是前端工程化组件化的思想之一

  const App = () => {       
    return (           
      <div>                    
        <BasicJSXDemo />      // 独立的功能组件
        <ComparisonDemo />    // 独立的对比演示组件 
        <DynamicDataDemo />   // 独立的数据展示组件                                 
        <InteractiveDemo />   // 独立的交互演示组件                                 
      div>                                                                       
    );                                                                           
  };

父子组件

父子组件顾名思义

来拿我们后端的内容做对比的话：

组件层级 ≈ 容器编排层级 (K8s: Pod → Service → Deployment)

Props传递 ≈ 配置传递 (ConfigMap → Pod)

事件回调 ≈ 事件通知 (Webhook/Alert Manager)

组件复用 ≈ 模板复用 (Terraform/Helm Chart)

父子组件的实际应用

父子组件关系就像现实中的父子关系一样，父组件负责管理和协调，子组件负责具体的业务逻辑实现。

React中，数据是单向流动的，从父组件流向子组件，这个设计模式被称为"单向数据流"。这样可以避免数据管理的混乱，让组件之间的依赖关系更加清晰。

// 父组件
const UserProfile = () => {
  const [userName, setUserName] = useState("张三");
  const [userAge, setUserAge] = useState(25);

  // 父组件定义的事件处理函数
  const handleAgeChange = (newAge) => {
    setUserAge(newAge);
  };

  return (
    <div className="parent-component">
      <h3>用户资料</h3>
      {/* 通过props将数据传递给子组件 */}
      <UserAvatar
        name={userName}
        age={userAge}
        onAgeChange={handleAgeChange}  // 将回调函数传递给子组件
      />
    </div>
  );
};

// 子组件
const UserAvatar = ({ name, age, onAgeChange }) => {
  const handleClick = () => {
    // 子组件调用父组件传递的回调函数
    onAgeChange(age + 1);
  };

  return (
    <div className="child-component">
      <h4>头像：{name}</h4>
      <p>年龄：{age}</p>
      <button onClick={handleClick}>增加年龄</button>
    </div>
  );
};

通过合理地使用父子组件的结构，可以构建出更加清晰、可维护的react project。

• system : 系统提示词用于统一设定当前会话下ai的行为，例如设定ai的行为、语气、风格或限制。用户不会显式观察到系统提示词，但是会影响到用户和ai的后续对话。

• user : 这是用户实际向ai提出的问题，这是对话的起点。

• assistant: 这是ai对于用户问题的回答，通常也会被添加到上下文中，供下一次对话进行参考，所以也属于prompt的范畴。

prompt 格式

标准格式：

<Instruction>

问答格式：

<Question>?

零样本提示 (Zero-shot Prompting):

依赖于模型在训练时学到的知识来给出回答。

例子: 什么是提示工程？ 优点: 简单、直接。 局限: 对于复杂的任务，模型可能表现不佳。

少样本提示 (Few-shot Prompting):

先提供一些任务的示例，然后让模型完成下一个类似的任务。

例子:

This is awesome! // Positive
This is bad! // Negative
Wow that movie was rad! // Positive
What a horrible show! //

前三个例子告诉模型，“awesome”和“rad”是正面情绪，“bad”是负面情绪。因此，模型可以推断出“horrible”也应被标记为负面情绪。 优点: 在许多情况下，能显著提高模型在特定任务上的表现。 局限: 需要花费更多精力来构建有效的示例，并且会占用更多的提示词（token）数量。

风险

在 Few-shot 场景下，如果正负样本比例失衡（如 8:2），模型倾向于预测占多数的标签。

prompt 构成

指令 Instruction: 希望模型执行的具体任务或操作 上下文 Context: 这是额外的外部信息或背景知识，可以引导模型给出更准确的回复。 输入信息 Input Data: 这是模型需要处理的具体数据或信息。 输出指示器 Output Indicator: 模型需要生成的输出类型或格式。

一个prompt并不需要完整的以上的四个部分，这根据具体的任务和模型的能力。

通用提示词设计

任务拆解

从简单开始：提示设计是一个反复试验的过程。建议从简单的提示开始，随着目标变得更明确，再逐步增加复杂性和上下文。 拆解任务：对于复杂的任务，可以将其分解成多个简单的子任务，以避免一开始就陷入复杂的提示设计。

指令

使用明确的指令: 采用明确的指令,或者说希望达到的目标来告诉模型需要它完成的事。 指令放置与格式: 建议将指令放在提示的开头，并使用清晰的分隔符（如###）将其与上下文或输入数据分开。

准确性

保持具体和详细：提供更多的描述，更多的详细细节. 提供例子：在提示中提供示例是获得所需格式输出的一种非常有效的方法。 关注上下文长度：在保持具体的同时，也要注意提示的长度限制，避免加入不必要的细节，确保所有细节都与手头的任务相关。

避免不精确的描述

直接而精确：要直接、具体，避免含糊不清的描述。 关注TODO：不要告诉模型不要做什么（比如“不要问我的兴趣相关内容”），明确告诉它要做什么（比如“推荐全球热门电影”）。这能更有效地指导模型的行为，减少产生意外结果的可能性。

提示词优化技巧

零样本提示词 (Zero-shot Prompting)

常用技巧

1. 明确任务目标: 告诉模型需要完成的任务，如分类、生成文本、翻译等。

2. 指定格式和输出要求: 如指定输出为JSON格式、限制输出长度等。

3. 角色扮演: 如“你是一个专业的翻译”、“你是一个专业的客服”等。

4. 逐步推理: 如“先理解用户的问题，然后根据理解生成回答”等。

5. 限制范围: 如限制模型的回答范围，避免生成不相关的内容。

少样本提示 (Few-shot Prompting)

常用技巧

1. 任务描述 + 示例结合: 先描述任务，然后提供一些示例，让模型根据示例完成任务。

2. 示例涵盖边界情况: 提供一些边界情况的示例，帮助模型理解任务的复杂性和边界条件。

3. 示例与目标风格一致: 确保示例与目标风格一致，避免生成与示例风格不同的内容,如我需要json形式的结果。

4. 用分隔符清晰分隔示例与新任务: 用分隔符（如###）清晰地区分示例和新任务，避免混淆。

COT (Chain of Thought)

COT通过让大模型显式生成“中间推理步骤”来提升其在多步推理任务上的准确性 主要变体

零样本COT

1. 添加COT提示: 在任务描述后添加“请一步一步思考”等提示，引导模型生成推理步骤。

2. 要求示例中包含推理步骤: 提供的示例中包含推理步骤，帮助模型理解任务的复杂性。

自动COT

1. 问题聚类（Question Clustering）：将数据集中的问题分成几个簇。

2. 示例采样（Demonstration Sampling）：从每个簇中选择一个代表性问题，并使用零样本思维链提示为它生成推理链。该过程会采用一些简单的启发式规则，比如问题长度或推理步骤的数量，以确保示例的简洁和准确。

示例： Question:

如果一个玻璃杯从10楼掉下去，会发生什么？逐步思考。

Answer:

Let's think step by step.
1. 玻璃是易碎材料。
2. 从10楼掉下会有很大速度和冲击力。
3. 玻璃承受不了这样的冲击。
4. 因此，它很可能会在落地时碎裂。
答案：它会碎掉。

Self-Consistency（自一致性）

常和 Chain-of-Thought（思维链提示）配合使用。 核心思想: 让模型多次独立推理同一个问题，然后选出现次数最多的答案作为最终结果。 技巧：

1. 生成多条推理路径，并且引入temperature

2. 收集多个候选答案

3. 投票选出最高频率的答案

思维树 (TOT)

思维树（ToT）是一种用于解决复杂任务的提示工程框架，它通过模拟人类的树状思维过程，显著提升了大型语言模型（LLM）的推理和解决问题的能力。

不同于传统的“思维链（Chain-of-Thought, CoT）”那种线性的、一步步的思考方式，ToT 鼓励 AI 进行多路径、多步骤的探索。它将问题分解成多个中间步骤（即“思想”），并在每个步骤中生成多个可能的选项（“分支”），形成一个树状的思考结构。

prompt 结构：分解任务→ 生成和评估 → 结合搜索算法

示例

你是一位经验丰富的旅行规划师。

你的任务是为客户规划一个从北京到上海的五天四夜旅行。


请你严格按照以下步骤进行思考和规划，最终给出详细的行程安排：


**第一步：任务分解**

首先，将这个复杂的旅行规划任务分解成几个主要的子任务或“思想”步骤。例如：

1.  **交通规划**：如何规划北京到上海的往返高铁，以及上海市内的交通方式？

2.  **住宿选择**：如何根据预算和兴趣，选择合适的住宿区域和酒店？

3.  **行程安排**：如何将客户的兴趣（历史文化、现代艺术、本地美食）合理地分配到五天行程中？

4.  **餐饮推荐**：如何为每一天安排符合客户喜好的美食体验？

5.  **预算考量**：如何在整个过程中平衡中等偏高的预算？


**第二步：多路径思考与探索**

针对每个子任务，请思考至少两种不同的方案或“思想路径”，并简要说明其优劣。


**示例（住宿规划）：**

* **方案A（思想路径A）**：选择住在外滩附近。

    * **优势**：交通便利，景点集中，夜景美观。

    * **劣势**：酒店价格较高，游客较多，可能会有些嘈杂。

* **方案B（思想路径B）**：选择住在法租界区域（如徐汇区）。

    * **优势**：环境安静优雅，靠近现代艺术区，美食选择多样。

    * **劣势**：离外滩等核心景点稍远，部分地区交通便利性不如外滩。


请像这样，为每个子任务思考至少两种不同的方案。


**第三步：评估和选择**

在思考完所有方案后，请你对它们进行综合评估，并从这些“思想路径”中选择一个你认为最佳的组合方案。请解释你为什么选择这个方案。


**第四步：生成最终行程**

根据你选择的最佳方案，生成一个详细、结构化的五天四夜行程。行程应包括：

* 每天的行程主题。

* 具体的景点和活动安排。

* 推荐的餐饮和交通方式。


请按照这个逻辑，一步步地为我完成这个旅行规划。

Generated Knowledge Prompting（生成知识提示）

是一种让大语言模型（LLM）先生成相关背景知识，再利用这些知识去回答问题的提示方法。

示例

step1 生成相关知识

Q: 请列出联合国安理会常任理事国的相关背景知识。
A:
1. 联合国安理会有5个常任理事国。
2. 他们拥有否决权。
3. 成员是根据二战胜利国确定的。
4. 成员包括：中国、法国、俄罗斯、英国、美国。

step2 利用相关知识回答问题

Q: 哪些国家是联合国安理会常任理事国？
A: 中国、法国、俄罗斯、英国、美国。

适用场景

1. 开放域问答（历史、科学、地理等）

2. 常识推理（需要多步背景知识）

3. 学术类问题（先回忆理论再应用）

4. 跨领域问题（整合多个知识片段）

Reference

[1]What is chain of thought (CoT) prompting? https://www.ibm.com/think/topics/chain-of-thoughts [2]Grok Prompts : https://github.com/xai-org/grok-prompts

[3]Tree of Thoughts Implement : https://github.com/princeton-nlp/tree-of-thought-llm

Ip工具可以查看当台主机的一些基本信息。

场景

• 查看基本信息:查看网络接口、mtu等。

• 查看docker虚拟网络相关信息。

Ping

ping 是 Linux 下一个非常常用且基础的网络工具，用于测试网络连接的可达性。

场景

• 测试网络连通性: 判断本机是否能够到达目标主机。分别ping lo地址、本机对外地址、gateway地址、公网地址，可以一步一步的进行问题的排查。

• 测量网络性能: 查看RTT、丢包等信息，即数据包从发送到接收到回复所花费的时间。

• 域名解析验证: 当使用域名作为目标时，ping 命令会先解析域名为 IP 地址，可以间接验证 DNS 解析是否正常。

• 压测:ping 可以使用-f 进行Flood ping，可以配合-s(设置package size)来进行简单的对目标主机的压测。

Dig

Dig是 Linux 命令行下用于查询 DNS信息的强大工具。dig 允许用户直接与 DNS 服务器交互，查询各种 DNS 记录，并显示从服务器返回的详细信息。

场景

• 检查域名是否能够被解析:这是dig最基本的功能，通过查询 A、AAAA、CNAME 等记录，可以确认域名是否在 DNS 系统中存在并指向正确的 IP 地址或别名。

• 查看DNS解析信息:包括DNS解析时长、最大超时时间等。

• 检查指定的 DNS 服务器是否正常工作:可以通过指定不同的 DNS 服务器进行查询，判断特定的 DNS 服务器是否响应查询或返回正确的结果。

• 检查DNS 记录是否正确传播:在 DNS 记录更新后，可以使用 dig 查询不同的 DNS 服务器，检查新的记录是否已经在全球范围内生效。

• 查看DNS解析过程:DNS 缓存问题可能导致用户无法访问某些网站。使用 dig 的 +trace 选项可以帮助跟踪 DNS 解析过程，查找可能的缓存问题。

• 查看DNS策略是否生效:dig baidu.com的时候可以发现有两个ip地址，可以通过dig来查看DNS 配置策略状态。

nmap

namp是一个网络扫描工具，主要用于发现网络上的主机、探测开放的端口、识别运行的服务以及操作系统类型等。

场景

• 端口扫描:扫描主机的端口，查看是否开放，可以指定全连接或半连接扫描。

• 网段范围的主机探测:本质上是ping命令，但是可以指定范围，通过ip ranges来进行主机的存活探测。

• Flood Testing:基本原理同ping。

• 暴力破解测试:不细说。

• 检测远程主机OS信息(估测)：原理是根据一些网络协议信息进行os版本的推测。

netstat & ss

netstat

netstat 用于显示 Linux 系统上的网络连接、路由表、接口统计信息、伪装连接、多播成员关系等。它提供了一个实时的网络活动快照，对于监控网络状态、诊断网络问题以及了解系统上的网络配置非常有用。

ss

ss 是另一个用于显示 Linux 系统上的套接字统计信息的命令行工具。它被认为是 netstat 的现代替代品，能够显示更多的 TCP 和套接字信息。两个工具在功能上有一些重叠。

场景

• 查看所有活动的网络连接:显示所有 TCP 和 UDP 连接，以及正在监听的端口;查找占用特定端口的服务。

• 查看套接字相关信息:包括 TCP 窗口大小、拥塞控制算法等。

traceroute

traceroute 是一个网络诊断工具，用于跟踪数据包从计算机到目标主机所经过的路由（路径）。

场景

• 诊断网络连接问题:无法访问某个网站或服务时，traceroute 可以帮助确定问题出在本地网络、ISP 网络还是目标服务器的网络路径上。

• 识别网络瓶颈:观察每个跃点的延迟，可以找到网络中可能导致速度缓慢的瓶颈节点。

speedtest-cli

一个简单的网络测试工具，可以快速获取最近的网络测试节点并且测试网速。

Vnstat

Vnstat 是一个轻量级的命令行网络流量监控工具。它在后台运行，记录网络接口的接收和发送数据量，并提供各种报告，记录网络的历史使用情况。

场景

• 网卡流量监控:基于proc，针对网卡的流量监控，可以分时进行查询，还可以导出图片进行分析。

nethogs

类似于 top 命令，但专注于按进程实时显示网络带宽使用情况。它可以让你看到哪个进程正在消耗最多的上传和下载带宽。缺点就是不能够查询一些内核级别的进程的通信信息。

场景

• 网卡实时流量监控:针对网卡的实时流量监控，可以达到进程级别。

iftop

实时监控网络接口的带宽使用情况，但它按网络连接（主机对）显示流量，并尝试解析主机名。可以查看哪些主机之间正在进行大量的网络通信。

• 实时流量监控:针对主机级别的实时流量监控，和nethogs有点类似。

wireshark

一个强大的网络分析可视化工具。

• 详细分析网络协议: 可以深入分析 TCP/IP 协议栈的各个层次，查看每个数据包的详细头部信息和数据内容。

• 性能分析: 分析网络延迟、丢包、重传等性能指标，帮助优化网络性能。

tcpdump

一个命令行抓包工具。它可以捕获指定接口上的网络数据包，并将数据包信息输出到终端或保存到文件中。

• 作为数据源: tcpdump 的一个常用的用处就是将dump下的数据导入到wireshark中进行详细分析。tcpdump可以快速抓取数据包。

• 数据分析:可以进行一些简单的数据分析，当然可视化方面还是wireshark比较好。

bcc

BCC 是一个围绕 eBPF 构建的强大工具包，里面有很多关于网络抓包的工具。

没有接触过，皓哥这里有详细的介绍：https://coolshell.cn/articles/22320.html

Reference

• Nmap:https://www.recordedfuture.com/threat-intelligence-101/tools-and-techniques/nmap-command

• traceroute:https://support.microsoft.com/en-us/topic/how-to-use-tracert-to-troubleshoot-tcp-ip-problems-in-windows-e643d72b-2f4f-cdd6-09a0-fd2989c7ca8e

• tcpdump:https://www.modb.pro/db/634018

• bcc:https://www.cnblogs.com/charlieroro/p/13265252.html#bcc%E5%8F%AF%E8%A7%82%E6%B5%8B%E6%80%A7

• Vnstat:https://cgking.gitbook.io/linux/linux/vnstat-tong-ji-fu-wu-qi-wang-ka-liu-liang

硬件资源

目前登录使用的是机房内的一台机器（192.168.40.50） 连接已经配好的虚拟机地址 虚拟机硬件资源如下： os版本：Ubuntu 24.04 LTS (GNU/Linux 6.8.0-31-generic x86_64) k8s版本：Kubernetes v1.30.6

将会使用kubeadm进行安装

安装前要求检测

• 一台兼容的 Linux 主机。Kubernetes 项目为基于 Debian 和 Red Hat 的 Linux 发行版以及一些不提供包管理器的发行版提供通用的指令。

• 每台机器 2 GB 或更多的 RAM（如果少于这个数字将会影响你应用的运行内存）。

• 控制平面机器需要 CPU 2 核心或更多。

• 集群中的所有机器的网络彼此均能相互连接（公网和内网都可以）。

• 节点之中不可以有重复的主机名、MAC 地址或 product_uuid。请参见这里了解更多详细信息。

• 开启机器上的某些端口。请参见这里了解更多详细信息。

• 交换分区的配置。kubelet 的默认行为是在节点上检测到交换内存时无法启动。更多细节参阅交换内存管理。

• 如果 kubelet 未被正确配置使用交换分区，则你必须禁用交换分区。例如，sudo swapoff -a 将暂时禁用交换分区。要使此更改在重启后保持不变，请确保在如 /etc/fstab、systemd.swap 等配置文件中禁用交换分区，具体取决于你的系统如何配置。

Install Steps

配置必要插件以及网络参数

k8s 需要通过ipv4来进行不同pod之间的通信

# 安装两个必要内核插件，overlay 和 br_netfilter
cat <<EOF | sudo tee /etc/modules-load.d/k8s.conf
overlay
br_netfilter
EOF
​
# 动态加载这两个模块
sudo modprobe overlay
sudo modprobe br_netfilter
​
# 设置所需的 sysctl 参数，参数在重新启动后保持不变
cat <<EOF | sudo tee /etc/sysctl.d/k8s.conf
net.bridge.bridge-nf-call-iptables  = 1
net.bridge.bridge-nf-call-ip6tables = 1
net.ipv4.ip_forward                 = 1
EOF
​
# 应用 sysctl 参数而不重新启动
sudo sysctl --system
​
# 使用以下命令验证 net.ipv4.ip_forward 是否设置为 1
sudo sysctl net.ipv4.ip_forward

下载containerd service 选择 container runtime

这里选择containerd而不是docker（kubernetes新版本已将默认容器编排切换为containerd）

## 1、containerd
# 下载包
wget https://github.com/containerd/containerd/releases/download/v1.7.22/containerd-1.7.22-linux-amd64.tar.gz
​
# 将下载的包解压到/usr/local下
tar Cxzvf /usr/local containerd-1.7.22-linux-amd64.tar.gz

# 下载服务启动文件
wget -O /etc/systemd/system/containerd.service https://raw.githubusercontent.com/containerd/containerd/main/containerd.service

# 文件内容如下，下载不下来直接复制
cat /etc/systemd/system/containerd.service
[Unit]
Description=containerd container runtime
Documentation=https://containerd.io
After=network.target local-fs.target
[Service]
ExecStartPre=-/sbin/modprobe overlay
ExecStart=/usr/local/bin/containerd
Type=notify
Delegate=yes
KillMode=process
Restart=always
RestartSec=5
# Having non-zero Limit*s causes performance problems due to accounting overhead
# in the kernel. We recommend using cgroups to do container-local accounting.
LimitNPROC=infinity
LimitCORE=infinity
# Comment TasksMax if your systemd version does not supports it.
# Only systemd 226 and above support this version.
TasksMax=infinity
OOMScoreAdjust=-999
[Install]
WantedBy=multi-user.target
# 启动containerd
systemctl daemon-reload
systemctl enable --now containerd
​
## 2、Installing runc
wget https://github.com/opencontainers/runc/releases/download/v1.2.0-rc.3/runc.amd64
TODO:worker1
sudo install -m 755 runc.amd64 /usr/local/sbin/runc

containerd也可以通过apt来下载：

`sudo apt-get install containerd.io`

修改containerd配置文件 (!important)

containerd 相关配置

# 创建containerd目录
sudo mkdir /etc/containerd
​
# 恢复默认配置文件
sudo containerd config default | sudo tee /etc/containerd/config.toml > /dev/null

​
# 切换为国内源
sed -i 's/registry.k8s.io/registry.aliyuncs.com\/google_containers/' /etc/containerd/config.toml
​
# 修改SystemCgroup为true
[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options]
    SystemdCgroup = true
​
# 重启服务
sudo systemctl daemon-reload
sudo systemctl restart containerd

设置cgroup

sudo sed -i 's/SystemdCgroup = true/SystemdCgroup = false/' /etc/containerd/config.toml

为什么还需要在config中设置镜像源

使用kubeadm init 并指定image-repository 后仍需要在 containerd 的 config.toml 文件中指定镜像源的原因，主要是由于这两个配置的生命周期不同：

• kubeadm init 配置镜像源仅用于初始化过程加速必要的相关组件：如 kube-apiserver、kube-controller-manager、kube-scheduler 等）

• containerd 自身的配置不受 kubeadm 影响 。Kubernetes 组件启动后，由 containerd 负责持续管理容器和镜像的生命周期。当 containerd 需要重新拉取镜像（例如镜像更新或节点重启后），它将遵循自己的 config.toml 配置文件，而不是 kubeadm 的参数。未在 containerd 中配置镜像源时，它会默认访问官方的 k8s.gcr.io 源，而这一源在中国大陆访问通常较慢或受限。

设置完成后保存、重新加载containerd配置、重启containerd服务、验证配置是否生效

sudo systemctl daemon-reload
sudo systemctl restart containerd
sudo systemctl status containerd

下载kubeadm以及相关组件

sudo apt-get update
# apt-transport-https may be a dummy package; if so, you can skip that package
sudo apt-get install -y apt-transport-https ca-certificates curl gpg

# If the directory `/etc/apt/keyrings` does not exist, it should be created before the curl command, read the note below.
# sudo mkdir -p -m 755 /etc/apt/keyrings
curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.30/deb/Release.key | sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg

# This overwrites any existing configuration in /etc/apt/sources.list.d/kubernetes.list
echo 'deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.30/deb/ /' | sudo tee /etc/apt/sources.list.d/kubernetes.list

sudo apt-get update

sudo apt-get install -y kubelet kubeadm kubectl

sudo apt-mark hold kubelet kubeadm kubectl

初始化master节点

命令行部署

国内如果不指定image源，在拉取sandbox的时候会出现异常 sudo kubeadm init --image-repository registry.aliyuncs.com/google_containers --pod-network-cidr=10.128.0.0/16

yaml部署（推荐）

首先执行kubeadm config print init-defaults 输出kubeadm默认配置

之后需要在kubeadm-config.yaml这个文件中修改以下几个地方：

1. hostname 修改name为自己的主机名称，上下文： nodeRegistration: criSocket: unix:///run/containerd/containerd.sock imagePullPolicy: IfNotPresent imagePullSerial: true name: k8s-master taints: null

2. podSubnet 追加podSubnet podSubnet: 10.244.0.0/16 上下文： networking: dnsDomain: cluster.local serviceSubnet: 10.96.0.0/12 podSubnet: 10.244.0.0/16

3. KubeletConfiguration 文件最后追加 KubeletConfiguration apiVersion: kubelet.config.k8s.io/v1beta1 kind: KubeletConfiguration cgroupDriver: systemd

之后，可以根据yaml文件初始化master节点：kubeadm init --config=kubeadm-config.yaml

master初始化完成

初始化完成后显示示例：

Your Kubernetes control-plane has initialized successfully!

To start using your cluster, you need to run the following as a regular user:

  mkdir -p $HOME/.kube
  sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
  sudo chown $(id -u):$(id -g) $HOME/.kube/config

Alternatively, if you are the root user, you can run:

export KUBECONFIG=/etc/kubernetes/admin.conf

You should now deploy a pod network to the cluster.
Run "kubectl apply -f [podnetwork].yaml" with one of the options listed at:
  https://kubernetes.io/docs/concepts/cluster-administration/addons/

Then you can join any number of worker nodes by running the following on each as root:

kubeadm join 192.168.40.140:6443 --token wssf4y.fikow8fj6w1f2oar \
        --discovery-token-ca-cert-hash sha256:f942ac3be4f63eff7ff780145bf2937bd10656e7a361daf2da002fe2ece6a76e

注意：export KUBECONFIG=$HOME/.kube/config 这里需要设置环境变量，当使用普通用户非root的时候，如果没有上述操作，可能会默认读取/etc下的config文件

初始化flannel网络插件

下载配置文件

wget https://raw.githubusercontent.com/coreos/flannel/a70459be0084506e4ec919aa1c114638878db11b/Documentation/kube-flannel.yml

如果连接失败可参考文件：

apiVersion: v1
kind: Namespace
metadata:
  labels:
    k8s-app: flannel
    pod-security.kubernetes.io/enforce: privileged
  name: kube-flannel
---
apiVersion: v1
kind: ServiceAccount
metadata:
  labels:
    k8s-app: flannel
  name: flannel
  namespace: kube-flannel
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  labels:
    k8s-app: flannel
  name: flannel
rules:
- apiGroups:
  - ""
  resources:
  - pods
  verbs:
  - get
- apiGroups:
  - ""
  resources:
  - nodes
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - ""
  resources:
  - nodes/status
  verbs:
  - patch
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  labels:
    k8s-app: flannel
  name: flannel
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: flannel
subjects:
- kind: ServiceAccount
  name: flannel
  namespace: kube-flannel
---
apiVersion: v1
data:
  cni-conf.json: |
    {
      "name": "cbr0",
      "cniVersion": "0.3.1",
      "plugins": [
        {
          "type": "flannel",
          "delegate": {
            "hairpinMode": true,
            "isDefaultGateway": true
          }
        },
        {
          "type": "portmap",
          "capabilities": {
            "portMappings": true
          }
        }
      ]
    }
  net-conf.json: |
    {
      "Network": "10.244.0.0/16",
      "EnableNFTables": false,
      "Backend": {
        "Type": "vxlan"
      }
    }
kind: ConfigMap
metadata:
  labels:
    app: flannel
    k8s-app: flannel
    tier: node
  name: kube-flannel-cfg
  namespace: kube-flannel
---
apiVersion: apps/v1
kind: DaemonSet
metadata:
  labels:
    app: flannel
    k8s-app: flannel
    tier: node
  name: kube-flannel-ds
  namespace: kube-flannel
spec:
  selector:
    matchLabels:
      app: flannel
      k8s-app: flannel
  template:
    metadata:
      labels:
        app: flannel
        k8s-app: flannel
        tier: node
    spec:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: kubernetes.io/os
                operator: In
                values:
                - linux
      containers:
      - args:
        - --ip-masq
        - --kube-subnet-mgr
        command:
        - /opt/bin/flanneld
        env:
        - name: POD_NAME
          valueFrom:
            fieldRef:
              fieldPath: metadata.name
        - name: POD_NAMESPACE
          valueFrom:
            fieldRef:
              fieldPath: metadata.namespace
        - name: EVENT_QUEUE_DEPTH
          value: "5000"
        image: docker.io/flannel/flannel:v0.26.0
        name: kube-flannel
        resources:
          requests:
            cpu: 100m
            memory: 50Mi
        securityContext:
          capabilities:
            add:
            - NET_ADMIN
            - NET_RAW
          privileged: false
        volumeMounts:
        - mountPath: /run/flannel
          name: run
        - mountPath: /etc/kube-flannel/
          name: flannel-cfg
        - mountPath: /run/xtables.lock
          name: xtables-lock
      hostNetwork: true
      initContainers:
      - args:
        - -f
        - /flannel
        - /opt/cni/bin/flannel
        command:
        - cp
        image: docker.io/flannel/flannel-cni-plugin:v1.5.1-flannel2
        name: install-cni-plugin
        volumeMounts:
        - mountPath: /opt/cni/bin
          name: cni-plugin
      - args:
        - -f
        - /etc/kube-flannel/cni-conf.json
        - /etc/cni/net.d/10-flannel.conflist
        command:
        - cp
        image: docker.io/flannel/flannel:v0.26.0
        name: install-cni
        volumeMounts:
        - mountPath: /etc/cni/net.d
          name: cni
        - mountPath: /etc/kube-flannel/
          name: flannel-cfg
      priorityClassName: system-node-critical
      serviceAccountName: flannel
      tolerations:
      - effect: NoSchedule
        operator: Exists
      volumes:
      - hostPath:
          path: /run/flannel
        name: run
      - hostPath:
          path: /opt/cni/bin
        name: cni-plugin
      - hostPath:
          path: /etc/cni/net.d
        name: cni
      - configMap:
          name: kube-flannel-cfg
        name: flannel-cfg
      - hostPath:
          path: /run/xtables.lock
          type: FileOrCreate
        name: xtables-lock

设置镜像源

[plugins."io.containerd.grpc.v1.cri".registry.mirrors] 
[plugins."io.containerd.grpc.v1.cri".registry.mirrors."[docker.io](http://docker.io)"] 
endpoint = ["[https://docker.1panel.live(https://docker.1panel.live)","[https://docker.agsv.top](https://docker.agsv.top)","[https://docker.agsvpt.work](https://docker.agsvpt.work)"] 
[plugins."io.containerd.grpc.v1.cri".registry.mirrors."[k8s.gcr.io](http://k8s.gcr.io)"]
endpoint = ["[registry.aliyuncs.com/google_containers](http://registry.aliyuncs.com/google_containers)"]

目前境内一些好用的镜像源：

https://docker.1panel.live ✅网友自建
地址 https://docker.agsv.top  ✅网友自建
备用 https://docker.agsvpt.work  ✅网友自建
地址①:https://dockerpull.com ✅网友自建
地址②:https://dockerproxy.cn ✅网友自建

配置完成后进行应用 kubectl apply -f kube-flannel.yml

kubectl get pods --all-namespaces 可以检查看dns和flannel相关pod有没有正常启动，

初始化工作节点

工作节点前置任务完成后（安装containerd&安装kubeadm）

kubeadm join <master-ip>:<port> --token abcdef.0123456789abcdef \
    --discovery-token-ca-cert-hash sha256:<discovery-token-ca-cert-hash>

主节点的 IP 和端口：

主节点的 IP 地址可以通过在主节点上运行 ip addr show 或 ifconfig 命令来获取。

端口通常是 6443，这是 Kubernetes API 服务器默认使用的端口。

加入令牌（Token）：

当你使用 kubeadm init 初始化主节点时，命令会输出一个加入令牌。这个令牌用于工作节点加入集群时的身份验证。

如果你丢失了这个令牌，可以通过以下命令在主节点上重新获取：

kubeadm token list

这将列出所有可用的令牌及其过期时间。你可以选择一个合适的令牌用于 kubeadm join 命令。

发现令牌的 CA 证书哈希：

发现令牌的 CA 证书哈希是用于验证集群信息的证书的哈希值。这个哈希值也可以在主节点上通过以下命令获取：

kubeadm token create --print-join-command

这个命令会输出一个完整的 kubeadm join 命令，包括所需的 CA 证书哈希。你可以直接复制这个命令中的哈希值。

# 可以在master节点生成新的加入令牌
kubeadm token create --print-join-command

初始化完成后可以跳到主节点，kubectl get nodes 查看是否加入成功

工作节点不需要进行flannel配置，工作节点加入集群后会自动进行同步

初始化节点失败后回退方法

重置 Kubernetes 节点，使其恢复到初始化前的状态 sudo kubeadm reset -f

手动清除配置文件： sudo rm -rf /etc/kubernetes /var/lib/etcd /var/lib/kubelet /var/lib/dockershim /var/run/kubernetes

查看是否有端口占用，如果有kill一下 sudo lsof -i :10250

Discover the Best AI Tools and Services - Your Ultimate AI Directory at AIPURE

设计相关

https://slea.ai logo生成

stable diffusion 图片处理

AI 搜索：

perplexity.ai

felo.ai/

kimi

翻译：

Immersive Translate - Translate Web & PDF 沉浸式翻译，强烈推荐

DeepL目前体感翻译效果最好的，好处就是可以不局限于web端

podwise.ai

LLM API：

siliconflow.com

openrouter.ai

OpenRouter.ai

Chatbot：

lobechat.com

poe.com

monica.im

chatgpt

claude

AI IDE：

www.cursor.com

v0

辅助阅读：

notebooklm.google.com

AI 应用开发：

dify.ai

coze

语音生成：

elevenlabs.io

fish.audio

https://github.com/SWivid/F5-TTS

一些乱七八糟的

suno prompt 生成

suno

示例图生成

PPT:

https://gamma.app/signup?r=mz3b22zprlhdp5t

Delve 是一个 Go 语言的调试器，由 Sam Boyer 和 Brian Powers 开发，并且是 Go 社区广泛使用的调试工具之一。它提供了一套丰富的调试功能，专门针对 Go 语言的特性设计，使得开发者可以更加高效地进行程序调试。默认在bin目录下。

DAP（Debug Adapter Protocol）是一个标准化的 JSON-RPC 协议，用于定义调试器和开发环境之间的通信，支持跨语言和跨平台的调试功能。 https://microsoft.github.io/debug-adapter-protocol/overview

1. Visual Studio Code 配置

当在Visual Studio Code中安装go官方tools后，默认会使用dlv作为debugger，dap作为protocol进行本机调试

Visual Studio Code中根据launch.json中的配置信息进行debug 一个常见的配置信息如下

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Launch Package",
            "type": "go",
            "request": "launch",
            "mode": "auto",
            "program": "cmd/xxx/."
        }
    ]
}

• version: Visual Studio Code 配置文件的具体版本

• configurations：一个数组，可以通过json形式添加不同的config

• type: 指定了调试会话使用的调试器类型。在这里，"go" 表示使用 Go 语言的调试器。

• request: 定义了调试会话的请求类型。"launch" 表示启动一个新的程序进行调试。

• mode: "auto",：指定了调试模式。"auto" 模式意味着调试器将自动选择是直接启动程序还是附加到已运行的程序上。

• "program": "cmd/healthcare/."：定义了要启动和调试的程序的路径。这里 "cmd/healthcare/." 指的是项目中 cmd/healthcare 目录下的主程序入口文件。 详细配置字段以及流程： https://code.visualstudio.com/docs/editor/debugging

2.注意事项

go的包管理机制： https://go.dev/blog/using-go-modules

Q: go run main.go的时候，go编译器会尝试自动编译和链接引入的import包，当使用wire时，wire会生成wire_gen.go ，如果在kratos框架中就会自动生成在 main包下，且wireApp为包可见级别。此时go run main.go会提示wireApp is undefined , 可能是go build 的时候，只build main.go 并没有寻找到wire生成的gen.go ， main.go 中也没有显式的import(存疑)，导致buid的过程中没有链接到wireApp S: 解决方法：build整个cmd项目目录下main package的所有go文件 go build .

同理，在Visual Studio Code配置 "program": "cmd/xxx/." 的时候，需要指定main package 所在的平级目录文件夹。不可cmd/xxx/main.go

这两天在小宇宙发现Ep 23. 个人知识管理体系系列 - 输入篇 - 捕蛇者说 (pythonhunter.org)有关知识管理体系以及如何学习的系列podcast。深有感触，这两年经历了一系列事情，我对学习这件事有了很多想法，遂整理一篇blog沉淀一下。

1. 一些影响

考研/高强度的网上冲浪/实习。 关于考研和实习这两件事我感觉可以挖个坑后面详细讲讲。先把重心放在知识管理这个主题上。

关于考研

虽说考研最后没有参加考试，但是对我影响还是很大的，有以下几个方面：能够真正沉下心输入&内化&输出（一个完整的知识增长workflow流程）、计算机基础&数学基础补全、对应试教育的厌恶++；

关于网上冲浪

起因是因为去年十月份在放弃考研之后。一段时间高强度网上冲浪，在知乎上刷到Thoughts Memo (zhihu.com)这位博主的文章，花了两天的时间通读了一遍。很有感触，并且开始使用anki对于碎片化记忆点进行review。

开始玩hoi4，和一些不太符合主流价值观的mod，有将近一个多月的时间是这样度过的：白天hoi4，夜晚刷Wikipedia相关历史词条。

开始接触podcast，最早听的就是beyondcode，印象比较深的还是郭宇的那集，应该正好是那段时间播出的。

开始接触stand-up comedy，特指台湾(STR network)。博恩夜夜秀 -> 贺龙夜夜秀。个人：博恩、贺龙、龙龙、微笑丹尼。

这段时间对世界观塑造的影响比较大，对于生活、技术的理解、世界观、价值观的改变等等。扩展了信息源，有意识的开始使用英语摄取信息。开始学习德文。

关于实习

"you don't know what you don't know"

三月份实习总共拿了两个offer， 一个是深圳的一家不知名小游戏公司的go游戏sdk开发+运维 还有一个就是美团的软服；因为成都比较熟悉加上有学长在，而且毕竟是大厂，还是选择了美团。 对于知识管理方面主要是一些流程规范（短短两个字其实内涵很多，如何沉淀文档、如何写一份技术设计、如何写一份需求复盘、如何阅读prd都是值得参考的。这个之后我会放在[[美团经历]]中详细讲一下）以及一些resource。

2. 现状和Why

按照流转状态分类的话和podcast标题一致，大致分为三个过程：输入/内化/输出。

输入

输入是很重要的一环，garbage in garbage out 。我一直坚信一个观点， 输入的质量决定输出的质量。

本文我主要想谈论的是一些<非人相关的input>。其实能够有一个很好的社交圈，如果能够有机会one one ，是更好的选择。

目前我的输入渠道：官方文档(如果有)=书>博客>podcast>others。

官方文档永远是最权威的，且最具时效性，如版本更迭，大部分技术项目也都会有archive。书的话时效性就相对较低了，但整体连贯，逻辑结构强，一些细节会更加丰满且通俗易懂。博客的话质量就层次不齐了（比如我这个应该就不太行😂）。需要挑选一些共识度较高的食用。podcast同理，但因为缺少一定的视觉输入，还是差了点意思，一般也就通勤听听，大多是一些比较轻松的话题。

当然，屏蔽一些内容农场也是很有必要的前置任务。可以试一下ublocklist.“作环保的程序员，从不用百度开始” | 酷 壳 - CoolShell

内化

内化这个词在我的理解就是对input的消化和吸收。 内化的知识我觉得可以分为两种类型：逻辑型 & 记忆型。其实也就是知识论中的先验和后验。两种不同的类型有不同解决方式。逻辑型的类似什么TCP需要三次握手？四次挥手？Why desgin？这种知识我觉得可以通过 梳理逻辑关系来加深理解。后验的一些东西类似单词拼写、一些command，就不如直接交给anki了。

输出

输出有很多方式：讲演、思维导图、文档、思维导图... 输出算是我的强项了，但是一些有逻辑性的文档输出还是差了一点。我一直觉得我的思维比较发散，需要在逻辑梳理这方面多加强一些。

3. 目前常用的一些知识管理工具

Vscode + Vim插件 + Markdown 文本编辑器

Draw.io 绘图

Blog 目前是Typecho，有自己重新build的一个想法

Obsidian + Notion 笔记管理

Google Calendar 日程/Todo

Feedly RSS订阅

Anki 碎片化记忆

uBlackulist 屏蔽内容农场

  2024年六月是一段特别的日子。离职、毕业、旅行，各种花花绿绿的计划排满了整个google calendar。在离职前后就有过想重新搭一个博客的想法，但因为各种乱七八糟的事情完成日期一直拖到了26号这样，虽说过程不是很难，但也踩了不少小坑。第一篇博客就用来记录一下这个新bolg plateform搭建时的心路历程吧。

1.需求分析

  虽说大学时正经的帖子没写过多少，但是搭建博客还是花了不少的功夫。wordpress、hexo、jekyll都上线把玩过。wordpress有点过于沉重了，不仅访问速度慢，并且似乎一直存在一些插件安全问题。

  hexo和jekyll这种静态的安全问题不太用考虑。大一的时候玩过hexo，那个时候还没有类似github pages这种东西，直接挂载服务器，配置一些新组件和修改新增博客的时候有点坐牢，之后也就不了了之了，记录还是多用语雀和notion。

  jekyll，大约是在大三的时候接触的，通过github action中的自动化脚本可以轻松的在push以后自动推送，配合vscode中vim用的也还是挺爽的，但是总觉得静态博客没有管理后台还是差了点意思。并且因为GFW&&国内政策的问题，搭建小站需要各种流程，很是繁琐。

  根据上面的一些问题大概总结了这次搭建博客平台的一些需求点：

• 无需审核备案

• 流量安全

• 动态博客

2.资源整理

• 阿里云 上海 2gb ram 2 core ecs

• 阿里云 ekreke.xyz

• RackNerd Los Angeles 2gb ram 1 core VPS （新购入）

• cloudflare account (cloudflare 下简称cf)

• 人生中宝贵的3天

3.解决方案

无需审核备案需求方案

  对于备案这种墙内问题，以前尝试通过端口转发+nginx反代隐藏真实80端口，但是不仅需要一台空闲的机器，而且还会有后续的审核风险，这次干脆一了百了选择墙外服务器来解决。(端口转发+反代规避备案教程类似：https://www.xiaoweigod.com/network/1566.html)

流量安全需求方案

  流量安全主要针对的就是一些恶意流量攻击的问题。这个部分主要就外包给cf来做了，还是免费。cf的提供的功能非常全面，可以进行托管省时省力省心，唯一的缺点就是大陆GFW会对某些托管的ip进行封锁，拨测ping值感人。关于更多cf相关内容可以详见此podcast(https://www.xiaoyuzhoufm.com/episode/6645a7b9fbc01d7f367e6da3)

动态博客方案

  这部分无非就是套架子，都大同小异。以前自己也写过类似的博客系统小玩具，这次为了方便偷个懒还是直接套用了。google了一下 top 10 blog framework , 比较中意的就是ghost。不过实装过后会发现在大陆访问的时候会加载一些被墙的静态资源。并且会出现莫名其妙的http&https混合内容问题。看了一下论坛issues，也并没有解决，遂弃。到达南京后在lvan chen的力推下整上了typecho。

4.搭建步骤

1. 解析域名：因为以前的域名是阿里云购买，担心直接指海外vps不安全遂放在cf上进行托管。cf的托管方式也很有意思，不是直接进行域名转移，而是在阿里云上更改解析权威域名的dns服务器域名。之后在dns板块进行配置解析。

2. 服务部署：此处可参考typecho官方文档。mysql直接docker run一下即可。

3. ssl证书/nginx配置：证书可以手动进行配置，参考(http://chenk.vip/index.php/archives/133/) 也可以使用certbot（https://certbot.eff.org/） nginx配置一下服务的端口即可。

5.Hello World!!!

  在查ghost的issues的时候偶然看到这么一条评论：其实技术选型并不重要，博客最终要的还是内容。自认为还是一个想法挺多的人，但是说来惭愧大学四年并没有积累太多的文字。文字积累的最多的还是在公司内网的平台上，大多也是一些简短的总结和技术设计，随着离职也不复存在了。随着年龄的增长，越来越觉得记录是一个很有必要的事情。   粗浅的分析一下，人对于一件事的观点变更大概有以下三种模式：

1. accept A

2. A -> B

3. A -> B.. -> A

  我并不觉得任何单一的观点具有可记录的意义。就像陈皓老师在一期podcast中说的一样，单个的点不是知识，串联起来的过程才是知识、经验，才是我们真正需要关注的东西。For example， 如果分别在10 ， 18 ， 22岁的时候分别问我大陆有没有言论自由，我觉得我会分别回答有、没有、有。一个类似ABA Problem的过程 :)（https://en.wikipedia.org/wiki/ABA_problem）实际上到底有或没有并没有什么可以记录的价值，但如果细究如上每一段时间社会的变革，个人的经历历程，就能找到一个状态变更的why。这是常常被人所忽视的，也是我觉得最为值得和必要记录的--experience。   有点扯远了。。anyway , 希望从现在开始能以每周一更的频率更新下去，记录一些有趣的事情。

（全文完）