大纲

• CentOS 7 通过 Shell 脚本实现磁盘监控报警
• Debian 13 通过 Shell 脚本实现磁盘监控报警

前言

本文将介绍 Debian 13 系统如何使用 Shell 脚本，实现对磁盘使用率的监控，并发送告警邮件（支持腾讯企业邮箱或者 QQ 邮箱）。

准备工作

防火墙配置

• 安装 UFW 服务

1

sudo apt install ufw -y

• 防火墙开放 22 端口（避免 SSH 远程连接断开）

1

sudo ufw allow 22/tcp

• 防火墙开放 465 端口（SMTPS，用于邮件发送）

1

sudo ufw allow 465/tcp

• 启用防火墙（务必先开放 SSH 的 22 端口再启用防火墙）

1

sudo ufw enable

• 查看防火墙运行状态和已开放端口

1

sudo ufw status verbose

安装邮件服务

• 安装邮件服务

1
2
3
4
5

# 安装 s-nail
sudo apt install s-nail -y

# 创建从 mail 到 s-nail 的软链接（可选操作，后续也可以直接使用 s-nail 命令）
sudo ln -s /usr/bin/s-nail /usr/bin/mail

导入 NSS 证书

• 安装 NSS 工具

1

sudo apt install libnss3-tools -y

• 导入 NSS 证书（这里使用 root 用户）

1
2
3
4
5
6
7
8
9
10
11
12
13
14

# 创建用于存储证书的目录
sudo mkdir -p /root/.certs/

# 从 QQ 邮箱的 SMTP 服务器（端口 465）获取 SSL 证书链，并提取出证书部分（BEGIN/END 标记之间），保存到 qq-smtp.crt 文件
sudo sh -c "echo -n | openssl s_client -connect smtp.qq.com:465 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > /root/.certs/qq-smtp.crt"

# 将提取的证书中的 "GeoTrust SSL CA" 证书添加到 NSS 数据库（-d 指定目录），信任属性设置为 "C,,"（表示作为 CA 证书，但不用于客户端 / 服务器认证）
sudo certutil -A -n "GeoTrust SSL CA" -t "C,," -d /root/.certs -i /root/.certs/qq-smtp.crt

# 将提取的证书中的 "GeoTrust Global CA" 证书添加到 NSS 数据库，同样设置信任属性为 "C,,"
sudo certutil -A -n "GeoTrust Global CA" -t "C,," -d /root/.certs -i /root/.certs/qq-smtp.crt

# 列出 NSS 数据库中所有已安装的证书，用于验证证书是否成功导入
sudo certutil -L -d /root/.certs

• 获取腾讯邮箱授权密码

1
2
3
4
5
6
7
8
9
10

1. 获取授权码：
   - 腾讯邮箱（包括腾讯企业邮箱和 QQ 邮箱）需要在邮箱设置中生成 SMTP 服务授权码。
   - 登录邮箱，前往 设置 -> 帐号设置 -> SMTP 服务，生成授权码并使用它代替密码。

2. 安全性设置：
   - 确保已启用 SMTP 服务和客户端登录支持。

3. SMTP 服务器地址：
   - QQ 邮箱： smtp.qq.com
   - 腾讯企业邮箱：smtp.exmail.qq.com

• 编辑系统配置文件，在文件末尾追加以下内容（请自行更改以下配置信息，切忌直接复制，这里使用的是 QQ 邮箱）

1
2
3
4
5
6
7
8
9
10
11
12
13

# 备份配置文件
sudo cp /etc/s-nail.rc /etc/s-nail.rc.bak

# 编辑配置文件
sudo vi /etc/s-nail.rc

set from=clay@qq.com
set smtp="smtps://smtp.qq.com:465"
set smtp-auth-user=clay@qq.com
set smtp-auth-password=xxxxxxxxxxxx
set smtp-auth=login
set ssl-verify=ignore
set nss-config-dir=/root/.certs

测试邮件发送

• 测试邮件发送（这里使用 root 用户）

1

sudo sh -c "echo 'TestMail~' | mail -s 'TestMail' xxx@qq.com 2>/dev/null"

• 如果邮件发送失败，可以通过添加 -v 参数输出详细的日志信息，然后进一步排查原因

1

sudo sh -c "echo 'TestMail~' | mail -v -s 'TestMail' xxx@qq.com"

脚本实现

• 创建磁盘监控脚本文件，并添加以下内容

1

sudo vi /opt/disk_monitor.sh

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

#!/bin/bash

# 告警阈值
THRESHOLD=90

# 邮件接收者（使用空格分割多个邮件接收者）
EMAIL="xxx@qq.com"

# 磁盘设备
DISK_DEVICE=/dev/sda1

# 日志文件
LOG_FILE=/tmp/disk_monitor.log

# 创建日志文件
if [ ! -f "$LOG_FILE" ]; then
    touch "$LOG_FILE"
fi

# 获取服务器的公网 IP
IP_ADDRESS=$(curl -s https://checkip.amazonaws.com)

# 判断服务器的公网 IP 是否为空
if [ -n "$IP_ADDRESS" ]; then
   IP_ADDRESS="0.0.0.0"
fi

# 获取指定磁盘设备的使用率
CURRENT_USAGE=$(df -h $DISK_DEVICE | awk 'NR==2 {print $5}' | sed 's/%//g')

# 写入日志文件
echo "$(date '+%Y-%m-%d %H:%M:%S') 磁盘设备 $DISK_DEVICE 的使用率为 $CURRENT_USAGE%" >> $LOG_FILE

# 判断磁盘使用率是否超过阈值
if [ "$CURRENT_USAGE" -ge "$THRESHOLD" ]; then
    # 发送告警邮件
    echo "警告: 磁盘设备 $DISK_DEVICE 的空间使用率超过 $CURRENT_USAGE%, 请登录服务器 ($IP_ADDRESS) 及时清理文件." | mail -s "磁盘空间告警" $EMAIL 2>/dev/null
fi

• 脚本文件授权

1

sudo chmod 755 /opt/disk_monitor.sh

• 脚本测试执行（这里使用 root 用户）

1

sudo bash /opt/disk_monitor.sh

定时检测

• 创建磁盘监控的服务单元

1
2
3
4
5
6
7
8
9

# 创建系统配置文件，添加以下配置信息
sudo vi /etc/systemd/system/disk-monitor.service

[Unit]
Description=Disk Monitoring Service

[Service]
Type=oneshot
ExecStart=/opt/disk_monitor.sh

• 创建磁盘监控的定时器单元（比如每 30 分钟执行一次磁盘使用率检测）

1
2
3
4
5
6
7
8
9
10
11
12

# 创建系统配置文件，添加以下配置信息
sudo vi /etc/systemd/system/disk-monitor.timer

[Unit]
Description=Run disk monitor every 30 minutes

[Timer]
OnCalendar=*:0/30
Persistent=true

[Install]
WantedBy=timers.target

• 启动并启用磁盘监控的定时器

1
2
3
4
5

# 重新加载系统配置文件
sudo systemctl daemon-reload

# 开机启动并立刻启用磁盘监控的定时器
sudo systemctl enable --now disk-monitor.timer

• 查看磁盘监控定时器的运行状态

1

sudo systemctl list-timers --all

验证检测

• 查看磁盘监控脚本执行输出的日志信息

1
2

# 查看日志文件
sudo tail -f -n 50 /tmp/disk_monitor.log

1

2026-06-15 21:15:30 磁盘设备 /dev/sda1 的使用率为 85%

参考资料

• Linux 使用 mailx 发送腾讯邮件
• Linux Shell 脚本监控磁盘与邮件告警
• Linux 使用 Shell 脚本监控磁盘与邮件告警

大纲

• CentOS 7 安装 Docker 与 Docker-Compose
• Debian 11 安装 Docker 与 Docker-Compose
• Debian 12 安装 Docker 与 Docker-Compose
• Debian 13 安装 Docker 与 Docker-Compose

官方资源

• Docker 官方网站
• Docker 官方文档
• Docker Hub 官方网站

准备工作

卸载已有软件

卸载已安装的 Docker，避免对后续的安装步骤产生影响。

1
2
3
4
5
6
7
8
9
10
11
12

# 卸载旧版本，包括有关的配置文件
sudo apt-get purge docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin docker-ce-rootless-extras

# 保证卸载干净
sudo apt-get remove docker docker-engine docker.io containerd runc

# 删除文件
sudo rm -rf /etc/docker
sudo rm -rf /var/lib/docker
sudo rm -rf /usr/libexec/docker
sudo rm -rf /var/lib/containerd
sudo rm -rf /etc/apt/keyrings

安装依赖软件

1

sudo apt install -y apt-transport-https ca-certificates curl gnupg lsb-release

安装 Docker

添加存储库

1
2
3
4
5
6
7
8

# 添加 Docker 的官方 GPG 密钥
sudo curl -fsSL https://download.docker.com/linux/debian/gpg | gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg

# 添加 Docker 的 APT 存储库
sudo echo "deb [arch=amd64 signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/debian $(lsb_release -cs) stable" | tee /etc/apt/sources.list.d/docker.list > /dev/null

# 更新 APT 索引
sudo apt update

Docker 安装

1
2

# 安装最新版本的 Docker
sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin

Docker 启动

1
2
3
4
5
6
7
8

# 开机自启动 Docker
sudo systemctl enable docker

# 启动 Docker
sudo systemctl start docker

# 查看 Docker 的运行状态
sudo systemctl status docker

Docker 配置源

由于 Docker Hub 存在不可抗拒因素，导致在国内无法访问，因此需要配置 Docker 使用国内镜像源。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

# 创建配置目录
sudo mkdir -p /etc/docker

# 创建配置文件
sudo tee /etc/docker/daemon.json <<-'EOF'
{
  "registry-mirrors": [
     "https://ustc-edu-cn.mirror.aliyuncs.com",
     "https://mirror.iscas.ac.cn",
     "https://docker.nju.edu.cn",
     "https://docker.m.daocloud.io",
     "https://ccr.ccs.tencentyun.com",
     "https://dockerhub.timeweb.cloud"
    ]
}
EOF

# 使配置文件生效
sudo systemctl daemon-reload

# 重启 Docker
sudo systemctl restart docker

# 查看 Docker 的运行状态
sudo systemctl status docker

# 查看 Docker 的运行信息
sudo docker info

Docker 验证安裝

验证是否正确安装了 Docker，以下命令将下载一个测试镜像并在容器中运行它，容器在运行时将输出一条参考消息并退出

1

sudo docker run hello-world

安装 Docker-Compose

第一种安装方式

1
2
3
4
5

# 安装 Docker-Compose 插件
sudo apt install -y docker-compose-plugin

# 验证 Docker-Compose 插件
sudo docker compose version

第二种安装方式

使用 curl 命令来下载 Docker-Compose 的二进制包，除此之外还可以在 GitHub Releases 上面手动下载对应的文件，然后上传到目标服务器。

1
2
3
4
5
6
7
8

# 下载文件
sudo curl -L "https://github.com/docker/compose/releases/download/1.29.1/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose

# 文件授权
sudo chmod +x /usr/local/bin/docker-compose

# 验证下载
sudo docker-compose -v

常见安装问题

info 命令输出警告信息

• 问题描述：当 Docker 安装完成之后，执行 docker info 命令，发现有以下警告信息存在：

1
2
3
4
5
6
7
8
9
10

WARNING: No cpu cfs quota support
WARNING: No cpu cfs period support
WARNING: No cpu shares support
WARNING: No cpuset support
WARNING: No io.weight support
WARNING: No io.weight (per device) support
WARNING: No io.max (rbps) support
WARNING: No io.max (wbps) support
WARNING: No io.max (riops) support
WARNING: No io.max (wiops) support

• 解决办法：重启 Debian 服务器，让系统重新加载 cgroup 规则

参考

• Docker 介绍与安装
• Docker-Compose 安装与使用
• Debian 11 上安装 Docker
• Debian11 之 Docker 稳定版本安装

前言

系统环境

1

Linux option 6.12.90+deb13-cloud-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.12.90-1 (2026-05-22) x86_64 GNU/Linux

准备工作

安装 Supervisor

Supervisor 主要用于管理 Nginx 的开机自启动（带守护进程）。

1
2
3
4
5
6
7
8
9
10
11

# 安装
# yum install -y supervisor

# 开机自启动
# systemctl enable supervisord

# 启动服务
# systemctl start supervisord

# 查看服务状态
# systemctl status supervisord

创建 Nginx 用户和用户组

1
2
3
4
5
6
7
8

# 切换root用户
$ sudo -i

# 创建nginx用户组
# groupadd nginx

# 创建nginx用户（不允许远程登录）
# useradd -g nginx nginx -s /bin/false

更改最大打开文件描述符数

• Centos 7 更改最大文件描述符数
• Debian 12 更改最大文件描述符数

Nginx 编译安装

下载文件

1
2
3
4
5
6
7
8
9

# 创建下载目录
# mkdir -p /home/nginx/software

# 下载
# cd /home/nginx/software
# wget http://nginx.org/download/nginx-1.26.3.tar.gz

# 解压
# tar -xvf nginx-1.26.3.tar.gz

编译安装

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

# 进入下载目录
# cd /home/nginx/software/nginx-1.26.3

# 安装依赖库
# apt-get install build-essential libpcre2-dev zlib1g zlib1g-dev openssl libssl-dev

# 配置
./configure \
  --user=nginx \
  --group=nginx \
  --prefix=/usr/local/nginx \
  --with-pcre \
  --with-http_v2_module \
  --with-http_ssl_module \
  --with-http_realip_module \
  --with-http_gzip_static_module \
  --with-http_stub_status_module

# 编译安装
# make && make install

# 备份默认的配置文件
# cd /usr/local/nginx/conf
# cp nginx.conf nginx.conf.default

# 文件授权
# chown -R nginx:nginx /usr/local/nginx

配置 Nginx

1
2
3
4
5
6
7

# 编辑nginx的配置文件
# vim /usr/local/nginx/conf/nginx.conf
worker_processes  4;
error_log  logs/error.log;

# 校验配置文件是否正确
# /usr/local/nginx/sbin/nginx -t

配置防火墙

1
2
3
4
5
6
7
8

# 启动防火墙
# ufw enable

# 开放端口
# ufw allow 80/tcp

# 查看已开放的端口
# ufw status verbose

Nginx 服务管理

开机自启动 Nginx

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

# 创建nginx的supervistor配置文件
# touch /etc/supervisor/conf.d/nginx.conf

# 编辑nginx的supervistor配置文件
# vim /etc/supervisor/conf.d/nginx.conf
[program:nginx]
directory=/usr/local/nginx
command=/usr/local/nginx/sbin/nginx -g 'daemon off;' -c /usr/local/nginx/conf/nginx.conf
user=root
numprocs=1
autostart=true
autorestart=true
startretries=10
process_name=%(program_name)s
stdout_logfile_backups=5
stdout_logfile_maxbytes=10MB
stdout_logfile=/var/log/supervisor/nginx.log
stderr_logfile_backups=5
stderr_logfile_maxbytes=10MB
stderr_logfile=/var/log/supervisor/nginx-error.log

# 上面的配置，主进程会以root用户运行，worker进程会以nginx用户运行

# 重载nginx的supervistor配置文件，会自动启动nginx服务
# supervisorctl reload

# 查看nginx的运行状态
# supervisorctl status nginx
nginx RUNNING   pid 9451, uptime 0:00:56     #如果输出此日志信息，说明nginx启动成功，否则查看nginx的启动日志来排查问题

# 测试访问nginx
# curl -I -X GET 127.0.0.1:80

管理 Nginx 服务

1
2
3
4
5
6
7
8
9
10
11
12
13
14

# 关闭
# supervisorctl stop nginx

# 启动
# supervisorctl start nginx

# 重启
# supervisorctl restart nginx

# 查看状态
# supervisorctl status nginx

# 平滑更新nginx的配置文件
# /usr/local/nginx/sbin/nginx -s reload

Nginx 配置文件概述

1
2
3
4
5

安装目录：/usr/local/nginx
配置文件：/usr/local/nginx/conf/nginx.conf
错误日志：/usr/local/nginx/logs/error.log
访问日志：/usr/local/nginx/logs/access.log
nginx的supervistor配置文件：/etc/supervisor/conf.d/nginx.conf

参考资料

• 详解 Debian 系统上如何编译安装 Nginx

RAID 历史

1988 年美国加州大学伯克利分校的 D.A.Patterson 教授等首次在论文 “A Case of Redundant Array of Inexpensive Disks” 中提出了 RAID 概念，即廉价冗余磁盘阵列（ Redundant Array of Inexpensive Disks）。由于当时大容量磁盘比较昂贵，RAID 的基本思想是将多个容量较小、相对廉价的磁盘进行有机组合，从而以较低的成本获得与昂贵大容量磁盘相当的容量、性能、可靠性。随着磁盘成本和价格的不断降低，” 廉价” 已经变得毫无意义。因此，RAID 咨询委员会（RAID Advisory Board，RAB）决定用 “独立” 替代 “廉价”，于是 RAID 变成了独立磁盘冗余阵列（Redundant Array of Independent Disks）。但这仅仅是名称的变化，实质内容并没有改变。

RAID 等级

• RAID 这种设计思想很快被业界接纳，RAID 技术作为高性能、高可靠的存储技术，得到了非常广泛的应用。RAID 主要利用镜像、数据条带和数据校验三种技术来获取高性能、可靠性、容错能力和扩展性，根据对这三种技术的使用策略和组合架构，可以把 RAID 分为不同的等级，以满足不同数据应用的需求。

• D.A.Patterson 教授等的论文中定义了 RAID0 ~ RAID6 原始 RAID 等级。随后存储厂商又不断推出 RAID7、RAID10、RAID01、RAID50、RAID53、RAID100 等 RAID 等级，但这些并无统一的标准。目前业界与学术界公认的标准是 RAID0 ~ RAID6，而在实际应用领域中使用最多的 RAID 等级是 RAID0、RAID1、RAID3、RAID5、RAID6 和 RAID10。

• RAID 每一个等级代表一种实现方法和技术，等级之间并无高低之分。在实际应用中，应当根据用户的数据特点，综合考虑可用性、性能和成本来选择合适的 RAID 等级，以及具体的实现方式。

RAID 分类

从实现角度来看，RAID 主要分为软 RAID、硬 RAID 以及混合 RAID 三种。

软 RAID

所有功能都是由操作系统和 CPU 来完成，没有独立的 RAID 控制处理芯片和 I/O 处理芯片，性能是最低的，但成本也是最低。

硬 RAID

配备了专门的 RAID 控制处理芯片和 I/O 处理芯片以及阵列缓冲，不占用 CPU 资源。性能是最高的，但成本也是最高。

混合 RAID

具备 RAID 控制处理芯片，但没有专门的 I/O 处理芯片，需要 CPU 和驱动程序来处理 I/O。性能和成本介于软 RAID 和硬 RAID 之间。

RAID 关键技术

镜像技术

• 镜像技术是一种冗余技术，为磁盘提供数据备份功能，防止磁盘发生故障而造成数据丢失。对于 RAID 而言，镜像技术最典型地的用法就是，同时在磁盘阵列中产生两个完全相同的数据副本，并且分布在两个不同的磁盘上。

• 镜像技术提供了完全的数据冗余能力，当一个数据副本失效不可用时，外部系统仍可正常访问另一副本，不会对应用系统运行和性能产生影响。而且，镜像不需要额外的计算和校验，故障修复非常快，直接复制即可。

• 镜像技术支持从多个副本并发读取以提升读性能；写入时会同时写入所有副本（支持并行写），但由于需要等待全部磁盘写入完成，写性能通常不会提升，反而可能略有下降，最终写入速度取决于写入最慢的那块磁盘。

• 镜像技术提供了非常高的数据安全性，其代价也是非常昂贵的，需要至少双倍的存储空间。高成本限制了镜像的广泛应用，主要应用于至关重要的数据保护，这种场合下的数据丢失可能会造成非常巨大的损失。

数据条带化技术

• 数据条带化技术是一种自动将 I/O 操作负载均衡到多个物理磁盘上的技术。更具体地说就是，将一块连续的数据分成很多小部分并把它们分别存储到不同磁盘上。这就能使多个进程可以并发访问数据的多个不同部分，从而获得最大程度上的 I/O 并行能力，极大地提升性能。

数据校验技术

• 数据校验技术是指 RAID 在写入数据的同时进行校验计算，并将得到的校验数据存储在 RAID 成员磁盘中。校验数据可以集中保存在某个磁盘或分散存储在多个不同磁盘中。当其中一部分数据出错时，就可以对剩余数据和校验数据进行反校验计算重建丢失的数据。

• 数据校验技术相对于镜像技术的优势在于节省大量存储开销，但由于每次数据读写都要进行大量的校验运算，对计算机的 CPU 运算速度要求很高，且必须使用硬件 RAID 控制器。在数据重建恢复方面，检验技术比镜像技术复杂得多且慢得多。

RAID 常见等级详解

JBOD

• JBOD（Just a Bunch of Disks，磁盘簇），表示一个没有控制软件提供协调控制的磁盘集合，这是 RAID 区别与 JBOD 的主要因素。JBOD 将多个物理磁盘串联起来，提供一个巨大的逻辑磁盘。
• JBOD 的数据存放机制是由第一块磁盘开始按顺序往后存储，当前磁盘的存储空间用完后，再依次往后面的磁盘存储数据。JBOD 存储性能完全等同于单块磁盘，而且也不提供数据安全保护。
• JBOD 本质上只是简单提供一种扩展存储空间的机制，JBOD 可用存储容量等于所有成员磁盘的存储空间之和。
• JBOD 通常是指磁盘柜，而不论其是否提供 RAID 功能。不过，JBOD 并非官方术语，官方称为 Spanning。

RAID0

• RAID0 是一种简单的、无数据校验的数据条带化技术。实际上不是一种真正的 RAID，因为它并不提供任何形式的冗余策略。RAID0 将所在磁盘条带化后组成大容量的存储空间，将数据分散存储在所有磁盘中，以独立访问方式实现多块磁盘的并读访问。

• 一个由 N 块磁盘组成的 RAID0，它的理论读写性能是单个磁盘性能的 N 倍，但由于总线带宽等多种因素的限制，实际的性能提升低于理论值。

• 由于 RAID0 可以并发执行 I/O 操作，总线带宽得到充分利用，并且不需要进行数据校验，因此 RAID0 的性能在所有 RAID 等级中是最高的。

• RAID0 具有低成本、高读写性能、100% 的高存储空间利用率等优点，但是它不提供数据冗余保护，一旦磁盘损坏，将无法恢复数据。

• RAID0 的适用场景：

  • 对数据的顺序读写速度要求不高，对数据的安全性和可靠性要求不高，但对系统性能要求很高的场景，比如：
  • 视频剪辑 / 渲染缓存（临时素材处理，追求高读写速度）
  • 游戏加载盘（加快加载速度，对数据丢失不敏感）
  • 缓存服务器（如临时缓存、CDN 缓存数据）
  • 大数据 / 科学计算临时数据盘（中间结果可丢失）

• RAID0 与 JBOD 相同点：

  • 存储容量：都是成员磁盘容量总和
  • 磁盘利用率都是 100%，即都没有做任何的数据冗余备份

• RAID0 与 JBOD 不同点：

  • JBOD：数据是顺序存放的，一个磁盘存满后才会开始存放到下一个磁盘
  • RAID0：通过数据条带技术将数据分布到多个磁盘，实现并行读写，在理想情况下其读写性能可接近单盘的 N 倍（N 为磁盘数量），但实际性能会受到硬件和访问模式等因素影响

RAID1

• RAID1 是一种镜像技术，它将数据完全一致地分别写到工作磁盘和镜像磁盘，它的磁盘空间利用率为 50%。

• RAID1 支持从多个副本并发读取以提升读性能，写入时会同时写入所有副本（支持并行写），但由于需要等待全部磁盘写入完成，写性能通常不会提升，反而可能略有下降。

• RAID1 提供了最佳的数据保护，一旦工作磁盘发生故障，系统将自动切换到镜像磁盘，不会影响使用。

• RAID1 是为了增强数据安全性使两块磁盘数据呈现完全镜像，从而达到安全性好、技术简单、管理方便。RAID1 拥有完全容错的能力，但实现成本高。

• RAID1 的适用场景：

  • 对顺序读写性能要求较高，或对数据安全性要求较高的场景，比如：
  • 数据库服务器（如订单、用户数据，要求高可靠性）
  • 金融交易系统（不允许丢失数据）
  • 企业文件服务器 / NAS（重要文件存储）
  • 操作系统盘（保证系统不因磁盘损坏而宕机）

RAID10

• RAID10 是一个 RAID1 与 RAID0 的组合体，所以它继承了 RAID1 的高安全性和 RAID0 的高性能。

• RAID10 是先进行数据镜像（RAID1），再在多个镜像组之间进行数据条带化（RAID0），即先保证数据冗余，再提升读写性能。

RAID01

• RAID01 是一个 RAID0 与 RAID1 的组合体，所以它继承了 RAID0 的高性能和 RAID1 的高安全性。

• RAID01 是先进行数据条带化（RAID0），再对条带后的数据整体做镜像（RAID1），即先提升读写性能，再保证数据冗余。

• RAID01 的可靠性低于 RAID10，一旦某个条带组中的一块磁盘损坏，整个条带组都会失效，从而使磁盘阵列退化为单一镜像组，容错能力较弱。

参考资料

• RAID 技术全解图解
• RAID 磁盘阵列是什么

TCP 连接，一端断电和进程崩溃有什么区别

问题剖析

TCP 连接，没有打开 Keepalive 选项，没有数据交互，现在一端突然断电或者一端的进程崩溃了，这两种情况有什么区别呢？这是腾讯的一道面试题，其中有几个关键词：

• TCP 连接没有开启 Keepalive；
• 一直没有数据交互；
• 进程崩溃；
• 主机宕机；

什么是 TCP Keepalive

TCP Keepalive 其实就是 TCP 的保活机制，它的工作原理如下：

如果两端的 TCP 连接一直没有数据交互，达到了触发 TCP 保活机制的条件，那么系统内核里的 TCP 协议栈就会发送探测报文。

• 如果对端程序是正常工作的。当 TCP 保活的探测报文发送给对端，对端会正常响应，这样 TCP 保活时间会被重置，等待下一个 TCP 保活时间的到来。
• 如果对端主机宕机，或对端由于其他原因导致报文不可达。当 TCP 保活的探测报文发送给对端后，石沉大海，没有响应，连续几次，达到保活探测次数后，TCP 会报告该 TCP 连接已经消亡。

所以，TCP 保活机制可以在双方没有数据交互的情况，通过探测报文，来确定对方的 TCP 连接是否存活。
注意，应用程序若想使用 TCP 保活机制需要通过 Socket 接口设置 SO_KEEPALIVE 选项才能够生效，如果没有设置，那么就无法使用 TCP 保活机制。

主机宕机

在没有开启 TCP Keepalive，且双方一直没有数据交互的情况下，如果客户端的「主机宕机」了，会发生什么？

客户端主机宕机了，服务端是无法感知到的，再加上服务端没有开启 TCP Keepalive，又没有数据交互的情况下，服务端的 TCP 连接将会一直处于 ESTABLISHED 连接状态，直到服务端重启进程。

所以，这里可以得知一个点，在没有使用 TCP 保活机制且双方不传输数据的情况下，一方的 TCP 连接处在 ESTABLISHED 状态，并不代表另一方的连接还一定正常。

进程崩溃

在没有开启 TCP Keepalive，且双方一直没有数据交互的情况下，如果服务端的「进程崩溃」了，会发生什么？

TCP 的连接信息是由系统内核维护的，所以当服务端的进程崩溃后，系统内核需要回收该进程的所有 TCP 连接资源，于是系统内核会发送第一次挥手 FIN 报文，后续的挥手过程也都是在系统内核完成，并不需要进程参与，所以即使服务端的进程退出了，还是能与客户端完成 TCP 四次挥手的过程。

这里可以尝试做实验，使用 kill -9 来模拟服务端进程崩溃的情况，发现在 kill 掉进程后，服务端会发送 FIN 报文，与客户端进行四次挥手。

所以，即使没有开启 TCP Keepalive，且双方也没有数据交互的情况下，如果任意一方的进程发生了崩溃，这个过程系统内核是可以感知的到的，于是系统内核就会发送 FIN 报文给对方，然后与对方进行 TCP 四次挥手。

有数据传输的场景

以上就是对这道面试题的回答，接下来我们看看在「有数据传输」的场景下的一些异常情况：

第一种，客户端主机宕机，又迅速重启，会发生什么？
第二种，客户端主机宕机，一直没有重启，会发生什么？

假设客户端主机宕机，又迅速重启，会发生什么？

在客户端主机宕机后，服务端向客户端发送的报文会得不到任何的响应，在一定时长后，服务端就会触发超时重传机制，重传未得到响应的报文给客户端。

在服务端重传报文的过程中，客户端主机重启完成后，客户端的内核就会接收重传的报文，然后根据报文的信息传递给对应的进程：

• 如果客户端主机上没有进程绑定该 TCP 报文的目标端口号，那么客户端内核就会回复 RST 报文，重置该 TCP 连接；
• 如果客户端主机上有进程绑定该 TCP 报文的目标端口号，由于客户端主机重启后，之前的 TCP 连接的数据结构已经丢失了，客户端内核里协议栈会发现找不到该 TCP 连接的 Socket 结构体，于是就会回复 RST 报文，重置该 TCP 连接。

所以，只要有任意一方的主机重启完成后，收到之前 TCP 连接的报文，都会回复 RST 报文给对端，以断开连接。

假设客户端主机宕机，一直没有重启，会发生什么？

这种情况，服务端超时重传报文的次数达到一定阈值后，系统内核就会判定出该 TCP 有问题，然后通过 Socket 接口告诉应用程序该 TCP 连接出问题了，于是服务端的 TCP 连接就会断开。

那 TCP 的数据报文具体重传几次呢？在 Linux 系统中，提供一个叫 tcp_retries2 配置项（cat /proc/sys/net/ipv4/tcp_retries2），默认值是 15；这个内核参数是控制在 TCP 连接建立的情况下，超时重传的最大次数。

不过 tcp_retries2 设置了 15 次，并不代表 TCP 超时重传了 15 次才会通知应用程序终止该 TCP 连接，内核会根据 tcp_retries2 设置的值，计算出一个 timeout（如果 tcp_retries2 = 15，那么计算得到的 timeout = 924600ms），如果重传间隔超过这个 timeout，则认为超过了阈值，就会停止重传，然后就会断开 TCP 连接。

在发生超时重传的过程中，每一轮的超时时间（RTO）都是倍数增长的，比如：如果第一轮 RTO 是 200 毫秒，那么第二轮 RTO 是 400 毫秒，第三轮 RTO 是 800 毫秒，以此类推。

而 RTO 是基于 RTT（一个包的往返时间）来计算的，如果 RTT 较大，那么计算出来的 RTO 就越大，那么经过几轮重传后，很快就达到了上面的 timeout 阀值了。

举个例子，如果 tcp_retries2 = 15，那么计算得到的 timeout = 924600ms，如果重传总间隔时长超过了 924600ms 就会停止重传，然后就会断开 TCP 连接：

• 如果 RTT 比较小，那么 RTO 初始值就约等于下限 200ms，也就是第一轮的超时时间是 200 毫秒，由于 timeout 总时长是 924600ms，表现出来的现象刚好就是重传了 15 次，超过了 timeout 值，从而断开 TCP 连接
• 如果 RTT 比较大，假设 RTO 初始值计算得到的是 1000ms，也就是第一轮的超时时间是 1 秒，那么根本不需要重传 15 次，重传总间隔时长就会超过 924600ms。

最小 RTO 和最大 RTO 已经是在 Linux 内核中定义好了：

1
2

#define TCP_RTO_MAX ((unsigned)(120*HZ))
#define TCP_RTO_MIN ((unsigned)(HZ/5))

Linux 2.6+ 使用 1000 毫秒的 HZ，因此 TCP_RTO_MIN 约为 200 毫秒，TCP_RTO_MAX 约为 120 秒。

如果 tcp_retries 设置为 15，且 RTT 比较小，那么 RTO 初始值就约等于下限 200ms，这意味着它需要 924.6 秒才会将断开的 TCP 连接并通知给上层（即应用程序），每一轮的 RTO 增长关系如下表格：

总结

如果「客户端进程崩溃」，客户端的进程在发生崩溃的时候，内核会发送 FIN 报文，与服务端进行四次挥手，以此断开 TCP 连接。

如果「客户端主机宕机」，那么是不会发生四次挥手的，具体后续会发生什么，还要看服务端会不会发送数据。

• 如果服务端会发送数据，由于客户端已经不存在，收不到数据报文的响应报文，服务端的数据报文会超时重传，当重传总间隔时长达到一定阈值（内核会根据 tcp_retries2 设置的值计算出一个阈值）后，会断开 TCP 连接；
• 如果服务端一直不会发送数据，再看服务端有没有开启 TCP Keepalive 机制？
  • 如果服务端有开启 TCP Keepalive 机制，服务端在一段时间没有进行数据交互时，会触发 TCP Keepalive 机制，探测对方是否存在，如果探测到对方已经消亡，则会断开自身的 TCP 连接；
  • 如果服务端没有开启 TCP Keep 机制，服务端的 TCP 连接会一直存在，并且一直保持在 ESTABLISHED 状态。

前言

由于人工智能（AI）发展迅速、日新月异，文中所列 AI 编程工具排行榜仅供参考，具有一定时效性，可能会随时间变化而失去准确性。截止 2026 年，AI 编程工具已经从早期单纯的 “代码补全工具”（只能基于上下文提示补几行或者一段代码），演进为具备更强自主能力的 AI Agent。这类 AI Agent 不仅能够理解需求，还可以自动完成从方案设计、代码编写、调试测试到迭代优化的一整套开发流程，甚至可以调用工具链、运行代码并根据结果进行自我修正。换句话说，AI 正在从 “辅助写代码” 转变为 “参与甚至主导功能开发” 的角色，极大提升了开发效率，也正在重塑软件工程的工作方式。

AI 编程工具的三种形态

全球 Top 6 AI 编程工具

Claude Code（Anthropic）

最强 “AI 程序员” 本体（Agent 级别）

• 综合能力：
  • 目前在多项编程与 Agent 评测中排名第一梯队
  • 可独立完成复杂软件开发任务
• 特点：
  • 直接 “接管任务”：能够自动写功能、改代码、跑测试
  • 支持超大上下文（10 万 + 行代码）
  • 多文件重构能力非常强
  • 本质：不是辅助，而是 “替你干活”
  • 更偏 “系统级开发 Agent” ，而不是代码补全工具
• 优点：
  • 极强的任务执行能力（从需求到代码闭环）
  • 复杂逻辑推理能力强，适合架构级问题
  • 多文件协同修改能力领先
  • 对工程任务自动化支持很强
• 缺点：
  • 对 UI / 产品体验类任务不如 Replit AI 直观
  • 对任务描述质量要求较高（需要清晰拆解）
  • 使用成本相对较高（学习 Agent 工作方式）
• 适合：
  • 架构设计
  • 大型项目重构
  • AI Agent 开发
  • 复杂工程任务自动化

Codex（OpenAI）

最强 “AI 软件工程 Agent”（云端并行开发系统）

• 综合能力：
  • 面向真实工程任务的 AI 编程 Agent
  • 可并行处理多个开发任务（PR / Feature / Bug Fix）
  • 在复杂代码库中表现稳定（跨任务 PR 通过率较高）
• 特点：
  • 云端沙盒执行：在独立环境中写代码、跑测试、提交 PR
  • 支持多 Agent 并行工作（Worktree / 多线程任务）
  • 可自动完成：功能开发 / Bug 修复 / 代码迁移 / 重构
  • 内置测试驱动执行（会跑测试直到通过）
  • 面向 “端到端软件交付”，而不是单次代码生成
  • 已支持 IDE / CLI / 云端多入口使用
  • 可在后台自动执行长期工程任务
• 优点：
  • 工程执行能力极强（可直接产出可合并 PR）
  • 支持大规模代码库任务拆解与并行处理
  • 自动化程度高，可持续运行在后台
  • 非常适合真实团队开发流程（Git Workflow 友好）
• 缺点：
  • 对非结构化需求（创意 / 产品想法）不如 Replit AI 直接
  • 需要较规范的代码仓库结构才能发挥最佳效果
  • 更偏工程协作，不适合 “零基础快速做 Demo”
  • 对任务拆解能力要求较高
• 适合：
  • 大型软件项目开发
  • 工程级重构 / 迁移 / Bug 修复
  • 团队并行开发（多任务 PR 管理）
  • AI 驱动的软件工程自动化
  • 复杂后端 / 系统级项目维护

Cursor（AI 原生 IDE）

最强 AI 原生 IDE（开发者体验天花板）

• 综合排名：
  • 常年排名 Top 1 ~ 2（AI IDE 领域）
• 综合能力：
  • 基于 VSCode 深度重构的 AI IDE
  • AI 深度融入编辑器，而不是插件形式
  • 支持全代码库理解与跨文件编辑
  • 内置多模型能力（Claude Code / GPT / Gemini 等）
• 特点：
  • 支持 Agent 模式（自动改代码 + 重构 + 任务执行）
  • 预测 “下一步修改”（不仅是单行补全）
  • 可理解整个项目结构
  • 支持多文件级别编辑与系统性重构
  • IDE + AI 深度融合，交互体验非常流畅
• 优点：
  • 项目理解能力强（比 Copilot 更深入）
  • 开发体验极佳（接近 “AI 操作 IDE” ）
  • 非常适合全栈开发与高频编码场景
  • 对中小型项目效率提升非常明显
• 缺点：
  • 对超大规模工程（百万行级）不如 Windsurf
  • 自动执行复杂工程任务能力不如 AI Agent（如 Claude Code / Codex）
  • 企业级权限与合规能力相对较弱
• 适合：
  • 日常开发主力工具
  • 独立开发者 / 一人公司
  • 全栈工程师
  • 中小型项目开发
  • 高效率迭代型开发场景

GitHub Copilot（编程助手）

最普及、最稳定的 AI 编程助手

• 使用率：
  • 市场使用率全球第一（行业标准工具）
• 功能：
  • 代码补全
  • 代码生成
  • 代码重构
  • 代码解释
• 特点：
  • 最强 IDE 兼容性（VSCode / JetBrains / Neovim）
  • GitHub 全流程集成（PR、CI、代码评审）
  • 自动补全速度最快
  • 学习成本最低，上手最快
• 优点：
  • 稳定可靠，企业接受度最高
  • 集成生态完善（GitHub 工作流）
  • 响应速度快
• 缺点：
  • 上下文理解能力不如 Claude Code / Cursor
  • 更偏 “代码补全型工具”，而非任务型 Agent
• 适合：
  • 企业开发
  • 多语言项目
  • 稳定优先
  • 代码补全为主的开发场景

Windsurf（超大代码库）

超大代码库处理王者

• 特点：
  • 支持 “百万行代码级别” 理解
  • 面向大型工程与团队协作设计
  • 多模型支持（Claude Code / GPT 等）
  • 强调代码库级别的理解与改造能力
• 优点：
  • 超大仓库理解能力强
  • 更偏工程级（系统维护能力强）
  • 适合复杂代码重构
• 缺点：
  • 学习成本略高
  • 产品体验不如 Cursor 轻量直观
• 适合：
  • 大厂项目
  • 微服务 / 单体巨型仓库
  • 团队协作开发
  • 超大规模工程维护

Replit AI（云端开发）

零环境（在线 IDE） + AI 自动生成项目

• 特点：
  • 浏览器内直接开发，无需本地环境配置（零环境）
  • 内置在线 IDE，支持实时编写、运行和调试代码
  • 一句话生成完整项目（类似 Bolt / V0）
  • AI 自动完成依赖安装、构建与部署
  • 提供从开发 → 运行 → 发布的一体化云端流程
  • 集成 AI Agent，可自动生成完整应用（前端 + 后端 + 数据库）
• 优点：
  • 极快完成 MVP（从想法到上线仅需几分钟）
  • 大幅降低开发门槛（无需环境配置和运维）
  • 适合快速试错与产品验证
  • 全流程（开发 + 运行 + 部署一体化）在线完成，只需浏览器
• 缺点：
  • 不适合大型复杂工程长期维护
  • 自定义底层能力较弱（受平台限制）
  • AI 生成项目在复杂场景下可控性一般
• 适合：
  • 初学者（无需复杂环境即可上手）
  • 快速原型开发（Prototype / Demo）
  • SaaS / Web 小型项目快速上线
  • 独立开发者 / 副业项目 / 验证想法

国内 Top 4 AI 编程工具

通义灵码（阿里）

国内最主流的 AI 编程助手（企业级使用率最高）

• 产品形态：
  • 通义灵码插件（当前主力）
    • 写代码助手
    • 类似 GitHub Copilot
  • 通义灵码 AI IDE（新一代形态）
    • 自带 Agent 能力
    • 类似 Cursor
  • Qwen Code（独立 Agent 工具链）
    • 真正执行任务的 AI Agent
    • 类似 Codex
• 综合能力：
  • 基于 Qwen 编码模型（Qwen-Coder 系列）
  • 深度集成 VSCode / JetBrains / IDEA
  • 支持代码补全、生成、解释、单测生成
• 特点：
  • 中文理解能力强（需求转代码能力优秀）
  • 企业内部代码库适配能力较好
  • 支持私有化部署（大厂常用）
  • 与阿里云生态（IDE / DevOps）结合紧密
• 优点：
  • 中文场景体验最好（需求理解准确）
  • 企业级稳定性强
  • 对 Java / 后端工程支持非常成熟
  • 适合团队统一接入
• 缺点：
  • Agent 能力相对 Claude Code / Cursor 偏弱
  • 超大代码库理解能力一般
  • 创意型开发能力不强
• 适合：
  • 企业后端开发（Java / Go）
  • 国内互联网公司团队开发
  • 规范化工程项目
  • 内部系统开发

Trae（字节跳动）

面向未来 AI Agent 编程方向的 IDE（成长最快）

• 产品形态：

  • MarsCode 插件（早期阶段）
    • 写代码助手
    • 类似 GitHub Copilot
  • Trae AI IDE（最新阶段）
    • 独立 AI 原生 IDE（开发环境）
    • 类似 Cursor / Windsurf

• 综合能力：

  • 字节自研 AI IDE + 编程 Agent 系统
  • 支持自动生成项目 + 修改代码 + 调试
  • 与云开发环境结合

• 特点：

  • 强调 AI Agent 自动开发能力
  • 支持从需求到项目生成
  • 与字节内部工程体系类似（Monorepo 友好）
  • 持续强化多文件重构能力

• 优点：

  • AI Agent 方向发展最快之一
  • 对前端 / 全栈项目非常友好
  • 自动生成项目能力强

• 缺点：

  • 生态仍在快速演进阶段
  • 稳定性不如 Cursor / Copilot
  • 企业级成熟度较低

• 适合：

  • 前端开发
  • 快速原型开发
  • AI 驱动产品团队
  • 探索型开发者

CodeBuddy（腾讯）

国内新一代企业级 AI 编程平台

• 综合能力：
  • 腾讯 + 混元模型 + 工程平台结合
  • 支持代码生成、Review、测试生成
  • 深度集成腾讯内部研发体系
• 特点：
  • 面向企业研发流程（DevOps 一体化）
  • 支持代码审查（AI Review）
  • 与腾讯 CI/CD 强绑定
  • 强调研发规范与工程质量
• 优点：
  • 企业级流程支持完善
  • 适合大型研发组织
  • 安全与权限体系成熟
• 缺点：
  • IDE 体验不如 Cursor
  • 创作型开发能力一般
  • 对个人开发者吸引力较弱
• 适合：
  • 大型企业研发团队
  • 金融 / 通信 / 政企系统
  • 强流程规范开发

文心快码（百度）

偏向工程补全 + 企业研发工具型 AI 编程助手

• 综合能力：
  • 基于文心大模型（ERNIE Code）
  • 支持代码补全、生成、修复
  • 与百度智能云开发体系集成
• 特点：
  • 强代码补全能力（类似 Copilot）
  • 支持多语言开发（Java / Python / JS）
  • 企业内部代码场景适配
  • 支持安全审计与代码规范检查
• 优点：
  • 稳定可靠（偏传统工程工具）
  • 在企业内网环境适配较好
  • 适合规范开发流程
• 缺点：
  • Agent 能力较弱
  • IDE 体验一般
  • 不适合复杂系统级开发
• 适合：
  • 企业后端开发
  • 传统研发团队
  • 代码规范要求较高的项目

国内 AI 编程工具的产品形态

通义灵码（阿里）

阿里的通义灵码有三种产品形态，本质是 “三层进化路线”，从插件工具 → AI IDE（开发环境） → AI Agent 执行系统。

• 通义灵码插件（当前主力）

  • 产品形态：
    • VSCode / JetBrains 插件
  • 能力特点：
    • 代码补全
    • 基础代码生成与修复
    • IDE 内增强辅助能力
    • AI 问答（解释代码 / 调试代码）
  • 产品定位：
    • AI 辅助写代码工具
    • 类似 GitHub Copilot

• 通义灵码 AI IDE（新一代形态）

  • 产品形态：
    • 基于 VSCode / JetBrains 深度改造的 AI IDE
    • 或独立 AI IDE 客户端
  • 能力特点：
    • 内置 AI Agent
    • 支持跨文件修改
    • 支持任务式编程
    • 可理解整个项目结构
    • 支持 “需求 → 功能实现” 流程
  • 定位：
    • 类似 Cursor / Windsurf
  • 核心变化：
    • AI 参与开发流程，而不是只辅助编码
    • 从 “写代码工具” 逐渐发展为 “任务执行型开发系统”

• Qwen Code（独立 Agent 工具链）

  • 产品形态：
    • CLI / 命令行 Agent
    • 可以脱离 IDE 独立运行
    • 更偏向自动化执行系统
  • 能力特点：
    • 修改代码文件
    • 执行 Shell 命令
    • 运行测试与任务流程
    • 可用于自动化工程操作
  • 定位：
    • 类似 Codex
  • 核心变化：
    • 真正执行任务的 AI Agent

• 通义灵码三种产品形态的关系

  • 通义灵码（插件）
    • 写代码助手
    • AI 辅助写代码（GitHub Copilot 模式）
  • 通义灵码 AI IDE
    • AI 开发环境
    • AI 主导开发（Cursor 模式）
  • Qwen Code
    • AI 执行引擎
    • AI 执行任务（Agent / CLI 模式）

Trae（字节跳动）

• MarsCode（早期插件阶段）

  • 产品形态：
    • VSCode / JetBrains 插件
  • 核心功能：
    • 代码补全
    • 代码生成
    • Bug 修复建议
  • 能力特点：
    • 以辅助编码为主
    • 基于上下文的局部代码理解
  • 定位：
    • 类似 GitHub Copilot
  • 核心模式：
    • 人主导，AI 辅助

• Trae（最新 AI IDE 阶段）

  • 产品形态：
    • 独立 AI 原生 IDE（开发环境）
  • 核心功能：
    • 全项目代码理解
    • 多文件级别修改与重构
    • AI Agent 自动写功能
    • Builder 模式（需求 → 项目生成）
  • 能力特点：
    • 支持任务级编程
    • 可进行跨文件、跨模块的系统性改造
    • 更接近 “AI 参与完整开发流程”
  • 定位：
    • 类似 Cursor / Windsurf
  • 核心模式：
    • AI 主导，人类协作

大纲

• 电⼦元器件零基础⼊⻔教程之一
• 电⼦元器件零基础⼊⻔教程之二

常见电子元器件

大纲

• 电⼦元器件零基础⼊⻔教程之一
• 电⼦元器件零基础⼊⻔教程之二

前序知识

这里先了解⼀些原⼦相关的知识 ，会对电学中很多的概念和结论有更好的理解。

原子（Atomic）

• 原⼦是构成物质的最⼩单位，它由原⼦核和电⼦组成，其中原⼦核又由质⼦和中⼦组成。

• 下图为碳原⼦的简易模型图：

质⼦（Proton）

• 质⼦带⼀个单位的正电荷，且质⼦数量决定着元素身份，改变了质⼦数量，也就改变了原⼦的类型。
• 举个例⼦：如果能从铅的原⼦核（82 个质子）⾥移出 3 个质⼦，那就成功的⽤铅原⼦造出了⼀个⾦原⼦（79 个质子）。
• ⽽实际上：质⼦之间结合地⾮常紧密，⼏乎⽆法分开，这也是炼⾦术未能实现的原因。
• 拓展内容：现代物理学中的核反应堆、粒⼦加速器等可以实现上述过程，但所需能量和成本⾮常⾼，已经远超⻩⾦的价值了，⽽且这种反应通常很难精确控制，产出的黄⾦量可能很少。

中⼦（Neutron）

• 中⼦不带电，且中⼦对原⼦的影响远⼩于质⼦。
• 电学领域通常不对中⼦进⾏深⼊探讨，因为它不带电荷，不直接影响电势、电流的形成。

电⼦（Electron）

• 电⼦带⼀个单位的负电荷，它围绕原⼦核做⽆规则的运动。
  • 早期的『波尔模型』，将电⼦的运动⽐作成⾏星的 “轨道运动”；
  • 但随着量⼦⼒学的发展，这种⽐喻并不完全正确，所谓的 “轨道” 其实是电⼦出现的概率区域，并不不是⼀个具体的路径。
• 通常来说原⼦的质⼦数和电⼦数相等，其内部的正电荷与负电荷互相抵消，这时候原⼦呈电中性。

• 电⼦层：电⼦围绕原⼦核活动的范围。

• 最外层电⼦数为 8 个时，通常是较稳定的状态。

  • 许多元素在化学反应中，会倾向于通过：获得电⼦、失去电⼦、共享电⼦，来尽可能达到 8 个电⼦的稳定结构，这个现象被称为：⼋隅规则。
  • 当然也有⼀些例外的元素，例如：氢 (H) 、氦 (He) 只需要 2 个电⼦就能达到稳定状态。

• 不同电荷之间互相吸引，相同电荷之间互相排斥，具体计算参考库伦定律：

• 最外层的电⼦更容易脱离原⼦，因为它们与原⼦核的距离较远，受到的引⼒较弱。

⽯墨与⾦刚⽯

• ⽯墨：每个碳原⼦与周边 3 个碳原⼦分别建⽴共价键，最终外层剩余 1 个 未成键的电⼦，这个电⼦可以在不同的原⼦之间⾃由移动，所以⽯墨是导体。
• ⽯墨的层与层之间是靠『范德华⼒』结合在⼀起的，范德华⼒是⼀种弱的分⼦间作⽤⼒，因此⽯墨的各个层之间可以很容易地滑动，所以⽯墨可以作为：润滑剂、铅笔芯等。

• ⾦刚⽯：每个碳原⼦与周边 4 个 碳原⼦分别建⽴共价键，形成⼀个⾮常坚硬的⽴体⽹状结构，没有⾃由电⼦，所以⾦刚⽯是绝缘体。
• ⾦刚⽯的碳原⼦之间共价键内的电⼦活动范围相对较⼩，且共价键内的电⼦被两个原⼦核共同吸引，所以碳原⼦之间共价键内的电⼦相对稳定，不会轻易脱落，除⾮有⾜够的能量来打破这个键。

电学基础

电场、电势、电势能

为了能更好的理解⼀些抽象的概念，这里⽤重⼒场中的相关概念，去类⽐电场中的相关概念。

重⼒场、电场

• 重⼒场：在地球周围存在，有质量的物体进⼊该区域后，会受到被拉向中⼼的⼒。
• 电场：在电荷周围存在，带电的粒⼦进⼊这个区域后，会受到吸引⼒或排斥⼒。
  • 沿着电场线⽅向，电场的强度会逐渐减弱，且⽆论正电荷还是负电荷，⽆穷远处的电场强度为 0。

重⼒势能、电势能

• 重⼒势能：描述物体在重⼒场中所具备的能量，与所处位置、物体质量均有关。
• 电势能：描述带电粒⼦在电场中所具备的能量，与所处位置、粒⼦带电量均有关。

重⼒势、电势

电流

• 电流的概念：

  • 电荷的定向移动，形成了电流，衡量电流的⼤⼩，要看单位时间内通过导体横截⾯的电荷量。
  • 注意：
    • 电学上定义的『电流⽅向』是正电荷的流动的⽅向，这个概念在 19 世纪初就先被定电学上定义的『电流⽅向』是正电荷的流动的⽅向，这个概念在 19 世纪初就先被定义了；
    • 后来虽然发现了是电⼦在移动，但为了保持定义的统⼀性，『电流⽅向』仍然⽤正电荷的流动去定义，所以『电流⽅向』与『电⼦移动⽅向』是相反的。

• 电流的单位：安培 (A)，简称安

  • 1A 的含义：1 秒钟内有 6.242*10^18 个单位电荷（电⼦、质⼦、都属于单位电荷）通过了导体横截⾯。
  • 6.242*10^18 个单位电荷所带的电荷总量，为 1 库伦 (C)，所以 1A 的含义也能这样描述：在 1 秒钟内，有 1 库仑的电荷通过了导体的横截⾯。

• 电流的单位换算：

  • 进位为 1000，例如 1A = 1000mA
  • 常⽤的单位是：安 (A)、毫安 (mA)
    

• 常⻅电器的⼯作电流：
  

电压

• 电压的概念：

  • ⼜称电势差，是两点之间电势的差值，衡量电压的⼤⼩，要看两点电势差的⼤⼩。
  • 有了电压，电子才能持续且定向地移动起来，所以电压是形成电流的必要条件之一。
  • 电压越大，能定向移动起来的电子就越多，电流就会越大。

• 电压的单位：伏特 (V)，简称伏

  • 1V 的含义是：电场 对 1 库伦 (C) 电荷做了 1 焦⽿ (J) 的功。
    

• 电压的单位换算：

  • 进位为 1000，例如 1kV = 1000V
    

• 常⻅电源的电压：
  

电阻

• 电阻的概念：

  • 电阻是指材料或元器件对电流流动的阻碍程度。
  • 电阻的大小不仅与材料有关，还与材料的粗细、长短等因素有关。

• 电阻的单位：欧姆（简称欧），符号是 Ω。

  • 1Ω 的含义：给导体施加 1V 电压，此时如果导体的电流为 1A，那这个导体的电阻就是 1Ω。

• 电阻的单位换算：

  • 进位为 1000，例如 1KΩ = 1000Ω
    

• 电阻的决定式：

  • $R = \rho \cdot \frac{L}{A}$
    • R：电阻
    • L：导体的⻓度
    • A：导体的横截⾯积
    • ρ：材料的电阻率，表示材料对电流的阻碍能⼒

• 电阻的补充内容：

  • 后续会讲解⼀种电⼦元器件 — 『电阻器』，它的简称也叫『电阻』，是⼀种专⻔⽤于控制电流大小的电⼦元器件（如下图所示），其的作⽤是：为电路提供电阻，来限制电流的⼤⼩。
    

电路

• 电源：物理学中将提供电能的装置叫做电源。
• ⽤电器：将灯泡、电动机、等这类消耗电能的装置叫做⽤电器。
• 电路：电源、⽤电器，再加上导线、开关等，就组成了电流可以流过的路径，这就是电路。

• 电路图：

  • 在绘制电路图时，为了绘制简单且⽅便研究，通常⽤图形符号来表示元件。
  • 此处先只列举了三个电路符号（如下图所示），其他的电路符号以后会随着教程讲解。
    

• 电路状态：

  • 断路：电路中某处被切断，电路中没有电流流过。
  • 通路：正常接通的电路，⽤电器能够正常⼯作的电路。
  • 短路：比如直接⽤导线将电源的正、负极连接起来（⚠️危险操作）。
    

欧姆定律

• 概念：

  • 导体中的电流，与导体两端的电压成正⽐，与导体的电阻成反⽐。
  • 在电阻不变的情况下，电压越⼤，电流也会越⼤。

• 公式：

  • $I = \frac{U}{R}$
    • U 为电压，单位为 V
    • I 为电流，单位为 A
    • R 为电阻，单位为 Ω
  • 变形公式一：
    • $R = \frac{U}{I}$
  • 变形公式二：
    • $U = IR$

• 决定式 vs 定义式：
  

• 使⽤场景：
  

• 局限性：

  • 欧姆定律有局限性，仅适用于纯电阻电路（或者说纯电阻元器件、纯电阻设备）！
  • 纯电阻电路：消耗的电能仅转化为热能，没有其他形式的能量转换。

直流电 VS 交流电

直流电

• 定义：

  • 有固定的正负极，且电流⽅向始终『不变』的电流，全称：Direct Current，简称 DC。

• 举例：

  • ⼲电池、锂电池、光伏发电板等。
    

交流电

• 定义：

  • 电流⽅向随时间做『周期性变化』的电流，全称：Alternating Current，简称 AC。
  • 交流电的电流⽅向⼀定做周期性变化，但电流⼤⼩不⼀定做周期性变化！

• 举例：

  • 家庭⽤电
    

扩展内容

家庭⽤电为的 220V / 50Hz 的正弦交流电，下⾯是关于家⽤交流电的⼀些总结性内容。

• 周期：

  • 交流电完成⼀个完整波动循环所需的时间（参考下图）。
    

• 零线与⽕线：

  • 交流电⽆正负极之分，但有零⽕线之分。
  • 零线的电势始终为 0，⽕线的电势不断变化，有时⾼于 0，有时低于 0，这样就形成了交变电流。

• 对于 220V / 50Hz 的理解：

  • 220V 指的是交流电的有效电压
    • 什么是有效电压？—— 让交流电和直流电，分别通过同⼀个电阻，在交流电的⼀个周期内，若⼆者产⽣的热量相等，那么这个直流电的电压，就是交流电的有效电压。
    • 我们平时聊天所说到的、⽤电器说明书上写的、电表所测到的，都是有效电压，即：220V。家庭用电的 220V 指的是交流电的有效电压。
    • 什么是峰值电压？—— 交流电在⼀个周期中达到的最⼤电压值，220V 交流电的峰值电压为：$200\sqrt {2}$，约为：311V，如图所示。
  • 50hz 指的是交流电的频率
    • 50hz 的含义是交流电在 1 秒钟内完成了 50 个周期（每个周期包含两次电流⽅向变化，所以对于 50Hz 的交流电来说，1 秒钟内电流的⽅向变化了 100 次）。

• 整流与逆变：

  • 什么是整流？—— 交流（AC） → 直流（DC）
  • 什么是逆变？—— 直流（DC） → 交流（AC）
  • 在⽣活中很多的电器，都是将交流转换成直流后⼯作的（参考下图），例如：电脑、⼿机、路由器等，因为直流电更加稳定，适合精密电路。
    

弱电与强电

• 弱电：

  • 弱电的电压⼀般较低，⾏业规定安全电压为不⾼于 36V。
  • 弱电通常⽤于直流电路（3.3V、5V、12V），弱电也能于信号传递，例如：⾳频和视频线路、⽹络线路、电话线等（参考下图）。
    

• 强电：

  • 强电的电压⼀般很⾼，对人体危害较大，必须采取防护措施，例如：220V 的家⽤电、1000V 及以上的⾼压电。
  • 强电常⽤于能源传输或者高功率供电（参考下图）。
    

• 通过人体电流的大小，直接决定了电击的危险性：

  • 感知电流：能引起人感觉的最小电流，约 0.7mA ~ 1.1mA 左右，有很轻微的刺痛感，但不会造成伤害。
  • 摆脱电流：能自主摆脱的最大电流，约 10mA ~ 16mA 左右，会有明显的肌肉收缩，不要持续接触。
  • 致命电流：能在短时间内危及生命的最小电流，约为 50mA 左右，明显的呼吸困难、心脏产生室颤。

家庭电路

本节属于电⼯学内容，但也属于电学相关的常识性内容，不必深究，了解⼀下就可以。

• 家庭电路中的『保护接地』，是如何保护我们的？
  • (1) 发电⼚系统会通过⼀个接地点，将零线连接到⼤地，这是电⼒系统中⼀个重要的设计， 其⽬的是：
    • 保证电压稳定：将零线电压锁定为地电位（0V）。
    • 提供保护：在发⽣故障时，接地可以快速引导电流回到地，触发保护装置（如断路器）。
  • (2) 为什么触摸⽕线很危险？
    • ⽕线为 220V，地为 0V，身体与地之间构成回路，导致电流流过身体，很危险！
    • 人体触电时，电流的整体路径是：⽕线（220V）→ 人体 → 地 → 零线（0V，接地）→ 发电⼚。

• 无地线 + 人体触电（致命危险）

• 接地线 + 人体触电（非致命危险）

• 断路器 + 接地线 + 人体触电（安全）

串联与并联

串联电路

并联电路

串并联练习

• 电路图 1，请分析 A、B、C 三点电压分别是多少？答案是：A 点 9V，B 点 3V，C 点 0V，点击查看图解分析。

• 电路图 2，请分析 A、B、C 三点电压分别是多少？答案是：A 点 4V，B 点 1V，C 点 0V，点击查看图解分析。

• 电路图 3，请分析 A、B、C 三点电压分别是多少？答案是：A 点 10V，B 点 8V，C 点 4V，点击查看图解分析。

电功率

• 概念：

  • 电功率⽤于衡量电流在单位时间内所做的功（⽤来表示⽤电器消耗电能快慢的物理量）。

• 单位：

  • 瓦特（简称瓦），符号是 W。

• 单位换算：

  • 进位为 1000，例如： 1kW = 1000W。
    

• 公式：

  • $P = U I$
    • U 为电压，单位为 V（伏）
    • I 为电流，单位为 A（安）
    • P 为功率，单位为 W（瓦）

• 常⻅⽤电器的功率

• 瓦时 VS 千瓦时

  • ⼆者都是表示电能的⼀种单位。
  • 瓦时：
    • 瓦时是功率（W）与时间（h）的乘积，即：瓦时 = 功率 × 时间
    • ⼀个 1W 的⽤电器，⼯作 1h ，它消耗的电量就是 1 瓦时（1Wh）。
  • 千瓦时：
    • 千瓦时是瓦时的千倍，通常⽤于描述⼤型电⼒设备，如电表读数、新能源汽⻋等。
    • ⼀个 1kW 的电器⼯作 1h ，它消耗的电量就是 1 千瓦时（1kWh，俗称 1 度电）。
      

• 安时 VS 毫安时

  • ⼆者都是描述电池容量的单位。
  • 安时：
    • 表示该电池能以 1A 的电流持续⼯作 1h，通常⽤于描述⼤容量的电池。
  • 毫安时：
    • 安时的千分之⼀，通常⽤于描述⼩容量的电池。
  • 例如：
    • 华为『Mate70 Pro』⼿机电池的容量为 5700mAh ，充电宝的电池容量为 20000mAh。
    • 有些时候我们也省略 h，直接说：⼿机的电池容量和为 5700mA，充电宝电池容量为：20000mA。
      

焦⽿定律

• 概念：

  • 电流通过导体产⽣的热量与电流的平⽅成正⽐，跟导体的电阻成正⽐，跟通电时间成正⽐。

• 单位：

  • 单位：焦⽿（简称焦），简称 J。

• 公式：

  • $Q = I^2 R t$
    • Q 为热量，单位为：J（焦⽿）
    • I 为电流，单位为：A（安培）
    • R 为电阻，单位为：Ω（欧姆）
    • t 为时间，单位为：s（秒）

• 例如：

  • ⼀根 60Ω 的电阻丝接在 36V 的电源两端，在 5 分钟内共产⽣多少热量？答案是：$ \left (\frac {36\ \text {V}}{60\ \Omega} \right)^2 \times 60\ \Omega \times 5\ \times 60\ = 6480\ \text {J} $
    

• 注意：

  • 电路通过导体时，如果电能全部转化为内能，⽽没有同时转化为其他形式的能量，那么电流产⽣的热量就等于消耗的电能，但实际上：只有纯电阻电路，才能把电能完全⽤于产⽣热量！
  • 对于纯电阻电路来说，消耗的电能全部⽤于转化热量，所以可以推导出如下公式：
    • 功率计算公式：$P = \frac {U^2}{R}$，$P = I^2 R$
    • 热量计算公式：$Q = U I t$，$Q = P t$

公式总结

学习路线

基于 ESP32 + SI4732 + ATS MINI 的生态开发收音机，开发者并不需要从 51 单片机、寄存器操作等传统嵌入式底层知识开始学习，而可以利用现有的开源项目成果，以 “应用集成和修改” 为核心来切入，这会大大降低门槛。

必备知识

基于 ESP32 + SI4732 + ATS MINI 的生态开发收音机，开发者不需要学习 “底层嵌入式全家桶”（寄存器、启动流程、裸机 RTOS 移植等），会 Arduino API 就能开发，但理解 I2C、GPIO、库结构、编译烧录流程是必须的。

• 必须掌握的知识（重点）

  • ESP32 基础使用
    • 会刷固件（USB / 串口）
    • 会选开发板（ESP32 / ESP32-S3）
    • 会看 GPIO 引脚定义
  • Arduino 开发方式
    • 开发工具：Arduino IDE / PlatformIO-IDE
    • 开发框架：Arduino Core for ESP32
    • 使用 setup() / loop()
    • 编译 → 烧录 → 串口调试
    • 修改现有 .ino / .cpp
  • I2C 基本概念
    • SDA / SCL
    • SI4732 是 I2C 设备
    • 会填正确的引脚即可（不需要写 I2C 驱动）
  • 读文档与改配置
    • 屏幕分辨率
    • 按键 / 编码器引脚
    • FM / AM / SW 频段参数
  • 到这里，就已经能跑 ATS MINI 固件了

• 不需要掌握的知识（忽略）

  • 裸机开发
  • 寄存器级 GPIO / I2C
  • FreeRTOS 调度原理
  • 链接脚本 / 启动代码
  • 芯片 DataSheet 逐页啃

• 只有在下面情况之一，才建议系统学习嵌入式

  • 自己写 SI4732 驱动
  • 自己做低功耗管理
  • 不用 Arduino IDE，改用 ESP-IDF
  • 做商业级产品 / 深度定制

开发工具

• ESP32 开发的工具链：
  • IDE：Arduino IDE
  • SDK：Arduino Core for ESP32
  • 硬件：ESP32 开发板 + SI4732 芯片 + 屏幕

• Arduino 官方提供的 Arduino Core for ESP32 支持以下芯片：

• Arduino Core for ESP32 对比 ESP-IDF（乐鑫官方原生 SDK）

入门步骤

• 第一步：搭建环境，跑通示例

  • 行动：安装 Arduino IDE，添加 ESP32 开发板支持；导入 ATS MINI 的源代码，尝试在电脑上成功编译。
  • 学习点：嵌入式开发的第一步就是工具链的搭建，这能让你熟悉最基本的流程。

• 第二步：购买开发板，点亮第一盏灯

  • 行动：购买一块 ESP32 开发板（如 ESP32-DevKitC），不接 SI4732，先学习如何控制一个 LED 闪烁，读取一个按键。
  • 学习点：这是嵌入式开发的 Hello World，让你建立 “编写代码 -> 硬件响应” 的直接概念，消除对硬件的陌生感。

• 第三步：连接核心部件，理解通信

  • 行动：将 SI4732 模块通过 I2C 接口连接到 ESP32。不要急于用 ATS MINI 完整代码，而是先寻找 SI4732 的 Arduino 基础库，尝试写几行代码，让 ESP32 命令 SI4732 收一个已知的 FM 电台，并读出信号强度。
  • 学习点：这是项目的核心，你将学会如何通过查阅芯片数据手册和使用现有驱动库来控制关键器件。I2C 通信是嵌入式开发中最常见的技能之一。

• 第四步：深入研究 ATS MINI 源码

  • 行动：在完成了前三步的基础上，再打开 ATS MINI 的工程。此时你看代码的心态会完全不同。你能找到初始化 SI4732 的代码、扫描频段的函数、处理编码器输入的逻辑。
  • 学习点：从 “读天书” 变成 “看图说话”。你能结合自己的实践经验，理解开源项目的架构设计，并知道在哪里修改以实现自己的功能。

学习资源

• ESP32：乐鑫官方文档是最好资源，重点关注 Arduino Core for ESP32 部分。
• SI4732：Silicon Labs 官方的 AN383（应用笔记） 和 SI4732 数据手册是必读文档，它详细说明了所有命令。
• ATS MINI 项目：仔细阅读其 GitHub 仓库的 README 和 Wiki（如果有），这里面通常包含了硬件连接图、编译说明和常见问题。

参考资料

• 开源收音机开发技术调研
• esp32-si4732/ats-mini 官方文档

技术路线

为了开发一款 DIY 收音机，非嵌入式开发者通常可以选择以下任意一种技术路线。

三种技术路线

• 技术路线一：模块化开发（推荐起点）
  • 怎么做：购买调频（FM）收音机模块（如 RDA5807、TEA5767）或网络收音机模块，用 Arduino 或 ESP32 这类开发板通过 I2C 等简单接口控制，甚至可以用树莓派做网络收音机。
  • 学习重点：基础的电子连接、Arduino IDE 的使用、调用现成的库函数。
  • 优点：最快出成果，能建立信心，适合所有初学者。

• 技术路线二：基于开源项目二次开发（平衡学习与成果）

  • 怎么做：在 GitHub 等平台找到开源收音机项目（例如，搜索 “Open Source Radio ESP32”）。下载其原理图、PCB 文件、源代码进行研究、焊接、烧录，并尝试修改功能（如增加显示屏、改变 UI）。
  • 学习重点：阅读和理解他人代码、学习使用 PCB 设计软件（如 KiCad）、掌握基本的焊接和调试技能。
  • 优点：在真实项目中高效学习，是成为合格开发者的最佳途径。

• 技术路线三：从零开始（不推荐新手直接尝试）

  • 涉及内容：从芯片 DataSheet 开始设计收音机高频头、中放电路；为微控制器编写底层寄存器代码驱动音频解码芯片；实现复杂的用户界面和网络协议栈。
  • 挑战：需要深厚的模拟 / 射频电路知识和嵌入式系统开发能力，极易因调试困难导致项目流产。

技术路线推荐

对于绝大多数个人开发者，强烈推荐从路线一或者路线二开始。尤其是路线二，它让你在一个高起点上站上巨人的肩膀，既能做出有成就感的作品，又能通过实践快速学习嵌入式开发中最实用的部分。一个有效的行动思路是：

• (1) 明确核心：先想清楚最想要的是 “一台自己做的收音机”，还是 “深入掌握嵌入式开发全过程”。如果是前者，绝对不要从零开始。
• (2) 寻找项目：立刻去 GitHub 等平台，用 “open source radio pcb” 或 “arduino radio” 等关键词搜索，找一个 star 数多、文档齐全的项目。
• (3) 动手复刻：按照项目指导，购买现成的 PCB（或打样）、采购元件、焊接、烧录程序，这个过程本身就是最好的学习。
• (4) 迭代升级：成功运行后，再尝试修改代码、增加功能，逐步深入到嵌入式开发中。

技术路线总结

开源固件项目

ATS MINI

项目简单介绍

• 在开源硬件与软件领域，ATS MINI 项目无疑是一个值得关注的技术瑰宝。它是一款专为 SI4732（ESP32-S3）Mini/Pocket Receiver 设计的固件，旨在为用户提供一个高度集成、易于使用的收音机解决方案。
• ATS MINI 项目的核心是一个功能齐全的收音机固件，它基于多个开源项目的经验与智慧，例如 Volos Projects、PU2CLR、Ralph Xavier、Goshante 以及 G8PTN 等。这些开源项目的合并，使得 ATS MINI 在性能与稳定性上有着坚实的基础。

项目主要特点

• 高度集成
  • ATS MINI 项目将 ESP32-S3 与 SI4732 模块的优势高度集成，用户无需担心复杂的硬件兼容性问题，只需关注于功能的实现和优化。
• 灵活配置
  • 项目支持多种硬件配置，用户可以根据自己的需求自由搭配，实现个性化定制。
• 开源共享
  • ATS MINI 项目遵循开源协议，用户可以自由使用、修改和分发，促进了技术的交流与共享。
• 完善文档
  • 项目提供了详细的硬件、软件以及刷机文档，即使是新手也能快速上手，降低了使用门槛。

项目技术分析

ATS MINI 项目采用 ESP32-S3 芯片作为主控制器，结合 SI4732 收音机模块，实现了 AM/FM/DAB+ 等多种广播信号的接收。其技术亮点如下：

• 高性能处理器：ESP32-S3 提供了强大的处理能力和丰富的接口，使得收音机在处理信号和用户交互时游刃有余。
• 模块化设计：项目支持多种硬件配置，用户可以根据自己的需求选择不同的硬件模块，实现个性化定制。
• 丰富接口支持：ESP32-S3 的丰富接口使得 ATS MINI 能够支持屏幕显示、按键输入等多种交互方式。

项目应用场景

ATS MINI 项目不仅适用于个人爱好者进行 DIY 创作，也适用于教育、科普等领域。以下是几个典型的应用场景：

• 个人娱乐：用户可以自定义收音机的外观和功能，打造独一无二的个人娱乐设备。
• 教育工具：ATS MINI 可以作为一个教学工具，帮助学生了解无线信号传输原理，提高实践操作能力。
• 科普展示：在科技馆、展览馆等场所，ATS MINI 可以作为展示无线信号传输技术的展品，供参观者体验。

项目开源地址

上游开源项目

下游开源项目

调频收音机

• ATS MINI 原始版本 / 老版本固件：G8PTN/ATS_MINI

  • G8PTN/ATS_MINI 是最早的原始 ATS MINI 固件来源之一。
  • 这是由作者 Dave (G8PTN) 发布的最初或早期的 ATS MINI 固件代码，围绕 ESP32-S3 + SI4732 搭建的固件实现。
  • 该项目包含基础的功能、菜单扩展、电池电压显示等，可作为项目的一个核心实现版本。

• ATS MINI 社区 Fork 版本 / 发展版本固件：esp32-si4732/ats-mini

  • esp32-si4732/ats-mini 是一个 “ATS MINI Firmware Fork（ATS MINI 固件派生版）”，基于包括 G8PTN/ATS_MINI 在内的多个开源项目来开发，例如 Volos Projects、PU2CLR、Ralph Xavier、Goshante 以及 G8PTN 自己的 ATS_MINI。
  • 该项目围绕 ESP32-S3 + SI4732 搭建的固件实现，它集成了更多贡献者的改善、修复、特性扩展和新功能，代码更活跃、更新频率更高，并且形成了自己的版本体系（比如 v2.x 系列）。

• SI4732 Radio 固件：si4732-radio

  • si4732-radio 是基于 G8PTN/ATS_MINI 的派生实现，偏向个人维护 / 定制化方向，围绕 ESP32-S2 + SI4732 搭建的固件实现。
  • 该项目由 Joaquim Org 维护，定位更偏向 通用型 / 工程示例型固件，适合作为 SI4732 芯片的软件参考实现与二次开发基础。

• SI4732 / SI4735 Radio 固件：ralphxavier/SI4735

  • ralphxavier/SI4735 是一个面向 SI4732 / SI4735 收音芯片的开源固件与示例项目，旨在为基于这些芯片的收音机开发提供功能实现和驱动参考。
  • 该项目支持在 ESP32 系列 MCU（包括 ESP32-S2 / ESP32-S3）平台上运行，通过 I²C 接口控制 SI4732 / SI4735，实现 FM、AM、SW 等广播波段的接收与基础操作，并提供基本界面交互示例代码。
  • 项目主要特点包括对硬件模块的收音控制逻辑封装、示例功能展示及对常见显示与按键硬件的支持，是一个适合作为 SI473x 系列芯片学习、移植与二次开发的基础实现仓库。

• SI4732 Mini Radio 资源汇总：Ramsin/SI4732-Mini-Radio-Files

  • SI4732 Mini Radio 的固件代码、硬件设计（PCB）、资源链接等汇总。

网络收音机

• yoRadio / 网络收音机固件: e2002/yoradio

  • e2002/yoradio 是一个基于 ESP32 + I2S DAC 或 VS1053 音频解码模块的网络互联网电台播放器固件项目，用于构建可播放网络电台流（Web Radio）的硬件网络收音机，不支持 FM 调频，完全依赖 Wi-Fi 网络流媒体。
  • 该项目定位为高度可定制的通用网络收音机固件，支持多种 ESP32 开发板和音频输出方案，适合 DIY 桌面网络收音机、智能音箱类设备。
  • 功能特点包括：
    • 支持 MP3、AAC 等常见网络电台流格式，通过 I2S DAC（如 PCM5102、ES9023 等）或 VS1053 输出音频。
    • 支持多种显示屏（如 SSD1306、ST7735、ILI9341 等），可显示电台名称、播放状态、时间、菜单等信息。
    • 内置 Web 管理界面，可通过浏览器配置 Wi-Fi、电台列表、系统参数，无需反复刷固件。
    • 支持多种人机交互方式：按键、旋转编码器、触摸屏等，硬件适配性强。
    • 支持 OTA 在线升级、电台列表导入导出、配置持久化存储。
    • 可选支持 MQTT / Home Assistant 集成，适合智能家居场景使用。

• ESP32 Radio Evo3 / 网络收音机固件: dzikakuna/ESP32_radio_evo3

  • dzikakuna/ESP32_radio_evo3 是一个基于 ESP32-S3 + PCM5102A 音频 DAC 的网络互联网电台播放器项目，称为 Evo (Evolution 3)，主要用于构建可播放全球在线电台流的硬件网络无线电设备，不支持 FM 调频，完全依赖 Wi-Fi 网络流媒体。
  • 该项目支持 MP3、AAC、VORBIS 和 FLAC（最高 1.5 Mbit/s）等多种流媒体格式，并集成了 OLED 显示、旋转编码器、IR 遥控等交互控制功能，让用户能方便进行调台、调音量等操作。
  • 功能特点包括：
    • 从预设的 “电台库” 文件获取网络电台流（支持 SD 卡或 GitHub 下载）。
    • 使用 I2S 与 PCM5102A DAC 解码音频并输出。
    • 内置完整的 Web 服务器，可通过浏览器在电脑或手机上控制电台、音量等设置。
    • OLED 显示屏显示当前电台信息、音量、VU 表等。
    • 使用单旋转编码器实现菜单操作（包括音量、台号、库切换等），同时支持 NEC 标准红外遥控器操作。
    • 支持 OTA（网页直接更新）、SD 卡浏览、3 种显示模式、睡眠定时器、3 点均衡器 等扩展功能。

二合一收音机

开源硬件资源

硬件博客资源

立创硬件资源

调频收音机

网络收音机

二合一收音机

前言

在 Linux 系统中，磁盘 I/O 往往是性能瓶颈。当应用程序频繁读取大文件（例如数据库文件、日志文件、多媒体文件）时，系统可能因为 I/O 等待而变得非常卡顿。为了减少磁盘压力、提升性能，Linux 提供了多种利用内存作为缓存的机制，例如：tmpfs、ramfs、Page Cache（页缓存）。本文将详细介绍这些机制的使用方法及区别，并介绍常用的磁盘 I/O 诊断工具。

磁盘 I/O 诊断工具

在 Linux 下，查看磁盘的吞吐量（每秒读 / 写的数据量）或者负载（IOPS - 每秒读 / 写的请求数），最常用、最直观的工具有下面几种。

iostat

iostat 是最快速的磁盘工具（强烈推荐）。

iostat 安装

1
2
3
4
5

# CentOS / RHEL
sudo yum install sysstat

# Debian / Ubuntu
sudo apt install sysstat

iostat 使用

• iostat 的使用

1

iostat -x 1

• 输出示例如下：

1
2
3
4
5
6
7

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           3.59    0.02    1.32    0.33    0.00   94.74

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sdc               0.09     0.67   33.60   14.91  2100.28  1028.30   128.99     0.32    6.53    2.01   16.73   0.43   2.09
sdb               0.00     0.00    0.17    0.00     9.39     0.00   110.24     0.00    6.75    6.75    0.00   4.22   0.07
sda               0.03     0.31    5.14    0.97   403.47    30.99   142.36     0.09   15.25   11.69   34.10   4.71   2.88

• 重点关注字段

• 其他字段说明

• 实战判断口诀
  • 磁盘是否被打满？
    • 看 %util
  • 磁盘为什么慢？
    • %util + await + avgqu-sz
  • 随机 I/O 还是顺序 I/O？
    • avgrq-sz + r/s / w/s
  • 是读慢还是写慢？
    • r_await vs w_await
  • 吞吐瓶颈还是 IOPS 瓶颈？
    • rkB/s / wkB/s vs r/s / w/s

iotop

iotop 是磁盘交互式神器（看进程 + 磁盘）。

iotop 安装

1
2
3
4
5

# CentOS / RHEL
sudo yum install iotop

# Debian / Ubuntu
sudo apt install iotop

iotop 使用

• iotop 的使用（需要 root 权限）

1

sudo iotop

1
2
3
4
5

# 或者
# -o 只显示有 I/O 的进程
# -p 显示进程而非线程
# -a 累计 I/O
sudo iotop -oPa

• 输出示例如下：

1
2
3
4
5
6
7

Total DISK READ:  12.34 M/s | Total DISK WRITE: 56.78 M/s
Actual DISK READ: 12.10 M/s | Actual DISK WRITE: 55.90 M/s
  TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN   IO>    COMMAND
12345 be/4  mysql    1.20 M/s    35.60 M/s    0.00 %  92.34 %  mysqld
23456 be/4  root     8.50 M/s     0.00 B/s    0.00 %  48.12 %  tar czf backup.tar.gz
34567 be/4  www-data 0.00 B/s     15.80 M/s   0.00 %  61.45 %  php-fpm
  987 be/4  root     0.00 B/s     2.10 M/s    0.00 %   5.23 %  jbd2/sda1-8

• 字段说明

• 排查磁盘 I/O 瓶颈时重点关注的字段
  • IO>（最重要）
    • 举例：

      1	IO> 92.34 %

    • 含义：
      • 进程 92% 的时间在等磁盘 I/O
      • 几乎可以确定：磁盘是瓶颈
    • 判断规则：
      • IO> > 30% → I/O 明显慢
      • IO> > 60% → 严重 I/O 阻塞
      • IO> > 80% → 磁盘被打爆
  • DISK READ / DISK WRITE
    • 举例：

      1	DISK WRITE 35.60 M/s

    • 用来判断：
      • 磁盘是读取多，还是写入多
      • 磁盘是否有异常的大流量进程
    • 特别注意：
      • 磁盘吞吐量高 ≠ 磁盘一定慢
      • 必须结合 IO> 来判断才有意义
  • Total / Actual 顶部汇总行（系统级）
    • 举例：

      1 2	Total DISK READ: 12.34 M/s | Total DISK WRITE: 56.78 M/s Actual DISK READ: 12.10 M/s | Actual DISK WRITE: 55.90 M/s

    • 字段：
      • Total DISK READ：所有进程发起的磁盘读取速率（总读请求速率）
      • Total DISK WRITE：所有进程发起的磁盘写入速率（总写请求速率）
      • Actual DISK READ：实际落盘的磁盘读取速率（受页缓存命中情况影响）
      • Actual DISK WRITE：实际落盘的磁盘写入速率（受页缓存、写合并等机制影响）
    • Total 与 Actual 两者差距大的可能原因
      • Page Cache（页缓存）命中高
      • 写请求被缓存 / 合并

vmstat

vmstat 无需安装，缺点只能看整体的磁盘 I/O 吞吐量，看不到具体的磁盘。

vmstat 概述

• vmstat 适合用来判断的事情

• vmstat 不适合用来判断的事情

vmstat 使用

• vmstat 的使用

1

vmstat 1

• 输出示例如下：

1
2
3
4
5
6
7

procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 1  0      0 24642772 6851660 22099404    0    0    50    16  133   71  3  1 95  0  0
 0  0      0 24644776 6851660 22096364    0    0     0    37 10080 9298  1  0 98  0  0
 0  0      0 24644308 6851660 22096384    0    0     0   409 3063 8706  1  0 99  0  0
 0  0      0 24652476 6851660 22096388    0    0     0   226 3145 8780  1  0 99  0  0
 0  0      0 24640804 6851660 22096400    0    0     0     0 4060 10007  1  1 98  0  0

• 重点关注字段

  • bi（Block In）
    • 每秒从块设备读取的数据量（磁盘读流量），单位：KB/s
    • 不是针对某一块磁盘，而是所有块设备的读吞吐量总和
    • bi 高，表示系统正在大量从磁盘读取数据
  • bo（Block Out）
    • 每秒写入块设备的数据量（磁盘写流量），单位：KB/s
    • 不是针对某一块磁盘，而是所有块设备的写吞吐量总和
    • bo 高，表现系统正在大量向磁盘写数据

• 使用注意事项

  • vmstat 关注的是「磁盘吞吐量」，而不是「磁盘负载」
  • bi / bo 高 ≠ 磁盘一定忙
  • 磁盘顺序读写时：
    • bi / bo 很高
    • 但磁盘可能很轻松
  • 磁盘随机读写时：
    • bi / bo 不高
    • 磁盘却可能被打满
  • 不能用 vmstat 来判断磁盘 I/O 瓶颈
    • bi / bo 是全系统汇总值
    • 只能判断 “有没有磁盘读写”
    • 不能判断 “哪个磁盘最忙”
    • 不能判断 “某个磁盘是否打满”

磁盘 I/O 优化方案

tmpfs

tmpfs 的概述

• tmpfs 是一种基于内存的文件系统：

  • 文件实际存储在内存 + 交换分区（Swap）中
  • 支持容量限制（挂载时可指定大小）
  • 内存不足时，tmpfs 文件可以被交换到 Swap
  • tmpfs 的文件内容本质上就是 Page Cache
  • 不会导致 OOM（Out of Memory）
  • 适合存放临时文件、缓存数据
  • 典型的挂载点：/dev/shm、/run

• tmpfs 的主要特点

  • 支持创建目录（无限层级）
  • 支持普通文件
  • 支持符号链接、硬链接
  • 支持权限、UID/GID
  • 支持文件删除（立即释放内存）
  • 支持调整大小（动态扩缩）
  • 系统重启后会丢失所有数据

• tmpfs 的适用场景

  • 程序临时文件
  • 加速频繁读写的小文件
  • 构建系统（make、npm、cargo 等）
  • OBS、FFmpeg 等读取多媒体文件减少磁盘压力

tmpfs 的使用

• 创建挂载点

1

sudo mkdir -p /mnt/ramdisk

• 挂载 tmpfs

1
2

# 比如限制 4GB 容量
sudo mount -t tmpfs -o size=4G tmpfs /mnt/ramdisk

• 验证挂载

1

df -h /mnt/ramdisk

• 开机自动挂载（可选）

1
2
3
4
5

# 编辑 fstab 系统配置文件，添加以下配置内容
sudo vim /etc/fstab

# 挂载 fstab 中所有自动挂载的文件系统，并检测配置是否正确
sudo mount -a

1

tmpfs /mnt/ramdisk tmpfs defaults,size=4G 0 0

• 卸载挂载（可选）

1

sudo umount /mnt/ramdisk

ramfs

ramfs 的概述

• ramfs 是最简单的内存文件系统：

  • 数据存储在纯内存中
  • 没有容量限制
  • 内存写满后系统不会阻止继续写入，会持续占用内存
  • 内存耗尽就会 OOM，最终导致系统宕机
  • 更像一个危险，但读写速度极快的文件系统

• ramfs 的主要特点

  • 支持创建目录（无限层级）
  • 支持普通文件
  • 支持符号链接、硬链接
  • 支持权限、UID/GID
  • 支持文件删除（立即释放内存）
  • 不支持大小限制（不能设置 Size，容量可无限增长）
  • 数据页不可回收（不会被内核回收）
  • 不支持 Swap Out（永远驻留物理内存中）
  • 容易导致系统 OOM（写入越多，内存占用越多）
  • 系统重启后会丢失所有数据

• ramfs 的适用场景

  • 极端场景下的高性能缓存
  • 只用于开发 / 研究，不建议生产环境使用

ramfs 的使用

• 创建挂载点

1

sudo mkdir -p /mnt/ramdisk

• 挂载 ramfs

1

sudo mount -t ramfs ramfs /mnt/ramdisk

• 开机自动挂载（可选）

1
2
3
4
5

# 编辑 fstab 系统配置文件，添加以下配置内容
sudo vim /etc/fstab

# 挂载 fstab 中所有自动挂载的文件系统，并检测配置是否正确
sudo mount -a

1

ramfs   /mnt/ramdisk   ramfs   defaults   0   0

• 卸载挂载（可选）

1

sudo umount /mnt/ramdisk

Page Cache

Page Cache 的概述

即使用户不主动使用 tmpfs 或 ramfs 文件系统，Linux 内核本身也会自动利用内存作为 “磁盘缓存”。当用户读取一个文件时：

• 内核将数据加载到操作系统的 Page Cache（页缓存）
• 下次读取同一个文件时，不再触发磁盘 I/O，直接从内存返回结果

Page Cache 的使用

• 将文件写入 Page Cache

1

cat video.mp4 > /dev/null

1
2
3
4

上述命令会：
- 强制把 `video.mp4` 文件从磁盘加载进内存
- 但不输出任何内容
- 后续程序读取 `video.mp4` 文件会命中缓存，不再产生磁盘 I/O

• 查看缓存使用情况

1
2

# 查看内存使用情况，会看到 buff/cache 部分增大
free -h

• 清除缓存（慎用，仅测试使用）

1
2
3
4
5

# 将所有文件系统的缓存数据写回磁盘
sudo sync

# 清理页缓存、目录缓存和 inode 缓存
sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'

优化方案总结

• tmpfs、ramfs、Page Cache 的优缺点

• tmpfs 与 ramfs 的主要区别

大纲

• C++ 从入门到精通之一、C++ 从入门到精通之二、C++ 从入门到精通之三
• C++ 从入门到精通之四、C++ 从入门到精通之五、C++ 从入门到精通之六
• C++ 从入门到精通之七、C++ 从入门到精通之八、C++ 从入门到精通之九
• C++ 从入门到精通之十、C++ 从入门到精通之十一

C++ 并发编程

线程开始和结束运行

thread 与 join () 的使用

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

#include <chrono>
#include <iostream>
#include <thread>

void func() {
    std::cout << "sub thread start." << std::endl;
    for (int i = 1; i <= 5; ++i) {
        std::cout << i << std::endl;
        std::this_thread::sleep_for(std::chrono::seconds(1));
    }
    std::cout << "sub thread end." << std::endl;
}

int main() {
    std::cout << "main thread start." << std::endl;

    // 创建并启动一个普通线程
    std::thread t(func);

    // 阻塞主线程，让主线程等待子线程执行结束，然后再往下执行
    // 注意：如果这里不让主线程阻塞等待子线程执行结束，会导致程序意外退出（直接崩溃），除非子线程调用 detach()
    t.join();

    std::cout << "main thread end." << std::endl;
    return 0;
}

程序运行输出的结果如下：

1
2
3
4
5
6
7
8
9

main thread start.
sub thread start.
1
2
3
4
5
sub thread end.
main thread end.

thread 与 detach () 的使用

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

#include <chrono>
#include <iostream>
#include <thread>

void func() {
    std::cout << "sub thread start." << std::endl;
    for (int i = 1; i <= 5; ++i) {
        std::cout << i << std::endl;
        std::this_thread::sleep_for(std::chrono::seconds(1));
    }
    std::cout << "sub thread end." << std::endl;
}

int main() {
    std::cout << "main thread start." << std::endl;

    // 创建并启动一个普通线程
    std::thread t(func);

    // 将主线程与子线程分离（即子线程变为守护线程），主线程无需等待子线程执行完成才继续往下执行
    t.detach();

    std::cout << "main thread end." << std::endl;
    return 0;
}

程序运行输出的结果如下，可以发现在子线程还未执行完，进程（主线程）就已经正常退出：

1
2
3
4

main thread start.
main thread end.
sub thread start.
1

线程创建的其他方式

使用函数对象创建线程

使用函数对象（仿函数）创建线程

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50

#include <chrono>
#include <iostream>
#include <thread>

class MyClass {
public:
    // 构造函数
    MyClass() {
        std::cout << "MyClass()" << std::endl;
    }

    // 拷贝构造函数
    MyClass(const MyClass& mc) {
        std::cout << "MyClass(const MyClass &)" << std::endl;
    }

    // 析构函数
    ~MyClass() {
        std::cout << "~MyClass()" << std::endl;
    }

    // 重载 () 操作运算符
    void operator()() {
        std::cout << "sub thread start." << std::endl;
        for (int i = 1; i <= 5; ++i) {
            std::cout << i << std::endl;
            std::this_thread::sleep_for(std::chrono::seconds(1));
        }
        std::cout << "sub thread end." << std::endl;
    }
    
};

int main() {
    std::cout << "main thread start." << std::endl;

    // 定义函数对象（仿函数）
    MyClass mc;

    // 创建并启动一个普通线程
    // 注意：这里底层会将 mc 对象复制到子线程里面去，因此即使 mc 对象提前销毁，也不会影响子线程的执行
    std::thread t(mc);

    // 阻塞主线程，让主线程等待子线程执行结束，然后再往下执行
    // 注意：如果这里不让主线程阻塞等待子线程执行结束，会导致程序意外退出（直接崩溃），除非子线程调用 detach()
    t.join();

    std::cout << "main thread end." << std::endl;
    return 0;
}

程序运行输出的结果如下：

1
2
3
4
5
6
7
8
9
10
11
12
13

main thread start.
MyClass()
MyClass(const MyClass &)   // 将主线程中的 MyClass 对象复制进子线程中
sub thread start.
1
2
3
4
5
sub thread end.
~MyClass()            // 这里析构的是复制进子线程的 MyClass 对象
main thread end.
~MyClass()            // 这里析构的是主线程中定义的 MyClass 对象 mc

使用函数对象创建线程时，应避免引用局部变量

在下面这段代码中，最核心问题是：MyClass 的构造函数接收 int& 引用，该引用绑定到 main 函数的局部变量 i。当子线程执行 detach() 后，主线程可能先于子线程结束运行，导致局部变量 i 被销毁，而子线程中的 m_i 仍持有该悬空引用，后续在 operator() 中访问 m_i 时将产生未定义行为（通常是程序崩溃、数据错乱或看似正常等）。特别注意，在使用函数对象（仿函数）创建线程时，应避免引用局部变量，否则可能会导致悬空引用（发生未定义行为）。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53

#include <chrono>
#include <iostream>
#include <thread>

class MyClass {
public:
    // 构造函数
    MyClass(int &i) : m_i(i) {
        std::cout << "MyClass()" << std::endl;
    }

    // 拷贝构造函数
    MyClass(const MyClass &mc) : m_i(mc.m_i) {
        std::cout << "MyClass(const MyClass &)" << std::endl;
    }

    // 析构函数
    ~MyClass() {
        std::cout << "~MyClass()" << std::endl;
    }

    // 重载 () 操作运算符
    void operator()() {
        std::cout << "sub thread start." << std::endl;
        for (int i = 1; i <= 5; ++i) {
            std::cout << i << ", " << m_i << std::endl;
            std::this_thread::sleep_for(std::chrono::seconds(1));
        }
        std::cout << "sub thread end." << std::endl;
    }

private:
    int &m_i;  // 引用
};

int main() {
    std::cout << "main thread start." << std::endl;

    int i = 100;

    // 定义函数对象（引用了局部变量）
    MyClass mc(i);

    // 创建并启动一个普通线程
    // 注意：这里底层会将 mc 对象复制到子线程里面去，因此即使 mc 对象提前销毁，也不会影响子线程的执行
    std::thread t(mc);

    // 将主线程与子线程分离（即子线程变为守护线程），主线程无需等待子线程执行完成才继续往下执行
    t.detach();

    std::cout << "main thread end." << std::endl;
    return 0;
}

程序运行输出的结果如下，可以发现在子线程还未执行完，进程（主线程）就已经正常退出，并且 m_i 成员变量输出的值可能是错误的：

1
2
3
4
5
6
7
8
9

main thread start.
MyClass()
MyClass(const MyClass &)    // 将主线程中的 MyClass 对象复制进子线程中
main thread end.
~MyClass()    // 这里析构的是主线程中定义的 MyClass 对象 mc
sub thread start.
sub thread start.
1, 22088    // 由于在主线程中，MyClass 对象引用了局部变量，因此这里输出的 m_i 成员变量的值可能是错误的；因为主线程先结束运行，局部变量 i 所在的栈内存会跟着提前被释放掉
1, 22088    // 由于在主线程中，MyClass 对象引用了局部变量，因此这里输出的 m_i 成员变量的值可能是错误的；因为主线程先结束运行，局部变量 i 所在的栈内存会跟着提前被释放掉

使用 Lambda 创建线程

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

#include <chrono>
#include <iostream>
#include <thread>

int main() {
    std::cout << "main thread start." << std::endl;

    // 定义 Lambda 表达式
    auto lambda = [] {
        std::cout << "sub thread start." << std::endl;
        for (int i = 1; i <= 5; ++i) {
            std::cout << i << std::endl;
            std::this_thread::sleep_for(std::chrono::seconds(1));
        }
        std::cout << "sub thread end." << std::endl;
    };

    // 创建并启动一个普通线程
    // 注意：这里底层会将 mc 对象复制到子线程里面去，因此即使 mc 对象提前销毁，也不会影响子线程的执行
    std::thread t(lambda);

    // 阻塞主线程，让主线程等待子线程执行结束，然后再往下执行
    // 注意：如果这里不让主线程阻塞等待子线程执行结束，会导致程序意外退出（直接崩溃），除非子线程调用 detach()
    t.join();

    std::cout << "main thread end." << std::endl;
    return 0;
}

程序运行输出的结果如下：

1
2
3
4
5
6
7
8
9

main thread start.
sub thread start.
1
2
3
4
5
sub thread end.
main thread end.

使用成员函数指针创建线程

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54

#include <iostream>
#include <thread>

class MyClass {
public:
    // 有参构造函数
    MyClass(int i) : m_i(i) {
        std::cout << "MyClass()" << std::endl;
    }

    // 拷贝构造函数
    MyClass(const MyClass &mc) : m_i(mc.m_i) {
        std::cout << "MyClass(const MyClass &)" << std::endl;
    }

    // 析构函数
    ~MyClass() {
        std::cout << "~MyClass()" << std::endl;
    }

    // 成员函数
    void thread_run(MyClass &mc) {
        std::cout << "sub thread start." << std::endl;
        // 主线程中使用 std::ref() 强制传递引用作为线程函数参数后，这里修改的是主线程中的 m_c 对象
        mc.m_i = 300;
        std::cout << "sub thread end." << std::endl;
    }

public:
    int m_i;
};

int main() {
    std::cout << "main thread start." << std::endl;

    // 局部变量
    MyClass m_c(200);

    // 在创建子线程时，使用 std::ref() 强制传递引用作为线程函数参数
    // 第一个参数是成员函数指针，第二个参数是类对象（可以是指针或者引用），第三个参数是真正传递给线程函数的参数
    std::thread t(&MyClass::thread_run, &m_c, std::ref(m_c));

    // 等价于上面的写法
    // std::thread t(&MyClass::thread_run, std::ref(m_c), std::ref(m_c));

    // 注意：如果使用下面这种写法（合法），又会多拷贝一份 m_c 对象，导致线程函数里修改的不是主线程中的 m_c 对象
    // std::thread t(&MyClass::thread_run, m_c, std::ref(m_c));

    // 主线程需等待子线程执行完成才继续往下执行
    t.join();

    std::cout << "main thread end." << std::endl;
    return 0;
}

程序运行的结果如下：

1
2
3
4
5
6

main thread start.
MyClass()
sub thread start.
sub thread end.
main thread end.
~MyClass()

线程传递参数的方式

传递临时对象作为线程参数

参数传递实战

这段代码是安全的（正确的），因为主线程必须等待子线程执行结束，然后再往下执行。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

#include <iostream>
#include <thread>

// 定义普通函数（带参数）
void func(const int &i, char *buf) {
    std::cout << "sub thread start." << std::endl;
    std::cout << i << std::endl;
    std::cout << buf << std::endl;
    std::cout << "sub thread end." << std::endl;
}

int main() {
    std::cout << "main thread start." << std::endl;

    // 局部变量
    int m_i = 1;
    char m_buf[] = "this is a string";

    // 创建线程，并传递参数
    std::thread t(func, m_i, m_buf);

    // 阻塞主线程，让主线程等待子线程执行结束，然后再往下执行
    // 注意：如果这里不让主线程阻塞等待子线程执行结束，会导致程序意外退出（直接崩溃），除非子线程调用 detach()
    t.join();

    std::cout << "main thread end." << std::endl;
    return 0;
}

程序运行输出的结果如下：

1
2
3
4
5
6

main thread start.
sub thread start.
1
this is a string
sub thread end.
main thread end.

要避免的陷阱一

在下面的这段代码中，存在一个严重的悬垂指针问题，这是 C++ 多线程开发中非常经典的错误。核心问题是：参数 m_buf 传递的是指针，但在子线程执行 detach() 后，主线程可能先结束运行，导致局部变量 m_buf 被销毁，最终子线程会访问已释放的内存。

• (1) 代码安全的部分：int & 参数

  • 虽然函数签名是 const int &i，但实际上 std::thread 构造函数会对参数做按值拷贝（除非显式使用 std::ref）
  • 即使 detach() 后主线程销毁了 m_i，子线程持有的也是独立副本，访问是安全的

• (2) 代码不安全的部分：char * 参数

  • m_buf 是局部变量，存储在栈上
  • std::thread 只是传递了数组首地址（指针值被拷贝），并没有拷贝字符串内容
  • 当主线程执行完 return 0 后，m_buf 的内存会被释放 / 覆盖
  • 子线程若此时继续访问 buf，将发生未定义行为（程序可能会崩溃、输出乱码、看似正常等）

问题代码

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

#include <iostream>
#include <thread>

// 定义普通函数（带参数）
void func(const int &i, char *buf) {
    std::cout << "sub thread start." << std::endl;
    std::cout << i << std::endl;
    std::cout << buf << std::endl;
    std::cout << "sub thread end." << std::endl;
}

int main() {
    std::cout << "main thread start." << std::endl;

    // 局部变量
    int m_i = 100;
    char m_buf[] = "this is a string";

    // 创建线程，并传递参数
    std::thread t(func, m_i, m_buf);

    // 将主线程与子线程分离（即子线程变为守护线程），主线程无需等待子线程执行完成才继续往下执行
    t.detach();

    std::cout << "main thread end." << std::endl;
    return 0;
}

解决方案

• 解决方案一：使用 join() 替代 detach()，让主线程等待子线程结束

1
2
3
4
5
6
7
8
9
10
11
12
13

void func(const int &i, char *buf) {
    std::cout << "sub thread start." << std::endl;
    std::cout << i << std::endl;
    std::cout << buf << std::endl;
    std::cout << "sub thread end." << std::endl;
}

int main() {
    int m_i = 100;
    char m_buf[] = "this is a string";
    std::thread t(func, m_i, m_buf);
    t.join();   // 主线程等待子线程结束
}

• 解决方案二：传递字符串副本

1
2
3
4
5
6
7
8
9
10
11
12
13

void func(const int &i, char *buf) {
    std::cout << "sub thread start." << std::endl;
    std::cout << i << std::endl;
    std::cout << buf << std::endl;
    std::cout << "sub thread end." << std::endl;
}

int main() {
    int m_i = 100;
    char m_buf[] = "this is a string";
    std::thread t(func, m_i, std::string(m_buf));   // 使用临时对象
    t.detach();
}

• 解决方案三：使用智能指针

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

void func(const int &i, char *buf) {
    std::cout << "sub thread start." << std::endl;
    std::cout << i << std::endl;
    std::cout << buf << std::endl;
    std::cout << "sub thread end." << std::endl;
}

int main() {
    int m_i = 100;
    char m_buf[] = "this is a string";
    auto sp_buf = std::make_shared<char[]>(strlen(m_buf) + 1);
    strcpy(sp_buf.get(), m_buf);

    std::thread t([m_i, sp_buf]() { 
        func(m_i, sp_buf.get()); 
    });
    t.detach();
}

• 解决方案四：使用值传递而不是引用专递（最佳实践）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

// 最安全的写法（不使用引用或指针，直接传递值）
void func(const int i, const std::string buf) {
    std::cout << i << std::endl;
    std::cout << buf << std::endl;
}

int main() {
    int m_i = 100;
    char m_buf[] = "this is a string";
    
    // 传递字符串副本（使用临时对象）
    std::thread t(func, m_i, std::string(m_buf));

    // 现在执行 detach() 安全了，因为 string 已经被拷贝到线程内部
    t.detach();

    return 0;
}

要避免的陷阱二

在下面的这段代码中，存在一个严重的悬空引用问题，这是 C++ 多线程开发中非常经典的错误。核心问题是：由于 m_c 局部变量通过隐式类型转换构造 MyClass 临时对象的时机不确定，因此代码是不安全的。

• (1) 隐式类型转换的细节：

  • func() 期望第二个参数是 const MyClass &，但传递的是 int，这里会发生隐式类型转换，也就是编译器会用 m_c（200）调用 MyClass(int) 构造函数创建一个临时对象。

• (2) 代码安全的部分：int & 参数

  • 虽然函数签名是 const int &i，但实际上 std::thread 构造函数会对参数做按值拷贝（除非显式使用 std::ref）
  • 即使 detach() 后主线程销毁了 m_i，子线程持有的也是独立副本，访问是安全的

• (3) 代码不安全的部分：MyClass & 参数

  • m_c（200）会通过隐式类型转换构造一个 MyClass 临时对象
  • 但是 std::thread 并不是立即执行线程函数，它会先拷贝或移动参数到内部存储
  • 当线程函数真正执行时，MyClass 临时对象的构造时机可能已经晚于主线程中 m_c 的销毁
  • 因此 const MyClass &mc 可能绑定到一个未正确构造的 MyClass 对象
  • 这会导致悬空引用，访问 mc 属于未定义行为（通常是程序崩溃、数据错乱或看似正常等）