rsync = 文件同步工具（不是单纯拷贝）

核心特点：

• 增量同步：只传输变化的数据块
• 可断点续传
• 支持本地 / 远程
• 支持权限、时间戳、ACL、xattr
• 可 over SSH（默认）

执行流程（简化）：

1. 建立连接（本地 / SSH / daemon）
2. 扫描源与目标文件列表
3. 比较元数据 / 校验
4. 传输差异数据
5. 校验完成
6. 正常退出

二、基本语法结构

rsync [OPTION...] SRC [SRC...] DEST

最常见的三种形式

1️⃣ 本地 → 本地

rsync -av /src/ /dst/

2️⃣ 本地 → 远程（SSH）

rsync -av /src/ user@host:/dst/

3️⃣ 远程 → 本地

rsync -av user@host:/src/ /dst/

三、最核心的一组参数（必须掌握）

1️⃣ -a（archive，生产必用）

-a  等价于：-rlptgoD

包含：

👉 生产同步几乎必带 -a

2️⃣ -v（verbose）

-v

• 显示执行过程
• 调试时非常重要

3️⃣ --progress / --info=progress2

--progress         # 单文件进度
--info=progress2   # 全局进度（推荐）

👉 大文件 / 镜像同步强烈推荐

四、文件传输控制参数（重点）

1️⃣ --partial（断点续传）

--partial

• 网络中断保留未完成文件
• 下次可继续

2️⃣ --append / --append-verify

--append
--append-verify   # 推荐

• 适合大文件（qcow2 / raw）
• 从已写入部分继续
• --append-verify 会校验安全性

3️⃣ --inplace（谨慎）

--inplace

• 直接写目标文件
• 不生成临时文件
• 文件损坏风险高

👉 仅在明确知道后果时使用

五、删除与镜像同步（非常危险的一类）

1️⃣ --delete

--delete

• 删除目标端多余文件
• 用于“镜像同步”

⚠️ 误用可能导致严重数据丢失

2️⃣ --delete-delay（更安全）

--delete-delay

• 同步完成后再删除

六、过滤与排除规则

1️⃣ 排除文件

--exclude="*.log"
--exclude="/tmp/"

2️⃣ 使用规则文件（推荐）

--exclude-from=exclude.txt

exclude.txt 示例：

*.log
tmp/
.cache/

3️⃣ 包含规则

--include="*.conf"
--exclude="*"

七、性能与网络控制

1️⃣ 限速

--bwlimit=10240   # KB/s

2️⃣ 压缩

-z

• 低带宽适合
• 内网高速一般不需要

3️⃣ 并发（rsync 本身不支持）

• rsync 是单进程
• 目录拆分 / GNU parallel 实现并发

八、校验与一致性

1️⃣ 默认比较规则

• size + mtime

2️⃣ 强制校验（慢）

-c

• 对文件做 checksum
• 非常耗 IO

九、权限 / ACL / 扩展属性

十、SSH 相关参数

指定 SSH 方式

-e "ssh -p 2222"

常见组合

rsync -av -e "ssh -o StrictHostKeyChecking=no"

十一、常见“生产级参数组合”

1️⃣ 普通目录同步（推荐模板）

rsync -av --info=progress2 /src/ /dst/

2️⃣ 大文件 / 虚拟机镜像

rsync -av \
  --partial \
  --append-verify \
  --info=progress2 \
  /vm-images/ backup:/vm-images/

3️⃣ 镜像备份（慎用）

rsync -av --delete /data/ /backup/data/

十二、最容易踩的坑（非常重要）

1️⃣ 目录结尾 / 的区别

rsync src/ dst/   # 同步内容
rsync src  dst/   # 同步目录本身

2️⃣ rsync 没有“全局超时”

• 网络卡死可能一直跑
• 外部用 timeout 或 Go context 控制

3️⃣ 不要随便用 --delete

• 先 dry-run

--dry-run

十三、exit code（用于自动化判断）

十四、一句话总结

rsync 是“长期可重复同步工具”，而不是 cp/scp 的简单替代；
掌握 -a、--partial、--append-verify、--delete 的边界，是生产使用的关键。

如果你需要，我可以：

• 给你 rsync 参数速查表（按场景）
• 或直接结合 Go exec / 自动化 / 虚拟化镜像同步 给你一套标准规范

chromedp是一个更快、更简单的Golang库用于调用支持Chrome DevTools协议的浏览器，同时不需要额外的依赖（例如Selenium和PhantomJS）

Chrome和Golang都与Google有着相当密切的关系，而Chrome DevTools其实就是Chrome浏览器按下F12之后的控制终端

2 为什么不使用Selenium

对于Golang开发来说，使用chromedp更为便捷，因为它仅仅需要Chrome浏览器而并不需要依赖ChromeDriver，省去了依赖问题，有助于自动化的构建和多平台架构的迁移

3 文章解决了什么需求

• 如何使用chromedp进行二维码登陆

• 如何将二维码展示在无图形化的终端上（makiuchi-d/gozxing解码 skip2/ go-qrcode编码）

• 如何保存Cookies实现短时间免登陆

网站会更新，文章不保证更新，请务必学会举一反三

4.如何使用chromedp进行二维码登陆

4.1 安装chromedp

• 下载并安装Chrome浏览器

• 创建Golang项目，开启Go Module(在项目目录下使用终端输入go mod init)

• 在项目目录下使用终端输入：

go get -u github.com/chromedp/chromedp
（如果有依赖问题请删除-u）

4.2 尝试打开网站

（以金山文档https://account.wps.cn/为例）

1.重新设置chromedp使用"有头"的方式打开，以便于我们进行debug

func main(){
    // chromdp依赖context上限传递参数
    ctx, _ := chromedp.NewExecAllocator(
        context.Background(),
        // 以默认配置的数组为基础，覆写headless参数
        // 当然也可以根据自己的需要进行修改，这个flag是浏览器的设置
        append(
            chromedp.DefaultExecAllocatorOptions[:],
            chromedp.Flag("headless", false),
        )...,
    )
}

2.创建chromedp上下文对象

func main(){
    // chromdp依赖context上限传递参数
    ...
    // 创建新的chromedp上下文对象，超时时间的设置不分先后
    // 注意第二个返回的参数是cancel()，只是我省略了
    ctx, _ = context.WithTimeout(ctx, 30*time.Second)
    ctx, _ = chromedp.NewContext(
        ctx,
        // 设置日志方法
        chromedp.WithLogf(log.Printf),
    )
    // 通常可以使用 defer cancel() 去取消
    // 但是在Windows环境下，我们希望程序能顺带关闭掉浏览器
    // 如果不希望浏览器关闭，使用cancel()方法即可
    // defer cancel()
    // defer chromedp.Cancel(ctx)
}

3.执行自定义的任务

func main(){
    // chromdp依赖context上限传递参数
    ...
    // 创建新的chromedp上下文对象，超时时间的设置不分先后
    // 注意第二个返回的参数是cancel()，只是我省略了
    ...
    // 执行我们自定义的任务 - myTasks函数在第4步
    if err := chromedp.Run(ctx, myTasks()); err != nil {
        log.Fatal(err)
        return
    }
}

4.至此程序的初始化过程已经完成，接下来就是任务——打开登陆页面

// 自定义任务
func myTasks() chromedp.Tasks {
    return chromedp.Tasks{
        // 1. 打开金山文档的登陆界面
        chromedp.Navigate(loginURL),
    }
}

5.运行一下程序，可以看到Chrome被打开，同时访问了我们指定的网站

4.3 获取二维码（点击过程）

1.需要点击微信登陆按钮，先找到按钮的选择器，右键按钮并在菜单中点击检查，然后可以看到按钮的元素

2.右键元素打开菜单找到copy下的copy selector，即获取到选择器

3.我们尝试点击微信登陆按钮，发现还需要点击一下确认，重复上述步骤获取确认按钮的选择器

4.用代码执行上述点击步骤

// 自定义任务
func myTasks() chromedp.Tasks {
    return chromedp.Tasks{
        // 1. 打开金山文档的登陆界面
        chromedp.Navigate(loginURL),
        // 2. 点击微信登陆按钮
        // #wechat > span:nth-child(2)
        chromedp.Click(`#wechat > span:nth-child(2)`),
        // 3. 点击确认按钮
        // #dialog > div.dialog-wrapper > div > div.dialog-footer > div.dialog-footer-ok
        chromedp.Click(`#dialog > div.dialog-wrapper > div > div.dialog-footer > div.dialog-footer-ok`),
    }
}

5.运行程序即可直达二维码展示界面

6.用同样的方式，获取二维码图片的选择器

7.用代码实现获取二维码

有两点需要注意，第一是二维码有加载过程，第二是二维码是元素渲染，

我们需要用截图的方式获取（也可以用js来获取对应的href并下载，但是为了照顾小白，选择最简单的）

func myTasks() chromedp.Tasks {
    return chromedp.Tasks{
        // 1. 打开金山文档的登陆界面
        ...
        // 2. 点击微信登陆按钮
        ...
        // 3. 点击确认按钮
        ...
        // 4. 获取二维码
        // #wximport
        getCode(),
    }
}
func getCode() chromedp.ActionFunc {
    return func(ctx context.Context) (err error) {
        // 1. 用于存储图片的字节切片
        var code []byte
        // 2. 截图
        // 注意这里需要注明直接使用ID选择器来获取元素（chromedp.ByID）
        if err = chromedp.Screenshot(`#wximport`, &code, chromedp.ByID).Do(ctx); err != nil {
            return
        }
        // 3. 保存文件
        if err = ioutil.WriteFile("code.png", code, 0755); err != nil {
            return
        }
        return
    }
}

8.执行程序即可发现目录下已经存储了二维码图片文件，我们可以通过扫描此二维码进行登陆，与浏览器上扫描为同一种效果

5. 如何将二维码展示在无图形化的终端上

（与chromedp无关，属于额外内容）

1.在上述步骤中，我们已经获取了二维码，接下来我们需要在终端显示二维码，首先是解码，这里使用gozxing库

func printQRCode(code []byte) (err error) {
    // 1. 因为我们的字节流是图像，所以我们需要先解码字节流
    img, _, err := image.Decode(bytes.NewReader(code))
    if err != nil {
        return
    }
    // 2. 然后使用gozxing库解码图片获取二进制位图
    bmp, err := gozxing.NewBinaryBitmapFromImage(img)
    if err != nil {
        return
    }
    // 3. 用二进制位图解码获取gozxing的二维码对象
    res, err := qrcode.NewQRCodeReader().Decode(bmp, nil)
    if err != nil {
        return
    }
    return
}

2.然后重新编码来输出二维码到终端，这里使用go-qrcode库

// 请注意import的库发生了重名
import (
    "github.com/makiuchi-d/gozxing"
    "github.com/makiuchi-d/gozxing/qrcode"
    goQrcode "github.com/skip2/go-qrcode"
)
func printQRCode(code []byte) (err error) {
    // 1. 因为我们的字节流是图像，所以我们需要先解码字节流
    ...
    // 2. 然后使用gozxing库解码图片获取二进制位图
    ...
    // 3. 用二进制位图解码获取gozxing的二维码对象
    ...
    // 4. 用结果来获取go-qrcode对象（注意这里我用了库的别名）
    qr, err := goQrcode.New(res.String(), goQrcode.High)
    if err != nil {
        return
    }
    // 5. 输出到标准输出流
    fmt.Println(qr.ToSmallString(false))
    return
}

3.修改我们第二步的过程

func getCode() chromedp.ActionFunc {
    return func(ctx context.Context) (err error) {
        // 1. 用于存储图片的字节切片
        ...
        // 2. 截图
        // 注意这里需要注明直接使用ID选择器来获取元素（chromedp.ByID）
        ...
        // 3. 把二维码输出到标准输出流
        if err = printQRCode(code); err != nil {
            return err
        }
        return
    }
}

3.运行程序即可查看效果

6. 如何保存Cookies实现短时间免登陆

1.在上述过程中，我们可以通过二维码扫描登陆，网站会在登陆之后进行跳转，跳转后我们需要保存cookies来维持我们的登录状态，代码实现如下

// 保存Cookies
func saveCookies() chromedp.ActionFunc {
    return func(ctx context.Context) (err error) {
        // 等待二维码登陆
        if err = chromedp.WaitVisible(`#app`, chromedp.ByID).Do(ctx); err != nil {
            return
        }
        // cookies的获取对应是在devTools的network面板中
        // 1. 获取cookies
        cookies, err := network.GetAllCookies().Do(ctx)
        if err != nil {
            return
        }
        // 2. 序列化
        cookiesData, err := network.GetAllCookiesReturns{Cookies: cookies}.MarshalJSON()
        if err != nil {
            return
        }
        // 3. 存储到临时文件
        if err = ioutil.WriteFile("cookies.tmp", cookiesData, 0755); err != nil {
            return
        }
        return
    }
}

2.获取到Cookies之后，我们需要在程序运行时将Cookies从临时文件中加载到浏览器中

// 加载Cookies
func loadCookies() chromedp.ActionFunc {
    return func(ctx context.Context) (err error) {
        // 如果cookies临时文件不存在则直接跳过
        if _, _err := os.Stat("cookies.tmp"); os.IsNotExist(_err) {
            return
        }
        // 如果存在则读取cookies的数据
        cookiesData, err := ioutil.ReadFile("cookies.tmp")
        if err != nil {
            return
        }
        // 反序列化
        cookiesParams := network.SetCookiesParams{}
        if err = cookiesParams.UnmarshalJSON(cookiesData); err != nil {
            return
        }
        // 设置cookies
        return network.SetCookies(cookiesParams.Cookies).Do(ctx)
    }
}

3.通过上述两步我们已经可以保持登陆状态，然后我们需要检查一下是否成功，这里调用浏览器执行js脚本获取当前页面的网址，判断是否已经个人中心页面，如果为真，则停止操作

// 检查是否登陆
func checkLoginStatus() chromedp.ActionFunc {
    return func(ctx context.Context) (err error) {
        var url string
        if err = chromedp.Evaluate(`window.location.href`, &url).Do(ctx); err != nil {
            return
        }
        if strings.Contains(url, "https://account.wps.cn/usercenter/apps") {
            log.Println("已经使用cookies登陆")
            chromedp.Stop()
        }
        return
    }
}

4.最终重新设置我们的浏览器任务即可

// 自定义任务
func myTasks() chromedp.Tasks {
    return chromedp.Tasks{
        // 0. 加载cookies <-- 变动
        loadCookies(),
        // 1. 打开金山文档的登陆界面
        ...
        // 判断一下是否已经登陆  <-- 变动
        checkLoginStatus(),
        // 2. 点击微信登陆按钮
        // #wechat > span:nth-child(2)
        ...
        // 3. 点击确认按钮
        // #dialog > div.dialog-wrapper > div > div.dialog-footer > div.dialog-footer-ok
        ...
        // 4. 获取二维码
        // #wximport
        ...
        // 5. 若二维码登录后，浏览器会自动跳转到用户信息页面  <-- 变动
        saveCookies(),
    }
}

5.我们使用已经登陆的cookies运行程序可以发现我们成功跳过登陆过程

这些库——
都是我在真实生产系统中踩过坑、救过火、扛过流量的武器。
每一个都在我崩溃边缘的时候救过命。

如果今天要我从零搭一个 Go 后端，
我只会带上这 10 个。

1️⃣ Gin —— 写 API 永远不后悔的框架

Gin 几乎是我所有 Go 后端的骨架。
它快、干净、不啰嗦，而且永远不会碍事。

package main

import (
    "github.com/gin-gonic/gin"
)

func main() {
    r := gin.Default()
    r.GET("/ping", func(c *gin.Context) {
        c.JSON(200, gin.H{"message": "pong"})
    })
    r.Run()
}

我一直用 Gin 的原因：

• • ⚡ 路由极快

• • 🧩 中间件机制丝滑

• • 🧱 自带完善错误处理

一句话：它让 Go 写 Web 变得愉快。

2️⃣ GORM —— 那个你骂但一直离不开的 ORM

别被键盘侠带跑偏。
GORM 拯救了我上千行原生 SQL。
功能够用、API 稳定、生态完善。

import (
    "gorm.io/driver/postgres"
    "gorm.io/gorm"
)

db, err := gorm.Open(postgres.Open("dsn"), &gorm.Config{})

type User struct {
    ID   uint
    Name string
}

db.AutoMigrate(&User{})
db.Create(&User{Name: "Rishabh"})

我的原则：

95% 用 GORM，剩下 5% 用原生 SQL 解决“野生问题”。

3️⃣ zap —— 真·高性能日志

Go 自带的日志在生产环境就是灾难。
Zap 来自 Uber 团队，速度快到离谱。

它是结构化日志、零内存拷贝、几乎无性能损耗。
在高并发服务中，它的性能比 stdlib logger 快 约 10 倍。

当你凌晨 3 点看日志时，
可读、可检索、不卡性能，就是救命。

4️⃣ Testify —— 测试不再痛苦

测试不该是折磨。
testify 让单元测试变得像写断言一样简单。

import (
    "testing"
    "github.com/stretchr/testify/assert"
)

func TestSum(t *testing.T) {
    result := 2 + 2
    assert.Equal(t, 4, result, "they should be equal")
}

不再写 if/else 比较。
一句断言，测试变清爽。

5️⃣ Cobra —— 真正能扩展的 CLI 框架

几乎每个系统最终都需要 CLI。
Cobra 就是 Go 世界的 “argparse++”。

import (
    "github.com/spf13/cobra"
    "fmt"
)

var rootCmd = &cobra.Command{
    Use:   "mycli",
    Short: "My custom CLI tool",
    Run: func(cmd *cobra.Command, args []string) {
        fmt.Println("Hello from CLI!")
    },
}

func main() {
    rootCmd.Execute()
}

它不仅能做命令，还能嵌套子命令、支持 flag、自动生成帮助。
更棒的是，它和 Viper 天生一对。

6️⃣ Viper —— 配置管理不再“咬人”

Go 的配置管理一直让人头大。
Viper 支持 YAML、JSON、环境变量、命令行参数，
一行代码全搞定。

import (
    "github.com/spf13/viper"
    "fmt"
)

func main() {
    viper.SetConfigName("config")
    viper.AddConfigPath(".")
    viper.ReadInConfig()
    fmt.Println(viper.GetString("app.name"))
}

搭配 Cobra 使用，
CLI + 配置，完美闭环。

7️⃣ go-redis —— 稳如老狗的缓存客户端

别用一堆封装 Redis 的“高级库”了。
Go 官方的 go-redis 就足够强大。

import (
    "github.com/redis/go-redis/v9"
    "context"
)

rdb := redis.NewClient(&redis.Options{
    Addr: "localhost:6379",
})
rdb.Set(context.Background(), "foo", "bar", 0)

稳定、性能好、社区活跃、API 明确。
我用它处理缓存、消息队列、分布式锁，
从没掉过链子。

8️⃣ Go Kit —— 真·微服务架构利器

当项目不再是一个简单 API，而是多模块、多协议的系统时，
Go Kit 是你最好的朋友。

它让你的服务从“HTTP-only”
升级为可复用、可观测、可扩展的微服务架构。

import (
    "github.com/go-kit/kit/endpoint"
    "context"
    "strings"
)

func makeUppercaseEndpoint() endpoint.Endpoint {
    return func(ctx context.Context, request interface{}) (interface{}, error) {
        req := request.(string)
        return strings.ToUpper(req), nil
    }
}

它不是框架，而是一个架构工具箱。
我曾用它支撑每秒上万请求的服务。

9️⃣ Prometheus Client —— 度量从未如此轻松

性能指标不是奢侈品，而是必要的生命线。
Prometheus 的 Go 客户端让监控变得自然且零阻力。

import (
    "github.com/prometheus/client_golang/prometheus"
    "github.com/prometheus/client_golang/prometheus/promhttp"
    "net/http"
)

var ops = prometheus.NewCounterVec(
    prometheus.CounterOpts{Name: "http_requests_total", Help: "Total requests"},
    []string{"method"},
)

func main() {
    prometheus.MustRegister(ops)
    http.Handle("/metrics", promhttp.Handler())
    http.ListenAndServe(":2112", nil)
}

轻松集成 Grafana，
生产监控一目了然。

🔟 Wire —— 依赖注入，不用魔法也能优雅

Wire 来自 Google，
它能帮你生成依赖注入代码——
没有运行时开销，没有反射，没有黑魔法。

import "github.com/google/wire"

type Foo struct{}
type Bar struct{}

func NewFoo() *Foo { return &Foo{} }
func NewBar(f *Foo) *Bar { return &Bar{} }

var Set = wire.NewSet(NewFoo, NewBar)

生成完就是纯 Go 代码。
可维护、可调试、无副作用。

用过一次，你就再也不想手动注入。

🧩 结语：别追潮流，用经过战火的东西

这些库不是 GitHub 热榜上的新宠，
而是经历了真实生产考验的老兵。

它们让我写的后端：

• • 快

• • 稳

• • 可维护

• • 能在凌晨两点救场

少追热点，多用验证过的东西。

简单、高效、优雅。

但当你熬过凌晨两点的内存泄漏、排查过线上 P99 延迟飙升、
或在生产环境里盯着看不懂的指标图发呆时，你会突然意识到：

Go 真正的威力，不在语法，而在 工具链（Tooling）。

而多数工程师，都是踩过坑之后才懂。

以下，就是每个高级 Go 工程师最终都会“痛过一遍”的工具经验。

1️⃣ pprof 不是选配，而是求生工具

每个 Go 开发迟早都会遇到那种莫名其妙的性能波动：
延迟飙升、内存暴涨、CPU 突然吃满。

新手的反应是猜：

“是不是 GC？”
“是不是 goroutine 太多？”

老手的反应是测：

go tool pprof http://localhost:6060/debug/pprof/heap

pprof 不是 profiler（性能分析器）而已，
它是 真相探测器。

它告诉你 CPU 时间花在哪、内存怎么分配、哪个锁在阻塞。

老工程师不会“感觉问题在哪”，
他们用 flame graph 把问题直接点亮。

go tool pprof -http=:8080 cpu.out

📍 经验总结：

如果你解释不出系统的性能画像，你就是在盲飞。

2️⃣ trace：当系统“不慢但不爽”时

有时服务没卡 CPU，也没死锁，
但就是“慢得莫名其妙”。

这时新手抓狂，老手会掏出：

go test -trace trace.out go tool trace trace.out

Go 的 trace 工具可以展示：

• • 哪些 goroutine 处于“可运行但未运行”状态

• • 调度器是如何把任务分配给线程的

• • 哪些系统调用卡住了整个流程

一句话：

你能看到代码“为什么看起来没阻塞，但其实在等”。

📍 教训：
每个老工程师都曾追了三天“虚幻瓶颈”才发现 trace 才是答案。

3️⃣ Delve (dlv)：实时显微镜

fmt.Println() 调试够用——
直到你遇到竞争条件、指针错乱、异步逻辑崩溃。

那一刻你会感叹：

没有 dlv，根本活不下去。

dlv debug ./cmd/server

然后在交互界面输入：

(dlv) break main.main (dlv) continue (dlv) goroutines

你能立刻看到几百个 goroutine 的状态：
有的在跑，有的在阻塞，有的在等通道。

📍 经验总结：

并发 bug 不在逻辑里，而在“时序”里。

4️⃣ benchstat：帮你看清幻觉

你改了点性能优化，重新跑 benchmark：
“快了 5%！完美！”
——真的吗？

其实这可能只是噪音。

老工程师会这样验证：

go test -bench=. -benchmem -count=10 > old.txt # 修改后 go test -bench=. -benchmem -count=10 > new.txt benchstat old.txt new.txt

它会告诉你改动是否真的有统计意义上的提升。

📍 经验总结：

性能直觉？往往是错觉。

5️⃣ go vet + staticcheck：提前救你一命

很多人以为 go vet 就是 lint。
错，它是语义级分析。

能抓出：

• • 错误的 Printf 参数

• • 循环里 defer 的坑

• • 无效的 struct tag

再加上 staticcheck：

staticcheck ./...

还能检测：

• • 泄漏的 goroutine

• • 未检查的 error

• • 已弃用的 API

• • 无效赋值

📍 经验总结：

几乎每次生产事故，staticcheck 都早已给过警告，只是没人看。

6️⃣ Build Tags & Toolchain：真正的工程之道

高级工程师会用 build tag 区分环境：

// +build debug

构建时：

go build -tags debug

或者跨平台编译：

GOOS=linux GOARCH=amd64 go build -o app-linux

新手在 Docker 里折腾一下午，
老手一句命令就搞定。

📍 经验总结：

善用工具链，你才配叫工程师。

7️⃣ 在生产环境里用 pprof，但不作死

每个人都学过在本地用 pprof。
但在生产用？要小心。

正确姿势：

import _ "net/http/pprof"

在内网或加认证暴露端口：

curl -sK -O http://service:6060/debug/pprof/heap

📍 经验总结：

你只有一次机会把线上搞崩，然后才会学会“敬畏 profiling”。

8️⃣ go build -gcflags=-m：内存分配全透明

当你开始在意 GC 时，
你会运行：

go build -gcflags=-m

输出可能是：

moved to heap: user inlining call to log.Printf

这告诉你：

• • 哪些变量被分配到堆（代价大）

• • 哪些函数被内联（更快）

• • 哪些分配被优化掉

📍 经验总结：

优化的目标不是“少分配”，而是“可预测的 GC 行为”。

9️⃣ CI/CD 集成：高级工程师的“安静胜利”

初级开发：

“跑 go test 就完事了。”

高级工程师：

• • CI 自动跑 go vet 和 staticcheck

• • 生成并上传覆盖率报告

• • 预提交自动执行 go mod tidy

📍 经验总结：

工具不是“帮你”，而是“管你”，才能防止团队滑向混乱。

🔟 go doc：你忽略的隐藏神器

被严重低估的命令：

go doc net/http

它能离线展示 API 结构、方法说明、示例。

老工程师常常直接读标准库源码，
因为那些代码——

已在 Google 规模下被验证、测试、打磨十几年。

🧰 二、NFS 服务器端安装与配置

1️⃣ 安装 NFS 服务

# CentOS / Rocky / openEuler
yum install -y nfs-utils

# Ubuntu / Debian
apt install -y nfs-kernel-server

2️⃣ 创建共享目录

mkdir -p /data/nfs-share
chmod -R 777 /data/nfs-share
chown -R nobody:nogroup /data/nfs-share  # 或者 nfsnobody:nfsnobody

3️⃣ 配置 NFS 导出文件 /etc/exports

编辑文件：

vi /etc/exports

示例内容：

/data/nfs-share 192.168.10.0/24(rw,sync,no_root_squash)

参数解释：

• rw：可读写
• sync：同步写入磁盘（更安全）
• no_root_squash：允许客户端 root 用户保留 root 权限（K8s 环境必需）
• 192.168.10.0/24：允许的网段（可换成单个IP）

4️⃣ 启动并设置开机自启

systemctl enable nfs-server --now

检查服务状态：

systemctl status nfs-server

5️⃣ 刷新配置并查看共享目录

exportfs -rav
showmount -e

输出示例：

Export list for nfs-server:
/data/nfs-share 192.168.10.0/24

💻 三、客户端挂载 NFS 共享

1️⃣ 安装 NFS 客户端工具

# CentOS / openEuler
yum install -y nfs-utils

# Ubuntu / Debian
apt install -y nfs-common

2️⃣ 创建挂载点并挂载

mkdir -p /mnt/nfs-share
mount -t nfs 192.168.10.10:/data/nfs-share /mnt/nfs-share

验证：

df -h | grep nfs

测试：

touch /mnt/nfs-share/test.txt
ls /mnt/nfs-share/

如果在服务器 /data/nfs-share/ 也能看到 test.txt，说明挂载成功 ✅

3️⃣ 开机自动挂载（可选）

编辑 /etc/fstab：

192.168.10.10:/data/nfs-share /mnt/nfs-share nfs defaults 0 0

立即生效：

mount -a

🔒 四、防火墙与SELinux

如果服务端启用了防火墙：

# Firewalld
firewall-cmd --permanent --add-service=nfs
firewall-cmd --permanent --add-service=mountd
firewall-cmd --permanent --add-service=rpc-bind
firewall-cmd --reload

如果启用了 SELinux，执行：

setsebool -P nfs_export_all_rw on

🧩 五、进阶用法（可选）

✅ 1. 查看客户端挂载情况

showmount -a

✅ 2. 取消挂载

umount /mnt/nfs-share

✅ 3. 手动刷新导出列表

exportfs -arv

🧱 六、Kubernetes 场景（如果你是为 K8s 提供存储）

可以直接把这台 NFS Server 暴露出来，创建一个 StorageClass 供 PVC 动态分配使用，例如：

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: nfs-storage
provisioner: kubernetes.io/nfs
parameters:
  server: 192.168.10.10
  path: /data/nfs-share
reclaimPolicy: Retain

✅ 七、总结命令速查表

下面我教你 从检测 → 启用 → 验证 全流程（支持 CentOS / Ubuntu / Debian / openEuler / Kylin / 等主流发行版）。

🧠 一、查看当前内核版本

BBR 需要 Linux 内核 ≥ 4.9

uname -r

示例输出：

5.10.0-23-amd64

✅ 如果版本 ≥ 4.9，可以直接开启。
❌ 如果低于 4.9，需要升级内核（下面会讲）。

🚀 二、开启 BBR（无需重启）

执行以下命令启用：

modprobe tcp_bbr

然后编辑配置：

echo "net.core.default_qdisc=fq" >> /etc/sysctl.conf
echo "net.ipv4.tcp_congestion_control=bbr" >> /etc/sysctl.conf
sysctl -p

立即加载：

sysctl -w net.core.default_qdisc=fq
sysctl -w net.ipv4.tcp_congestion_control=bbr

🔍 三、验证是否生效

查看当前 TCP 拥塞算法：

sysctl net.ipv4.tcp_congestion_control

输出应为：

net.ipv4.tcp_congestion_control = bbr

再确认模块加载成功：

lsmod | grep bbr

输出类似：

tcp_bbr                20480  3

✅ 表示成功启用。

⚙️ 四、（如内核太旧）升级内核

如果你的内核版本 < 4.9，例如：

3.10.0-1160.el7.x86_64

这是 CentOS 7 默认版本，不支持 BBR。
解决办法如下：

▶ 1. 升级内核（CentOS 7）

yum install -y https://www.elrepo.org/elrepo-release-7.el7.elrepo.noarch.rpm
yum --enablerepo=elrepo-kernel install kernel-ml -y
grub2-set-default 0
reboot

重启后再执行：

uname -r

应显示 5.x 或更高版本。

然后重复上面 第二步 启用 BBR。

🐧 五、Ubuntu / Debian 启用 BBR

Ubuntu 18+（内核自带）

sudo modprobe tcp_bbr
echo "net.core.default_qdisc=fq" | sudo tee -a /etc/sysctl.conf
echo "net.ipv4.tcp_congestion_control=bbr" | sudo tee -a /etc/sysctl.conf
sudo sysctl -p

验证：

sysctl net.ipv4.tcp_congestion_control

🧩 六、openEuler / Kylin / 其他国产系统

这些系统基于较新内核（通常 ≥ 4.19），可直接开启：

modprobe tcp_bbr
sysctl -w net.core.default_qdisc=fq
sysctl -w net.ipv4.tcp_congestion_control=bbr
sysctl -p

🧪 七、测试 BBR 是否有效

可以使用 iperf3、speedtest-cli 或 curl 测试速度前后差异：

iperf3 -c <server_ip> -P 4

BBR 的典型特征是：

• RTT 更低
• 丢包后恢复更快
• 带宽利用率提升显著

🧾 八、一键启用脚本（适用于所有系统）

#!/bin/bash
modprobe tcp_bbr
grep -q "tcp_congestion_control" /etc/sysctl.conf || {
cat >> /etc/sysctl.conf <<EOF
net.core.default_qdisc=fq
net.ipv4.tcp_congestion_control=bbr
EOF
}
sysctl -p
sysctl net.ipv4.tcp_congestion_control
lsmod | grep bbr

保存为 enable_bbr.sh 后执行：

bash enable_bbr.sh

是否方便告诉我：

• 你的系统是哪个发行版？（比如 CentOS7、Ubuntu20.04、Kylin、openEuler）
• 是物理机、虚拟机还是 K8s 节点？

我可以帮你输出一份定制命令（避免不兼容或 kernel 冲突）。

lsblk

示例输出：

NAME    MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda       8:0    0   40G  0 disk
├─sda1    8:1    0   40G  0 part /
sdb       8:16   0  100G  0 disk   <-- 新数据盘

假设新盘为 /dev/sdb

🧾 2. 分区（若无分区）

fdisk /dev/sdb

常见操作：

• 输入 n：新建分区
• 输入 p：主分区
• 输入 1：分区号
• 回车（默认起始）
• 回车（默认结束）
• 输入 w：写入保存并退出

之后应生成 /dev/sdb1 分区。

🧾 3. 格式化分区为 ext4

mkfs.ext4 /dev/sdb1

⚠️ 注意：此操作会清除该分区所有数据。

🧾 4. 创建挂载目录并挂载

mkdir -p /data
mount /dev/sdb1 /data

查看是否挂载成功：

df -h | grep /data

🧾 5. 设置开机自动挂载

✅ 方法一：使用设备路径（简单但不稳定）

echo '/dev/sdb1  /data  ext4  defaults  0 0' >> /etc/fstab

✅ 方法二：使用 UUID（推荐）

1. 查看 UUID：

blkid /dev/sdb1

示例输出：

/dev/sdb1: UUID="abcd-1234-5678-efgh" TYPE="ext4"

2. 编辑 /etc/fstab 添加：

UUID=abcd-1234-5678-efgh /data ext4 defaults 0 0

3. 测试挂载是否成功：

umount /data
mount -a

🧾 6. 设置目录权限（可选）

chown -R youruser:youruser /data
chmod 755 /data

✅ 常见问题排查

📌 命令小结

lsblk
fdisk /dev/sdb
mkfs.ext4 /dev/sdb1
mkdir -p /data
mount /dev/sdb1 /data
blkid /dev/sdb1
vim /etc/fstab
mount -a

📎 附加建议

• 推荐使用 UUID 挂载，防止设备顺序变化导致挂载失败
• 如果系统为云服务器，添加磁盘后可能需要重启或执行 SCSI 扫描命令

kubevirt/
├── api/                   # CRD 的定义，包括 VirtualMachine、VirtualMachineInstance 等的 API 类型
│   ├── core/              # 核心 API 定义
│   └── generated/         # 自动生成的 API 代码
│
├── cmd/                   # 可执行文件入口，例如 virt-api、virt-controller、virt-handler 等
│   ├── virt-api/
│   ├── virt-controller/
│   ├── virt-handler/
│   └── virt-launcher/
│
├── pkg/                   # 核心逻辑代码，控制器、调度器、设备管理等
│   ├── api/               # 与 `api/` 相关的封装逻辑
│   ├── virt-api/          # 实现 kubevirt 的 API Server（服务暴露 CRD 接口）
│   ├── virt-controller/   # 实现虚拟机控制器（管理 VM 生命周期）
│   ├── virt-handler/      # 在每个节点上运行的守护进程，管理 VM 运行时
│   ├── virt-launcher/     # 创建和启动 QEMU 虚拟机的容器入口
│   ├── virt-chroot/       # 用于 chroot 隔离逻辑
│   ├── util/              # 各种工具函数和工具包
│   └── network/           # 虚拟机网络配置与支持代码
│
├── tests/                 # 测试用例，包括 e2e 测试、功能测试等
│   ├── e2e/               # 端到端测试
│   └── framework/         # 测试框架和公用逻辑
│
├── tools/                 # 构建、测试等相关工具脚本
│
├── hack/                  # 开发、CI、构建辅助脚本（例如生成代码、部署等）
│
├── manifests/             # Kubernetes 资源清单，安装/部署相关
│
├── cluster/               # 用于本地部署开发集群（例如使用 kind）
│
├── docs/                  # 项目文档
│
├── automation/            # GitHub Actions / CI 自动化流程定义
│
├── vendor/                # Go modules 的依赖（go mod vendor 后生成）
│
├── go.mod                 # Go modules 定义文件
├── go.sum
└── Makefile               # 构建入口

关键组件说明：

• virt-api：为虚拟机相关的 CRD 提供 REST 接口。

• virt-controller：负责控制虚拟机的生命周期，比如创建、删除等。

• virt-handler：部署在每个节点上，负责和 libvirt/qemu/kvm 等交互，实际启动虚拟机。

• virt-launcher：每个虚拟机的启动容器，负责运行虚拟机进程。

• tests/e2e：用于验证 KubeVirt 在集群中部署和运行 VM 的行为

定义：当关系模式R的所有属性都不能在分解为更基本的数据单位时，称R是满足第一范式的，简记为1NF。

简易理解：表中的每列的属性不可再分

举例说明：

上表中，可以看到（就读信息）这一列，其实可以分解为年级和专业，也因为（就读信息）这一属性可以再分，故不满足第一范式

修改：

这样将（就读信息）拆分为（年级）、（专业）两个属性，便满足了第一范式（1NF）

二、第二范式（2NF）

定义：如果关系模式R满足第一范式，并且R得所有非主属性都完全依赖于R的每一个候选关键属性，称R满足第二范式，简记为2NF。

简易理解：在第一范式的基础上，表里的非主属性必须都依赖于主键（联合主键）

举例说明：

上表中，可以看到（教师姓名、成绩）两个属性都依赖于（学号）和（课程），但是（学生姓名、专业）这一属性却只依赖于（学号），不依赖于（课程），即：只需要知道（学号）便可得知（学生姓名、专业）。所以，导致非主属性（学生姓名、专业）不完全依赖于主键（学号、课程），故不符合第二范式。

修改：

将原表拆分为两张表，即可实现让它的非主属性都完全依赖于主键，即可符合第二范式（2NF）

三、第三范式

定义：设R是一个满足第一范式条件的关系模式，X是R的任意属性集，如果X非传递依赖于R的任意一个候选关键字，称R满足第三范式，简记为3NF。

简单理解：在第二范式的基础上，表中的非主属性不可以存在依赖关系 举例说明：

上表中，我们可以看到表中的非主属性都依赖于（学号），满足了第二范式。 但是，（班主任性别、年龄）这两个属性是直接依赖于（班主任姓名）这一属性的，与（学号）属于间接依赖。 这就导致了表中的非主属性存在着依赖关系，不符合第三范式。

修改：

将原表拆分为两张表：学生表与班主任表，在满足第二范式的同时，表中的非主属性都不存在着依赖关系，故符合第三范式

总结

个人认为，三大范式（1NF、2NF、3NF），其实是将一张表不停拆分、细化的过程，但在实际情况中，不停的对表进行拆分，在执行查询操作时就需要进行联表查询，所以，拆分的表多了，也会导致查询的效率也会大打折扣。所以一般最多拆成3张表，并且，为了查询方便，可能也会故意的将一些与主键无关的属性放在表中（在设计过程中，三大范式不是需要严格遵守的，只是提供了一种设计规范，供人参考使用）