墨青的博客

在 Fedora 上启用 ntfs3 文件系统驱动

Fri, 24 Jul 2026 00:00:00 GMT

前几天突然想起来自己还有一个 256G 的 NVMe SSD，是大一的时候买来当移动硬盘用的，可惜之前两次由于对这方面知识的欠缺，购买的硬盘盒都比较差劲，硬盘就一直搁置着。现如今，我还是认为自己需要一个移动硬盘，于是又新购入了一个硬盘盒。组装好后，我尝试在 Fedora 上测试它的读写速度，发现原本理论上是 10 Gbps 的传输速度，在使用 dd 测试顺序写入时，平均速度只有约 142 MB/s！我查阅了大量资料，发现貌似是文件系统的原因，我的硬盘使用的文件系统是 NTFS，而我并不想改用别的文件系统，所以只能找找看有没有两全其美的办法。

于是我发现了 ntfs3 文件系统驱动。

为什么用 NTFS ？#

NTFS 是微软为 Windows NT 系列设计的现代文件系统，也是目前 Windows 系统盘指定的文件系统。众所周知，exFAT 文件系统是大家使用移动硬盘的默认选择，因为其兼容性良好，符合移动硬盘跨平台使用的需求。但我使用的并不是传统的 U 盘。对于采用 NVMe SSD 的移动硬盘，其使用方式通常已经从 “移动存储介质” 转变为 “移动工作磁盘” 。相比主要面向移动存储设备兼容性的 exFAT，NTFS 提供日志保护、B+Tree 元数据索引、更完善的权限模型以及对链接、稀疏文件等高级特性的支持，在大量小文件、开发环境和长期数据存储场景下具有明显优势。

什么是 ntfs3 ？#

ntfs3 是 Linux 内核中的一个原生 ntfs 读写文件系统驱动，由 Paragon Software Group 开发并贡献给 Linux 内核，在 Linux v5.15-rc1 的 commit f746406 中正式合并。它的目标是替代早期 Linux 内核中功能有限的只读 ntfs 驱动以及基于 FUSE 的 ntfs-3g。

注意事项#

如果你的电脑是 Windows 与 Linux 双系统，那么请关闭 Windows 的快速启动。Windows 的快速启动本质上是休眠，即将完整的内存快照写入到磁盘，在下次启动 Windows 时再将其还原到内存，从而达到快速启动的效果。使用 ntfs3 挂载 Windows 系统盘并写入数据时，有可能会破坏这部分数据，进而造成 Windows 系统在启动时出现不同程度的异常。

开始使用#

检查配置#

首先，需要确认内核是否加载了 ntfs3 模块：

Terminal window

1
grep ntfs3 /proc/filesystems

如果已经有输出，请跳转至挂载。如果没有输出，说明内核并没有加载 ntfs3 模块，需要手动加载：

Terminal window

1
sudo modprobe ntfs3

注意：Linux 内核从 5.15 开始正式合并 ntfs3 驱动，如果不确定你的内核版本，可使用 uname -r 来确认。

挂载#

手动挂载#

在 /mnt 目录下新建一个或多个目录作为挂载点：

Terminal window

1
mkdir /mnt/mydrive

将硬盘分区通过 ntfs3 挂载在此挂载点：

Terminal window

1
# 以我的单分区移动硬盘为例
2
sudo mount -t ntfs3 /dev/sda1 /mnt/mydrive

确认：

Terminal window

1
mount | grep sda1

输出应该类似：

1
/dev/sda1 on /mnt/mydrive type ntfs3 (rw,relatime,uid=0,gid=0,acl,iocharset=utf8,prealloc)

自动挂载#

以 udisk2 为例，查看 udisk2 服务运行状态：

Terminal window

1
sudo systemctl status udisks2.service

创建 udisk2 配置文件，然后编辑：

Terminal window

1
sudo touch /etc/udisks2/mount_options.conf
2
sudo nano /etc/udisks2/mount_options.conf

写入以下内容：

1
[defaults]
2
ntfs:ntfs3_defaults=uid=$UID,gid=$GID
3
ntfs_drivers=ntfs3,ntfs

重启 udisk2 服务：

Terminal window

1
sudo systemctl restart udisks2.service

然后尝试使用 Dolphin 或桌面提示挂载硬盘，再检查：

Terminal window

1
mount | grep sda1

输出应该类似：

1
/dev/sda1 on /run/media/black/5A0580082D5EA6A1 type ntfs3 (rw,nosuid,nodev,relatime,uid=1000,gid=1000,acl,iocharset=utf8,prealloc,uhelper=udisks2)

性能测试#

使用 ntfs-3g：

1
❰black❙/mnt/mydrive❱✔≻ dd if=/dev/zero of=testfile bs=1G count=4 conv=fdatasync status=progress
2
4294967296 字节 (4.3 GB, 4.0 GiB) 已复制，28 s，153 MB/s
3
输入了 4+0 块记录
4
输出了 4+0 块记录
5
4294967296 字节 (4.3 GB, 4.0 GiB) 已复制，28.4704 s，151 MB/s

使用 ntfs3：

1
❰black❙/run/media/black/5A0580082D5EA6A1❱✔≻ dd if=/dev/zero of=testfile bs=1G count=4 conv=fdatasync status=progress
2
4294967296 字节 (4.3 GB, 4.0 GiB) 已复制，4 s，971 MB/s
3
输入了 4+0 块记录
4
输出了 4+0 块记录
5
4294967296 字节 (4.3 GB, 4.0 GiB) 已复制，6.33572 s，678 MB/s

可以看到，ntfs3 确实让硬盘的读写速度提升了不少。

参考文档#

NTFS3 —— Linux 内核文档

在 Linux 上配置树莓派 4B OpenCV 交叉编译

Sat, 18 Jul 2026 00:00:00 GMT

这两天大家都在火热地准备电赛，我也不例外。去年我使用的摄像头是 MaixCam Pro，编程语言我选择了 Python，使用了 MaixPy 和 Python OpenCV 库。苦于性能瓶颈，今年我打算用 C++ 重写图像处理逻辑，目标平台是树莓派 4B。

为什么需要交叉编译#

树莓派 4B 用的是 ARM Cortex-A72，编译 C++ 本来就慢，加上 OpenCV 的头文件和模板展开量巨大，哪怕是一个小项目也可能需要编译几十秒。开发过程中改一行代码就要重新编译，十分影响开发效率。交叉编译让我们在 x86 PC 上直接生成 ARM 二进制文件，编译速度能快不少。

整个流程大致是：

在树莓派上安装 OpenCV 的开发包
将树莓派的根文件系统同步到 PC，这样 PC 上的交叉编译器就能够使用树莓派 ARM 架构的 OpenCV 头文件和库
在 PC 上配置交叉编译工具链
使用 CMake + 交叉工具链编译你自己的项目
将编译好的二进制部署到树莓派

准备工作#

首先确保树莓派已开启 SSH，并能从你的 PC 连接。

SSH 到树莓派，安装 OpenCV 开发包：

Terminal window

1
sudo apt update
2
sudo apt install -y --no-install-recommends \
3
    libopencv-dev

libopencv-dev 会自动拉入所有 OpenCV 模块以及它们的头文件和 .so 链接。后续 rsync sysroot 时，这些头文件和库会被一起同步到 PC，编译器就能找到它们了。

获取树莓派 sysroot#

sysroot 是交叉编译的核心。它让 PC 上的编译器能识别目标设备的头文件和库。我们需要将树莓派的整个根文件系统复制到 PC。

在 PC 上创建 sysroot 目录，然后使用 rsync 同步：

Terminal window

1
mkdir -p ~/rpi-sysroot
2
rsync -avz --copy-unsafe-links \
3
    --exclude=/proc --exclude=/sys --exclude=/dev \
4
    --exclude=/tmp --exclude=/run --exclude=/mnt \
5
    pi@<树莓派IP>:/ ~/rpi-sysroot/

注意：将 <树莓派IP> 替换为你的树莓派 IP 地址。--copy-unsafe-links 会将绝对路径符号链接转换为相对路径的副本，避免链接指向宿主机路径。

配置宿主机交叉编译环境#

这里出现了分水岭：你的 PC 用的是什么 Linux 发行版？

Debian 系（Debian、Ubuntu、Mint 等）#

如果你用的是 Debian 系，事情很简单。Debian 的 multiarch 支持非常成熟，直接 apt install 即可获得交叉编译工具链：

Terminal window

1
sudo dpkg --add-architecture arm64
2
sudo apt update
3
sudo apt install -y --no-install-recommends \
4
    gcc-aarch64-linux-gnu g++-aarch64-linux-gnu \
5
    binutils-aarch64-linux-gnu

然后配置 CMake 工具链文件，指定 sysroot 路径和交叉编译器即可开始编译。

非 Debian 系（Fedora、Arch、openSUSE 等）#

如果你用的是 Fedora、Arch Linux、openSUSE 等非 Debian 系发行版，问题就复杂了。这些发行版虽然也提供 aarch64-linux-gnu-* 交叉工具链包，但存在几个棘手的问题：

工具链版本不一致，不同发行版提供的 binutils/gcc 版本可能与树莓派 sysroot 中的库 ABI 不兼容。
库路径布局差异，非 Debian 系的 aarch64 工具链默认搜索路径与 Debian 的 multiarch 布局 /usr/lib/aarch64-linux-gnu/ 不同，导致链接器找不到库。
glibc 版本不匹配，Arch 等滚动发行版的 glibc 版本往往更新，链接到树莓派旧版 glibc 时可能出现符号未定义的问题。

使用容器是非常好的一种解决方案。在 Docker/Podman 容器中运行一个完整的 Debian 环境，将树莓派 sysroot 挂载进去，所有编译操作都在容器内完成。这样工具链和 sysroot 同属 Debian 生态，自然兼容。

容器方案详解#

我选择 debian:trixie 作为基础镜像（Trixie 是 Debian 13，也是当前的 testing 分支，包版本较新且稳定）。以下是我的 Dockerfile：

1
FROM debian:trixie
2

3
ENV DEBIAN_FRONTEND=noninteractive
4
ENV TARGET_TRIPLE=aarch64-linux-gnu
5
ENV TOOLCHAIN_PREFIX=/usr/${TARGET_TRIPLE}
6
ENV SYSROOT_MOUNT=/sysroot
7

8
RUN apt update && apt install -y --no-install-recommends \
9
    build-essential \
10
    gcc-${TARGET_TRIPLE} g++-${TARGET_TRIPLE} binutils-${TARGET_TRIPLE} \
11
    cmake ninja-build make git rsync wget pkg-config dpkg-dev \
12
    && rm -rf /var/lib/apt/lists/*
13

14
RUN echo '#!/bin/bash' > /entrypoint.sh \
15
    && echo 'mkdir -p ${TOOLCHAIN_PREFIX}/{include,lib}' >> /entrypoint.sh \
16
    && echo 'rm -rf ${TOOLCHAIN_PREFIX}/include ${TOOLCHAIN_PREFIX}/lib/*' >> /entrypoint.sh \
17
    && echo 'ln -sf ${SYSROOT_MOUNT}/usr/include ${TOOLCHAIN_PREFIX}/include' >> /entrypoint.sh \
18
    && echo 'ln -sf ${SYSROOT_MOUNT}/usr/lib/${TARGET_TRIPLE} ${TOOLCHAIN_PREFIX}/lib' >> /entrypoint.sh \
19
    && echo 'exec "$@"' >> /entrypoint.sh \
20
    && chmod +x /entrypoint.sh
21

22
ENV CC=${TARGET_TRIPLE}-gcc --sysroot=${SYSROOT_MOUNT}
23
ENV CXX=${TARGET_TRIPLE}-g++ --sysroot=${SYSROOT_MOUNT}
24
ENV AR=${TARGET_TRIPLE}-ar
25
ENV PKG_CONFIG_SYSROOT_DIR=${SYSROOT_MOUNT}
26
ENV PKG_CONFIG_PATH=\
27
${SYSROOT_MOUNT}/usr/lib/${TARGET_TRIPLE}/pkgconfig:\
28
${SYSROOT_MOUNT}/usr/share/pkgconfig
29

30
WORKDIR /workspace
31
ENTRYPOINT ["/entrypoint.sh"]

展开收起

各部分说明#

ENV 环境变量定义了交叉编译的目标三元组 aarch64-linux-gnu，以及工具链和 sysroot 的挂载路径。将这些路径抽取为变量，方便使用者替换为自己需要的版本。

apt 安装的软件包分为几类：

build-essential：编译基础设施
gcc-aarch64-linux-gnu：ARM64 交叉编译器、汇编器和链接器
cmake ninja-build：Ninja 构建系统
rsync：从树莓派同步文件
pkg-config dpkg-dev：用于查找依赖库和生成正确的 pkg-config 路径

entrypoint.sh是容器启动时自动执行的脚本。它的任务是建立符号链接，让交叉工具链的默认搜索路径指向我们挂载的树莓派 sysroot：

将 ${SYSROOT_MOUNT}/usr/include 链接为工具链的 include 目录
将 ${SYSROOT_MOUNT}/usr/lib/${TARGET_TRIPLE} 链接为工具链的 lib 目录

这样当你使用 #include <opencv2/core.hpp> 时，编译器实际上会从树莓派的 sysroot 中寻找这个头文件。

CC/CXX 环境变量指定了交叉编译器，并通过 --sysroot 参数将 sysroot 设置为编译的根目录。GCC 的 --sysroot 选项会改变所有标准搜索路径（/usr/include、/usr/lib 等）的根前缀，效果等同于将 sysroot 模拟为 /。

PKG_CONFIG_SYSROOT_DIR 告诉 pkg-config 在 sysroot 中查找 .pc 文件，而 PKG_CONFIG_PATH 指定了 .pc 文件的具体搜索路径。这对于 CMake 找到 OpenCV 的依赖库至关重要。

构建和运行容器#

Terminal window

1
# 构建镜像
2
docker build -t rpi-cross-compiler .
3

4
# 运行容器，将 sysroot 挂载进去
5
docker run --rm -it \
6
    -v ~/rpi-sysroot:/sysroot:ro \
7
    -v $(pwd):/workspace \
8
    rpi-cross-compiler \
9
    bash

说明：/sysroot 以只读 :ro 方式挂载，防止编译过程意外修改树莓派系统文件。工作目录 /workspace 以读写方式挂载当前目录，用于存放源码和编译输出。

Sysroot 预处理：为什么需要这一步#

此前我在尝试交叉编译时，发现从树莓派 rsync 下来的 sysroot 不能直接使用，需要经过预处理。

1. 修复 merged-usr 目录结构#

Debian 从 Buster 开始采用了 merged-usr 方案（即 /bin、/sbin、/lib 统一迁移到 /usr/bin、/usr/sbin、/usr/lib 下，原路径保留为符号链接）。树莓派的 Raspberry Pi OS 基于 Debian，自然也遵循此布局。

但 rsync 在复制符号链接时，如果目标路径的解析出现问题（例如 --copy-unsafe-links 的处理时机），可能导致 sysroot 根目录下的 /include 或 /lib 符号链接变成空目录或指向错误位置。编译器查找头文件时，会期望 /sysroot/usr/include 是真实目录。如果 rsync 产物的结构不对，预处理脚本会将其修正为：

1
/sysroot/
2
├── include -> usr/include      # 符号链接
3
├── lib -> usr/lib              # 符号链接
4
└── usr/
5
    ├── include/                # 真实头文件目录
6
    └── lib/
7
        └── aarch64-linux-gnu/  # multiarch 库目录

2. 修复 C++ 标准库的多架构符号链接#

GCC 的 C++ 标准库头文件按架构组织，结构如下：

1
/usr/include/c++/14/
2
├── <平台无关头文件>
3
└── aarch64-linux-gnu/    # 平台相关头文件 → 链接到 ../../aarch64-linux-gnu/c++/14

在树莓派上，/usr/include/c++/14/aarch64-linux-gnu/ 应该是一个符号链接，指向 /usr/include/aarch64-linux-gnu/c++/14/，即 Debian multiarch 的 C++ 头文件存放位置。

这个符号链接使用的是绝对路径。当你用 rsync 拉取 sysroot 时，如果链接目标没有被完整保留，或者链接断掉了，编译 C++ 代码时就会找不到 <bits/c++config.h> 等平台相关头文件，报错：

1
fatal error: bits/c++config.h: No such file or directory

预处理会检查这个链接，如果断裂就重新创建。

我就是在这一步踩了坑。如果树莓派上没有 /usr/include/c++/14/aarch64-linux-gnu 也没关系，预处理会自动创建链接的。

3. 修复 alternatives 机制的断裂符号链接#

Debian 使用 update-alternatives 系统来管理同一软件的多个实现。BLAS 和 LAPACK（线性代数库，OpenCV 的核心依赖）就是典型例子：

1
/usr/lib/aarch64-linux-gnu/
2
├── libblas.so.3 -> blas/libblas.so.3.12.1   # alternatives 管理的链接
3
├── libblas.so -> blas/libblas.so             # 开发用的 .so 链接
4
├── liblapack.so.3 -> lapack/liblapack.so.3.12.1
5
└── liblapack.so -> lapack/liblapack.so

这些符号链接指向 blas/ 和 lapack/ 子目录下的实际库文件。但 rsync 同步时，这些相对路径链接可能因为 rsync 的 --copy-unsafe-links 选项或者文件系统差异而断裂或变成悬空链接。

后果就是链接阶段 CMake 找不到 -lblas 和 -llapack，链接器直接报 cannot find -lblas。

预处理脚本遍历 sysroot 中的库目录，检查这些关键的 libblas.* 和 liblapack.* 链接，如果断裂就手动修复，重新指向正确的目标文件。虽然逻辑看起来是重复的 case 分支，但每个链接的目标版本号可能不同（liblapack.so.3.12.1、libblas.so.3.12.1），必须逐一处理。

编译你自己的项目#

进入挂载了 sysroot 的容器后，就可以编译你自己的 C++ 项目了。

项目的 CMakeLists.txt#

跨平台编译的第一步是把 CMakeLists.txt 写对。下面是一个典型的 OpenCV 项目配置：

1
cmake_minimum_required(VERSION 3.16)
2
project(MyCVProject LANGUAGES CXX)
3

4
set(CMAKE_CXX_STANDARD 17)
5
set(CMAKE_CXX_STANDARD_REQUIRED ON)
6

7
find_package(OpenCV REQUIRED)
8

9
add_executable(my_app main.cpp)
10
target_link_libraries(my_app PRIVATE ${OpenCV_LIBS})

find_package(OpenCV REQUIRED) 会去 sysroot 里搜索 OpenCV 的 CMake 配置文件（OpenCVConfig.cmake），找到后自动设置好 include 路径和链接库。

交叉编译工具链文件#

CMake 靠工具链文件来知道你要交叉编译。创建一个 toolchain.cmake：

1
set(CMAKE_SYSTEM_NAME Linux)
2
set(CMAKE_SYSTEM_PROCESSOR aarch64)
3

4
set(CMAKE_SYSROOT /sysroot)
5

6
set(CMAKE_C_COMPILER aarch64-linux-gnu-gcc)
7
set(CMAKE_CXX_COMPILER aarch64-linux-gnu-g++)
8

9
set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
10
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
11
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
12
set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY)

配置说明：

CMAKE_SYSROOT：告诉 CMake 所有搜索都以此为根
CMAKE_C_COMPILER / CMAKE_CXX_COMPILER：指定交叉编译器。由于容器的 ENV 已经设了 CC/CXX（带 --sysroot），如果你想省略这两个变量，CMake 会自动从环境变量中获取
CMAKE_FIND_ROOT_PATH_MODE：控制 find_* 命令的查找策略。PROGRAM NEVER 表示不从 sysroot 中查找程序，而 LIBRARY ONLY、INCLUDE ONLY、PACKAGE ONLY 表示库、头文件、包都只从 sysroot 中查找，避免污染宿主机的头文件

编译#

Terminal window

1
# 在容器内执行
2
cd /workspace
3
mkdir build && cd build
4

5
cmake -GNinja \
6
    -DCMAKE_TOOLCHAIN_FILE=../toolchain.cmake \
7
    -DCMAKE_BUILD_TYPE=Release \
8
    ..
9

10
ninja -j$(nproc)

编译完成后，build/ 目录下就是可以在树莓派上直接运行的 ARM64 二进制文件。用 file 命令确认一下：

Terminal window

1
file my_app
2
# my_app: ELF 64-bit LSB executable, ARM aarch64, dynamically linked, ...

部署到树莓派#

编译产物只是一个可执行文件，直接 scp 过去就行：

Terminal window

1
scp build/my_app pi@<树莓派IP>:~/my_app

然后在树莓派上运行：

Terminal window

1
ssh pi@<树莓派IP> ./my_app

如果程序跑起来输出了预期结果，恭喜你，交叉编译成功了！

总结#

整个方案的核心思路是统一编译环境：让交叉工具链和 sysroot 来自同一个生态，避免跨发行版的 ABI 不兼容。对于使用 Fedora、Arch 等非 Debian 系发行版的开发者，Docker 容器以极低的额外开销解决了这个问题。

一年了

Sat, 10 Jan 2026 00:00:00 GMT

时间过得真快啊，网站不知不觉已经要一年了

前不久申请了宝塔砺行计划，最近给老师发邮件的时候才发现申请通过了，于是我马上为我的云服务器部署了宝塔面板（嘻嘻）

宝塔面板确实十分方便，他们推出的砺行计划对学生用户也十分有帮助，如果大家有条件的话，推荐大家都去申请一下

在 2026 年，我决定先修一下算法，然后尽量掌握 Jetpack Compose 安卓开发。看见网上很多人说学这个没用，国内没啥公司用这个写安卓，我想说的是，技术从来不应该通过有没有被广泛使用来衡量其必要性。不管是什么技术栈，其在传播时肯定不是第一天无人问津而第二天就做到家喻户晓的。有许多人愿意学习这门技术并且传播，就说明这门技术有前景有希望，并不会被一两盆冷水淹没。总之就一句话：程序员要多学、多练，而不是整天卖弄自己的才华，嘴里蹦出几个高级的专业词汇来唬人，然后对某门技术栈评头论足，去争个高低贵贱。

Sipeed 麦克风阵列获取声源角度

Sun, 06 Jul 2025 00:00:00 GMT

官方文档：MicArray 麦克风阵列 - Sipeed Wiki

在官方文档中，MicroPython 例程代码如下：

1
from Maix import MIC_ARRAY as mic
2
import lcd
3

4
lcd.init()
5
mic.init()                          # 默认配置
6
# mic.init(i2s_d0=23, i2s_d1=22, i2s_d2=21, i2s_d3=20, i2s_ws=19, i2s_sclk=18, sk9822_dat=24, sk9822_clk=25)       # 可自定义配置 IO
7

8
while True:
9
    imga = mic.get_map()            # 获取声音源分布图像
10
    b = mic.get_dir(imga)           # 计算、获取声源方向
11
    a = mic.set_led(b,(0,0,255))    # 配置 RGB LED 颜色值
12
    imgb = imga.resize(160,160)
13
    imgc = imgb.to_rainbow(1)       # 将图像转换为彩虹图像
14
    a = lcd.display(imgc)
15
mic.deinit()

展开收起

上述代码能够实现检测声源位置，输出声源彩虹图像，并点亮麦克风阵列上相应的 LED 灯

但是，代码中并没有明确输出声源的位置信息，这就导致了我们无法直接获取到声源的角度、距离等信息，从而无法实现某些功能

通过观察与调试，我们不难发现，mic.get_dir(imga) 获取到的数据是一组元组数据，其包括十二个元素。当麦克风阵列接收到声音时，其在控制台的输出近似如下的数据：

1
(0, 0, 0, 5, 8, 6, 0, 0, 0, 0, 0, 0)

我们可以初步判断，这组元组数据表示的应该是 12 个 LED 方向上的声音强度

聪明的你马上就想到了，我们可以根据这组数据获取声源角度

我们知道，麦克风阵列上有 12 个 LED ，如果以丝印正位方向为正位，那么它们代表的角度分别是 0° 30° 60° 90° 120° 150° 180° 210° 240° 270° 300° 330°。据此，我们便可以通过计算十二个方向的矢量和来估算声源的角度：

1
import math
2

3
def get_sound_angle(energy_data):
4
    if not energy_data or sum(energy_data) == 0:
5
        return None  # 返回None表示无效数据
6

7
    # 矢量求和法
8
    x_sum = 0.0
9
    y_sum = 0.0
10

11
    for i in range(12):
12
        angle_rad = math.radians(i * 30)
13
        # 对能量值进行平方增强主声源权重
14
        weighted_energy = energy_data[i] ** 2
15
        x_sum += weighted_energy * math.cos(angle_rad)
16
        y_sum += weighted_energy * math.sin(angle_rad)
17

18
    # 计算角度
19
    angle = math.degrees(math.atan2(y_sum, x_sum))
20

21
    # 转换为 -180 ~ 180 范围
22
    if angle > 180:
23
        angle -= 360
24
    elif angle < -180:
25
        angle += 360
26

27
    return int(angle)

展开收起

将例程中的 b = mic.get_dir(imga) 作为参数传递给该函数，便可以得到声源角度了。

我的任务是使用 K210 Maix Dock 搭配 Sipeed 麦克风阵列获取声源角度，控制舵机将激光照射在声源处。以下是我的程序源码：

1
from Maix import MIC_ARRAY as mic
2
from machine import Timer, PWM
3
import math
4
import time
5

6
# 全局变量
7
tim = None
8
pwm = None
9
angle_buffer = []           # 角度数据缓冲区
10
FILTER_WINDOW = 15          # 滤波窗口大小
11
SERVO_SMOOTH_FACTOR = 0.2   # 舵机运动平滑因子
12

13
def init():
14
    global pwm, tim
15
    tim = Timer(Timer.TIMER0, Timer.CHANNEL0, mode=Timer.MODE_PWM)
16
    pwm = PWM(tim, freq=50, duty=7.5, pin=0)  # 初始中间位置
17
    mic.init(i2s_d0=23, i2s_d1=22, i2s_d2=21, i2s_d3=20,
18
    i2s_ws=19, i2s_sclk=18, sk9822_clk=25, sk9822_dat=24)
19

20
def get_sound_angle(energy_data):
21
    if not energy_data or sum(energy_data) == 0:
22
    return None  # 返回 None 表示无效数据
23

24
    # 矢量求和法
25
    x_sum = 0.0
26
    y_sum = 0.0
27

28
    for i in range(12):
29
        angle_rad = math.radians(i * 30)
30
        # 对能量值进行平方增强主声源权重
31
        weighted_energy = energy_data[i] ** 2
32
        x_sum += weighted_energy * math.cos(angle_rad)
33
        y_sum += weighted_energy * math.sin(angle_rad)
34

35
    # 计算角度
36
    angle = math.degrees(math.atan2(y_sum, x_sum))
37

38
    # 转换为 -180 ~ 180 范围
39
    if angle > 180:
40
        angle -= 360
41
    elif angle < -180:
42
        angle += 360
43

44
    return int(angle)
45

46
def apply_filters(raw_angle):
47
global angle_buffer
48

49
    # 无效数据跳过
50
    if raw_angle is None:
51
        return None
52

53
    # 更新数据缓冲区
54
    angle_buffer.append(raw_angle)
55
    if len(angle_buffer) > FILTER_WINDOW:
56
        angle_buffer.pop(0)
57

58
    # 中值滤波
59
    sorted_angles = sorted(angle_buffer)
60
    median_angle = sorted_angles[len(sorted_angles) // 2]
61

62
    # 移动平均滤波
63
    avg_angle = sum(angle_buffer) / len(angle_buffer)
64

65
    # 加权组合滤波结果
66
    filtered_angle = 0.6 * median_angle + 0.4 * avg_angle
67

68
    # 角度连续性处理
69
    if filtered_angle > 180:
70
        filtered_angle -= 360
71
    elif filtered_angle < -180:
72
        filtered_angle += 360
73

74
    return int(filtered_angle)
75

76
def convert_angle(angle):
77
    """将声源角度映射到舵机控制信号
78
    参数: angle - 声源角度(-180~180度)
79
    返回: (有效角度, duty_val)
80
    """
81
    # 将角度转换为 0 ~ 360 范围用于计算
82
    angle_360 = angle % 360
83
    if angle_360 < 0:
84
        angle_360 += 360
85

86
    # 检查角度是否在有效范围内
87
    if 90 < angle_360 < 270:
88
        return False, None  # 无效角度
89

90
    # 映射角度到舵机控制信号:
91
    # - 90° -> duty 2.5 (右边)
92
    # - 0° -> duty 7.5 (正前方)
93
    # - -90°/270° -> duty 12.5 (左边)
94

95
    # 线性映射到duty值
96
    # 角度范围: -90° 到 90° 映射到 duty 12.5 到 2.5
97
    duty_val = 7.5 - (angle / 18.0)
98

99
    # 确保 duty 值在有效范围内
100
    duty_val = max(2.5, min(12.5, duty_val))
101
    return True, duty_val
102

103
def main():
104
    global angle_buffer
105
    last_valid_duty = 7.5   # 最后有效的 duty 值
106

107
    try:
108
        # 初始化角度缓冲区
109
        print("初始化角度缓冲区...")
110
        for i in range(FILTER_WINDOW):
111
            imga = mic.get_map()
112
            energy_data = mic.get_dir(imga)
113
            raw_angle = get_sound_angle(energy_data)
114
            angle_buffer.append(raw_angle if raw_angle is not None else 0)
115
            print("填充缓冲区 %d/%d" % (i+1, FILTER_WINDOW))
116
            time.sleep_ms(50)
117

118
        print("开始主循环...")
119
        while True:
120
            start_time = time.ticks_ms()
121

122
            # 获取原始数据
123
            imga = mic.get_map()
124
            energy_data = mic.get_dir(imga)
125
            mic.set_led(energy_data, (0, 0, 255))
126

127
            # 计算原始角度
128
            raw_angle = get_sound_angle(energy_data)
129

130
            # 应用多级滤波
131
            filtered_angle = apply_filters(raw_angle)
132

133
            # 如果本次数据无效，使用上次滤波结果
134
            if filtered_angle is None:
135
                filtered_angle = angle_buffer[-1] if angle_buffer else 0
136

137
            raw_str = str(raw_angle) if raw_angle is not None else "--"
138
            info = "原始角度: %s°  ->  滤波角度: %d°" % (raw_str, filtered_angle)
139
            info += "\n能量数据: " + str(energy_data)
140
            print(info)
141
            print("-" * 30)
142

143
            # 转换角度到舵机控制信号
144
            is_valid, duty_val = convert_angle(filtered_angle)
145

146
            if is_valid:
147
                # 有效角度，使用平滑处理
148
                target_duty = duty_val
149
                # 平滑处理：混合上次的 duty 值和本次的目标值
150
                smoothed_duty = last_valid_duty * (1 - SERVO_SMOOTH_FACTOR) + target_duty * SERVO_SMOOTH_FACTOR
151
                last_valid_duty = smoothed_duty
152
                duty_val = smoothed_duty
153
                print("有效角度，duty_val:", duty_val)
154
            else:
155
                # 无效角度范围，保持上次的有效 duty 值
156
                duty_val = last_valid_duty
157
                print("角度 %d° 在无效范围，保持上次duty值: %.2f" % (filtered_angle, duty_val))
158

159
            pwm.duty(duty_val)
160

161
            loop_time = time.ticks_diff(time.ticks_ms(), start_time)
162
            delay_time = max(10, 100 - loop_time)
163
            time.sleep_ms(delay_time)
164

165
    except KeyboardInterrupt:
166
        print("用户退出")
167
    finally:
168
        mic.deinit()
169
        pwm.duty(7.5)           # 回到中间位置
170
        print("资源已释放")
171

172
if __name__ == "__main__":
173
    init()
174
    main()

展开收起

Kruskal 算法与 Prim 算法

Wed, 25 Jun 2025 00:00:00 GMT

Kruskal 算法与 Prim 算法是图论中经典的算法，用于求解最小生成树问题。

这两个算法能干什么？打个比方：现在有 7 个城市 A B C D E F G，准备修建高铁线路，要求是在这 7 个城市中的任意一个城市坐高铁，都有一种出行方案能够到达其他任意一个城市。并且，城市与城市之间修建高铁线路的费用不一定相同。你要想一种方案，使得修建高铁线路的总费用最低。

聪明的你马上就想到了，可以把城市与城市之间的联系抽象为一个有权无向图，边的权值代表了修建高铁线路的费用。然后，你就可以用 Kruskal 算法或者 Prim 算法求解最小生成树，使得修建高铁线路的总费用最低。

本篇文章使用邻接矩阵表示无向图

Kruskal 算法#

Kruskal 算法通过贪心策略，从边权最小的边开始逐步构建生成树，确保每一步选择的边不会形成环，最终得到总权值最小的生成树。

其核心步骤如下：

将所有边按权值从小到大排序
初始化并查集
贪心选边
合并并查集
重复 2-4 直到所有边都被选过

具体实现如下：

1
// 边的数据结构
2
data class Edge(val from: Int, val to: Int, val weight: Int)
3

4
// 并查集：用于判断环、合并集合
5
class UnionFind(size: Int) {
6
    private val parent = IntArray(size) { it }
7

8
    // 查找根节点，并路径压缩
9
    fun find(x: Int): Int {
10
        if (parent[x] != x) {
11
            parent[x] = find(parent[x])
12
        }
13
        return parent[x]
14
    }
15

16
    // 合并两个集合，若已经连通返回 false
17
    fun union(x: Int, y: Int): Boolean {
18
        val rootX = find(x)
19
        val rootY = find(y)
20
        if (rootX == rootY) return false
21
        parent[rootY] = rootX
22
        return true
23
    }
24
}
25

26
// Kruskal 算法：从邻接矩阵生成边集合并构建最小生成树
27
fun kruskalFromAdjMatrix(adjMatrix: Array<IntArray>): List<Edge> {
28
    val nodeCount = adjMatrix.size
29
    val edges = extractEdgesFromMatrix(adjMatrix)
30

31
    if (edges.isEmpty()) {
32
        throw IllegalArgumentException("图中没有有效的边")
33
    }
34

35
    return kruskal(nodeCount, edges)
36
}
37

38
// 辅助函数：从邻接矩阵中提取边（避免重复）
39
fun extractEdgesFromMatrix(matrix: Array<IntArray>): List<Edge> {
40
    val edges = mutableListOf<Edge>()
41
    val n = matrix.size
42

43
    for (i in 0 ..< n) {
44
        for (j in i + 1 ..< n) {
45
            val w = matrix[i][j]
46
            if (w != 0 && w != Int.MAX_VALUE) {
47
                edges.add(Edge(i, j, w))
48
            }
49
        }
50
    }
51

52
    return edges
53
}
54

55
// Kruskal 主体：边排序 + 并查集连接
56
fun kruskal(nodeCount: Int, edges: List<Edge>): List<Edge> {
57
    val mst = mutableListOf<Edge>()
58
    val uf = UnionFind(nodeCount)
59

60
    for (edge in edges.sortedBy { it.weight }) {
61
        if (uf.union(edge.from, edge.to)) {
62
            mst.add(edge)
63
            if (mst.size == nodeCount - 1) break
64
        }
65
    }
66

67
    return mst
68
}

展开收起

以下是使用 Kruskal 算法求解图中 7 个城市的最小生成树的示例：

1
fun main() {
2
    val INF = Int.MAX_VALUE
3
    val adjMatrix = arrayOf(
4
        intArrayOf(0,  7, INF,  5, INF, INF, INF), // A
5
        intArrayOf(7,  0,  8,  9,  7, INF, INF),   // B
6
        intArrayOf(INF, 8,  0, INF, 5, INF, INF),  // C
7
        intArrayOf(5,  9, INF,  0, 15, 6, INF),    // D
8
        intArrayOf(INF, 7, 5, 15,  0, 8,  9),      // E
9
        intArrayOf(INF, INF, INF, 6, 8,  0, 11),   // F
10
        intArrayOf(INF, INF, INF, INF, 9, 11, 0)   // G
11
    )
12

13
    val mst = kruskalFromAdjMatrix(adjMatrix)
14
    val cityNames = listOf("A", "B", "C", "D", "E", "F", "G")
15

16
    println("最小花费的高铁修建方案如下：")
17
    var totalCost = 0
18
    for (edge in mst) {
19
        println("${cityNames[edge.from]} -- ${cityNames[edge.to]} : 费用 ${edge.weight}")
20
        totalCost += edge.weight
21
    }
22
    println("总花费：$totalCost")
23
}

展开收起

输出结果：

1
最小花费的高铁修建方案如下：
2
A -- D : 费用 5
3
C -- E : 费用 5
4
D -- F : 费用 6
5
A -- B : 费用 7
6
B -- E : 费用 7
7
E -- G : 费用 9
8
总花费：39

Prim 算法#

Prim 算法同样基于贪心策略，但与 Kruskal 算法不同的是，它从顶点的角度出发，逐步扩展生成树。

其核心步骤如下：

任选一个顶点作为起点，将其加入生成树集合
选择连接生成树集合与外部顶点的最小权值的边，加入生成树集合
重复 2 直到所有顶点都被加入生成树集合

具体实现如下：

1
fun prim(adjMatrix: Array<IntArray>): List<Triple<Int, Int, Int>> {
2
    val n = adjMatrix.size
3
    val visited = BooleanArray(n) { false }      // 记录已加入 MST 的点
4
    val minDist = IntArray(n) { Int.MAX_VALUE }  // 每个点到 MST 的最小距离
5
    val parent = IntArray(n) { -1 }              // 每个点在 MST 中的父节点
6

7
    minDist[0] = 0
8

9
    for (i in 0 ..< n) {
10
        // 选出未加入 MST 中、距离最小的点
11
        var u = -1
12
        var min = Int.MAX_VALUE
13
        for (j in 0 ..< n) {
14
            if (!visited[j] && minDist[j] < min) {
15
                min = minDist[j]
16
                u = j
17
            }
18
        }
19

20
        if (u == -1) break // 图不连通
21

22
        visited[u] = true
23

24
        // 用 u 点更新其他相邻点的最小距离
25
        for (v in 0 ..< n) {
26
            val weight = adjMatrix[u][v]
27
            if (!visited[v] && weight != 0 && weight < minDist[v]) {
28
                minDist[v] = weight
29
                parent[v] = u
30
            }
31
        }
32
    }
33

34
    // 构建结果
35
    val result = mutableListOf<Triple<Int, Int, Int>>()
36
    for (v in 1 ..< n) {
37
        val u = parent[v]
38
        if (u != -1) {
39
            result.add(Triple(u, v, adjMatrix[u][v]))
40
        }
41
    }
42

43
    return result
44
}

展开收起

以下是使用 Prim 算法求解图中 7 个城市的最小生成树的示例：

1
fun main() {
2
    val INF = Int.MAX_VALUE
3
    val adjMatrix = arrayOf(
4
        intArrayOf(0,  7, INF,  5, INF, INF, INF),
5
        intArrayOf(7,  0,  8,  9,  7, INF, INF),
6
        intArrayOf(INF, 8,  0, INF, 5, INF, INF),
7
        intArrayOf(5,  9, INF,  0, 15, 6, INF),
8
        intArrayOf(INF, 7, 5, 15,  0, 8,  9),
9
        intArrayOf(INF, INF, INF, 6, 8,  0, 11),
10
        intArrayOf(INF, INF, INF, INF, 9, 11, 0)
11
    )
12

13
    val cityNames = listOf("A", "B", "C", "D", "E", "F", "G")
14
    val mst = prim(adjMatrix)
15

16
    println("最小花费的高铁修建方案如下：")
17
    var totalCost = 0
18
    for ((u, v, w) in mst) {
19
        println("${cityNames[u]} -- ${cityNames[v]} : 费用 $w")
20
        totalCost += w
21
    }
22
    println("总花费：$totalCost")
23
}

展开收起

输出结果：

1
最小花费的高铁修建方案如下：
2
A -- B : 费用 7
3
E -- C : 费用 5
4
A -- D : 费用 5
5
B -- E : 费用 7
6
D -- F : 费用 6
7
E -- G : 费用 9
8
总花费：39

可以看到，Kruskal 算法与 Prim 算法求取的最终结果是一致的。

Kruskal 算法的平均时间复杂度为 O(E log E)，Prim 算法则为 O(V2)（使用邻接矩阵）或 O(E + V log V)（使用最小堆）。两者都是基于贪心策略，且都能保证构造出最优的最小生成树。Kruskal 更适合稀疏图（边数较少），而 Prim 算法（尤其使用邻接矩阵实现）更适用于稠密图（边多，点多）。

高斯-约旦消元法的 Kotlin 实现

Tue, 24 Jun 2025 00:00:00 GMT

最让我头疼的几门课已经考完试了，讲讲前几天复习线性代数的时候学到的东西

主要是一开始突发奇想，我能不能写一个 Kotlin 程序，输入矩阵，一键计算矩阵的秩，并输出其行最简形式，然后查阅资料的时候认识到了高斯-约旦消元法

高斯-约旦消元法#

高斯-约旦消元法（Gauss-Jordan Elimination）是线性代数中解线性方程组的重要方法，由德国数学家卡尔・弗里德里希・高斯（Carl Friedrich Gauss）提出，后经威廉・约旦（Wilhelm Jordan）改进完善。

高斯-约旦消元法的目标是将矩阵转换为最简行阶梯形矩阵（Reduced Row Echelon Form，简称 RREF），使得每个主元为 1，且主元所在列的其他元素全为 0。矩阵的行最简形式在求解线性方程组、求逆矩阵等问题中具有关键作用。

以下是高斯-约旦消元法的 Kotlin 实现：

1
/**
2
* 计算矩阵的行最简形式
3
* @return 矩阵的秩
4
*/
5
fun computeRREF(matrix: Array<DoubleArray>): Int {
6
    val rows = matrix.size
7
    val cols = if (rows > 0) matrix[0].size else 0
8
    var rank = 0
9
    var pivotRow = 0
10
    var pivotCol = 0
11

12
    while (pivotRow < rows && pivotCol < cols) {
13
        // 寻找当前列的主元
14
        var maxRow = pivotRow
15
        for (i in pivotRow + 1..<rows) {
16
            if (abs(matrix[i][pivotCol]) > abs(matrix[maxRow][pivotCol])) {
17
                maxRow = i
18
            }
19
        }
20

21
        // 如果当前列所有元素都是0，则处理下一列
22
        if (abs(matrix[maxRow][pivotCol]) < 1e-10) {
23
            pivotCol++
24
            continue
25
        }
26

27
        // 交换行
28
        if (maxRow != pivotRow) {
29
            val temp = matrix[pivotRow]
30
            matrix[pivotRow] = matrix[maxRow]
31
            matrix[maxRow] = temp
32
        }
33

34
        // 归一化主元行
35
        val divisor = matrix[pivotRow][pivotCol]
36
        for (j in pivotCol..<cols) {
37
            matrix[pivotRow][j] /= divisor
38
        }
39

40
        // 消元操作，使主元所在列的其他元素为0
41
        for (i in 0..<rows) {
42
            if (i != pivotRow) {
43
                val factor = matrix[i][pivotCol]
44
                for (j in pivotCol..<cols) {
45
                    matrix[i][j] -= factor * matrix[pivotRow][j]
46
                }
47
            }
48
        }
49

50
        // 处理下一行和下一列
51
        pivotRow++
52
        pivotCol++
53
        rank++
54
    }
55

56
    return rank
57
}

展开收起

主元选择#

在每一轮迭代中，算法会遍历当前列（从当前行开始），找到绝对值最大的元素作为主元。这一步称为主元选择，目的是减少浮点数计算中的舍入误差。若当前列所有元素的绝对值均小于极小值，则认为该列无主元，跳过并处理下一列。

1
// 寻找主元
2
var maxRow = pivotRow
3
for (i in pivotRow + 1 until rows) {
4
    if (abs(matrix[i][pivotCol]) > abs(matrix[maxRow][pivotCol])) {
5
        maxRow = i
6
    }
7
}
8

9
// 检查主元是否为0
10
if (abs(matrix[maxRow][pivotCol]) < 1e-10) {
11
    pivotCol++
12
    continue
13
}

行交换与归一化#

找到主元后，将其所在行与当前处理行交换，确保主元位于目标位置。随后将主元行的所有元素除以主元值，使主元变为 1，这是行最简形矩阵的基本要求。

1
// 行交换
2
if (maxRow != pivotRow) {
3
    val temp = matrix[pivotRow]
4
    matrix[pivotRow] = matrix[maxRow]
5
    matrix[maxRow] = temp
6
}
7

8
// 归一化主元行
9
val divisor = matrix[pivotRow][pivotCol]
10
for (j in pivotCol until cols) {
11
    matrix[pivotRow][j] /= divisor
12
}

消元操作#

消元是算法的关键步骤：对于每一行（除主元行外），计算当前行在主元列的元素与主元行的系数，通过线性组合将该列元素消为 0。

1
// 消元操作
2
for (i in 0 until rows) {
3
    if (i != pivotRow) {
4
        val factor = matrix[i][pivotCol]
5
        for (j in pivotCol until cols) {
6
            matrix[i][j] -= factor * matrix[pivotRow][j]
7
        }
8
    }
9
}

有了这个程序，至少让我在复习线性代数的时候方便了不少

关于 5 月 14 日在写博客时发现的代码高亮显示问题

Thu, 15 May 2025 00:00:00 GMT

昨天在写博客的时候，调用了 Prism 的 cpp 代码高亮显示：

1
<script src="https://cdnjs.cloudflare.com/ajax/libs/prism/1.29.0/prism.min.js"></script>
2
<script src="https://cdnjs.cloudflare.com/ajax/libs/prism/1.29.0/components/prism-cpp.min.js"></script>

奇怪的是，调用这两个 js 并没有让文章中的 C++ 代码高亮显示。我上网查阅了一下相关信息，从 github 仓库的 issue 里面得到了解决方法：

1
<script src="https://cdnjs.cloudflare.com/ajax/libs/prism/1.29.0/prism.min.js"></script>
2
<script src="https://cdnjs.cloudflare.com/ajax/libs/prism/1.29.0/components/prism-c.min.js"></script>
3
<script src="https://cdnjs.cloudflare.com/ajax/libs/prism/1.29.0/components/prism-cpp.min.js"></script>

原来要引用 C 语言的库才能实现 C++ 的高亮显示（悲）

我跟 wolf 讲的时候，他说：

注意： 有 c 才能 pp（

C++ 输入输出流的 operator

Wed, 14 May 2025 00:00:00 GMT

今天是朝鲜主体历114年5月14日 (喜)

说正事，马上就到期末周了，C++ 已经结课有一段时间了，这两天在复习 C++ 的基础知识。复习到运算符重载，我发现对输入输出流的重载都用友元函数，记得当时学的时候就有点疑惑，但是也没有深究。现在有时间了，我好好研究了一下。

为什么不能用普通成员函数？#

当运算符重载为成员函数时，this指针会被隐式绑定到左操作数。例如：

1
class A {
2
public:
3
    bool operator==(const A& rhs) const; // 等价于 bool A::operator==(const A* this, const A& rhs)
4
};
5
a == b; // 实际调用 a.operator==(b), 即 operator==(&a, b)

因此，成员函数重载的运算符左操作数必须是类的实例。但流运算符的左操作数是std::ostream/std::istream，这与成员函数的绑定规则冲突。

显而易见，使用友元函数是最优解。

1
class Person {
2
private:
3
    std::string name;
4
public:
5
    friend std::ostream& operator<<(std::ostream&, const Person&);
6
};
7

8
std::ostream& operator<<(std::ostream& os, const Person& p) {
9
    os << p.name;
10
    return os;
11
}

更改了文章的加载模式

Tue, 13 May 2025 00:00:00 GMT

给博客写了个 api ，用于获取所有文章。

用的是 Spring Boot 后端，第一次尝试使用 Kotlin 写一个 Spring Boot 项目，感觉还蛮舒服的（

调用 https://blog.blackcyan.top:8000/api/articles 即可获取所有文章的title、url与date

后续我可能会多写一些api，然后开放docs(其实主要也是自用？)

api 已经弃用，我会找个合适的日子把它删掉的

总结一下三月份

Mon, 31 Mar 2025 00:00:00 GMT

今年三月份，我开始系统学习SpringBoot。

我还认识了一些新的朋友，第一次在别人的群里有点存在感（感动）

我打算整一个新的兽设，然后约一个毛脸 kig… 争取在生日前做完这一切吧。

已经跟亲友确定好漫展时要跳的舞了，不知道我能不能学会（笑）

终于部署好啦

Tue, 25 Feb 2025 00:00:00 GMT

经过不懈的上网查询和与朋友讨论，我终于把网页部署好了

网站是基于Nginx搭建的，目前还只是一个简单的静态页面，主要用来放一些文章和代码，欢迎大家跟我一起探讨学习！

Kotlin 输出 HelloWorld

Sat, 18 Jan 2025 00:00:00 GMT

以下是Kotlin输出”Hello, world!”的简单代码：

1
package top.blackcyan.kt
2

3
fun main() {
4
    println("Hello, world!")
5
}

或者说，你想使用一些花里胡哨的方法：

1
package top.blackcyan.kt
2

3
val message: ListOf<String> = ["Hello ", "world!"]
4

5
message.forEach {
6
    print(it)
7
}
8
println()

也有更加花里胡哨的办法，请不要在真正的项目中这么做，会被骂（）

1
package top.blackcyan.kt
2

3
fun greeting() = "Hello"
4

5
fun String.printOut() {
6
    println("${greeting()} $this!")
7
}
8

9
fun main() {
10
    "world".printOut()
11
}