VSCode + clangd：Linux 内核源码阅读与模块调试环境搭建

用 VSCode 来读 Linux 内核、写内核模块这件事，我从最早靠 grep 加 vim 硬扛，到中间试过 Source Insight、Eclipse CDT、KDevelop，最后稳定在 VSCode 这套组合上，前后换了三四轮配置。Linux 内核这份代码的体量摆在那儿——单是 x86 主线就有六万多个 C 文件和头文件，交叉引用密得像蛛网，纯靠字符串搜索翻代码，翻一天下来脑子是糊的。所以我在意的从来不是“能不能跳转”这种及格线问题，而是三个更实际的点：跳转准不准、索引重建快不快、调试时能不能把断点直接打进内核里。这篇内容就是把这套环境的搭建思路、插件选型、索引生成参数、模块开发流程和一堆踩过的坑一次性摊开讲清楚，适合刚准备读内核源码的同学，也适合已经在写驱动但还在用老 IDE 的朋友。配置基本都是可复制粘贴的，参数我也会说明为什么这么填。

1. 内核代码阅读的真实难点与环境方案选型

1.1 为什么普通 C 工程那套办法在内核上会失灵

在用户态写 C 程序，你只要把编译命令交给 c_cpp_properties.json 或者 compile_commands.json，智能提示基本就到位了。内核不一样，它有几个特性会直接把常规做法打穿。第一个是宏密度极高，SYSCALL_DEFINE系列、EXPORT_SYMBOL、__init、module_init这些宏层层嵌套，同一份代码在预处理器展开前后完全是两张脸，索引器如果拿不到正确的宏定义，跳转就会断在半路。第二个是同一份源码要跑几十种架构和几百种配置组合，#ifdef CONFIG_SMP这类条件编译分支在你眼里的“有效代码”其实跟你选的 defconfig 强相关，配置不对，索引出来的引用关系就是错的。

第三个麻烦是构建产物污染。内核原地编译之后目录里会塞进几万个.o、.cmd、.mod文件，如果不做排除，VSCode 的文件搜索和文件监听都会被拖慢，有时候打开一个目录要转十几秒硬盘。我最早没做排除，Ctrl+P找文件时列表里一半是编译中间件，体验非常糟。所以这套环境的搭建顺序应该是：先确定在哪跑内核、再把构建配置固定下来、然后才生成索引、最后才是配置编辑器的各种体验项。顺序错了，后面就是反复重建索引的无底洞。

1.2 三种运行环境方案的实际取舍

内核开发必须在 Linux 上做，没有例外。VSCode 只是编辑器，编译、加载模块、跑 QEMU 都得落到真正的 Linux 环境。摆在你面前的基本是三条路，我三个都用过，各自的账算下来差别挺大。

如果你只是读代码、跑编译、偶尔写个模块做实验，我个人最推荐 Remote-SSH 到一台 Linux 机器或者直接用 WSL2，理由是宿主机的图形界面和浏览器不会被编译任务拖卡。但要注意一个细节：Remote-SSH 模式下源码必须放在远端文件系统里，别用本地挂载的方式打开，否则 clangd 的索引 IO 全部走网络，后台索引一次能卡到你怀疑人生。WSL2 也一样，源码放/home/xxx/下面，不要放/mnt/c/，跨文件系统的元数据操作慢一个数量级，这是实测出来的差距。

注意：不要为了“看起来干净”把内核源码放在 NTFS 或者网络共享盘上编译。内核构建过程会创建大量小文件，跨文件系统那层开销会被放大得很明显。

2. 从零搭起可用的阅读环境

2.1 工具链与源码准备

先把编译内核需要的东西装齐。以 Debian/Ubuntu 系为例，一套常用的组合是build-essential、flex、bison、libelf-dev、libssl-dev、bc、dwarves、pahole、cppcheck、universal-ctags、cscope、clang、lld、llvm、gdb、qemu-system-x86。这里面dwarves和pahole是给 BTF 用的，很多新版本内核默认开了CONFIG_DEBUG_INFO_BTF，缺了会编译报错；universal-ctags和cscope是给传统索引方案兜底的；llvm这一套是给 clangd 提供驱动的。

源码获取就是标准的 git 流程，建议不要用 tarball，用 git 才能做版本对比和 blame。克隆的时候用浅克隆重磅仓库能省不少时间，比如--depth=1 --branch v6.6这种；但如果你需要看历史演进、做git log -p追 bug，那就老老实实全量克隆，第一次慢一点，后面省事。我一般会把源码放在~/work/linux这种短路径下，路径太深会让某些工具的输出难读，编译报错时绝对路径太长也不方便复制。

内核版本的选择有个经验：读代码用稳定版主线的最新 tag，写驱动做实验用你目标平台对应的 LTS 版本，两者最好分开，别混在一个目录里。原因很简单，主线版本 API 变动快，你今天照着文档写的模块，下个版本可能register_chrdev的用法就变了；而 LTS 版本相对稳定，社区文档和第三方资料也更多。我习惯建两个目录，linux-mainline和linux-lts，VSCode 里开两个工作区，互不干扰。

2.2 索引方案的两条路线：传统 tags 与 clangd

内核从很早以前就内置了索引生成的支持，make tags生成 ctags 文件，make cscope生成 cscope 数据库，两个可以一起跑。这套方案的优势是生成快、内存占用小，几千万行的代码两分钟到十几分钟能出结果，跳转定位到符号定义这一层级很够用。劣势也很明显：它本质是符号索引，不知道类型，做不了“跳转到具体实现的重载”“找某个结构体成员的所有读写点”这类语义操作。

clangd 走的是另一条路，基于编译数据库做真正的语义分析。前提是你得先有compile_commands.json。内核源码树里带了工具可以生成它：scripts/clang-tools/gen_compile_commands.py。用法是先配置并完整编译一次，然后跑：

cd ~/work/linux-mainline make defconfig make -j$(nproc) # 完整编译一次，生成 .cmd 文件和编译命令 python3 scripts/clang-tools/gen_compile_commands.py -d .

它会在源码根目录生成compile_commands.json。这个文件可能有几十兆到上百兆，是 clangd 的唯一依据。注意 clangd 只会解析这个文件里列出的编译单元，也就是说你没编译过的文件、没被任何目标引用的文件，它不认识。所以“先编译”这一步不能省。

两种方案我的实际做法是并行存在，用 clangd 做主力跳转和补全，用 ctags 做快速全局符号搜索，用git grep或 ripgrep 做兜底字符串匹配。三者互补：clangd 精准但偶尔失灵，grep 笨但永远不会骗你。

2.3 插件组合与关键配置项

VSCode 侧我装的插件不多，装多了互相抢功反而慢。核心几个是：clangd（LLVM 官方那个）、C/C++（微软的，主要用来跑 GDB 调试前端）、Remote - SSH 与 WSL、GitLens、EditorConfig。这里有一个非常关键的点，很多人踩过：clangd 和微软 C/C++ 扩展的 IntelliSense 会打架，两个都想提供补全和跳转，结果是补全列表里两套结果混在一起，跳转经常跳到错误的地方。

解决办法是在工作区的.vscode/settings.json里把 C/C++ 的 IntelliSense 引擎关掉，只保留它作为调试器前端的功能：

{ "C_Cpp.intelliSenseEngine": "disabled", "clangd.arguments": [ "--background-index", "--background-index-priority=normal", "--clang-tidy=false", "--completion-style=detailed", "--header-insertion=never", "--query-driver=/usr/bin/clang-*,/usr/bin/gcc-*", "--compile-commands-dir=${workspaceFolder}", "--pch-storage=memory", "--limit-results=50", "-j=6" ], "files.watcherExclude": { "**/.git/objects/**": true, "**/*.o": true, "**/*.cmd": true, "**/*.mod": true, "**/kernel/**": false }, "search.exclude": { "**/*.o": true, "**/*.cmd": true, "**/*.mod.c": true, "**/.tmp_*": true } }

-j控制后台索引的线程数，我通常设成物理核心数的三分之一到一半，因为索引跑起来很吃内存和 CPU，设太狠会把你正常的编辑操作卡住。--clang-tidy=false是我故意关的，内核代码里大量宏和非常规写法会让 clang-tidy 刷出一堆噪音警告，而它带来的开销却不小；如果你确实想用静态检查，建议单独配 pre-commit 去跑，别挂在编辑器里。

提示：--pch-storage=memory在内存足够（32G 以上）时能明显加快补全响应，但如果你的机器只有 16G，建议改成--pch-storage=disk，否则索引过程中可能出现内存压力导致编辑器无响应。

3. clangd 索引的深水区配置

3.1 .clangd 配置文件与编译参数补全

compile_commands.json是内核构建系统生成的，它记录的编译命令里带有-D__KERNEL__、-I一堆头文件路径、-mno-sse、-fno-stack-protector这类参数。大多数时候 clangd 直接吃这个文件就够了，但内核有些写法会让它犯迷糊，典型的是asm goto、内联汇编、以及部分 GCC 扩展。遇到这种情况可以在源码根目录放一个.clangd文件做补充：

CompileFlags: Add: - -Wno-everything - -D__KERNEL__ - -DKBUILD_MODNAME="dummy" Remove: - -mabi=* - -fconserve-stack - -fno-var-tracking-assignments Diagnostics: Suppress: - unknown-argument - invalid-argument

Remove那几条是实战总结出来的：某些 GCC 特有的参数 clang 不认，会直接报错并导致这个编译单元索引失败，表现出来就是“这个文件完全没补全”。把不认识的参数剔掉，索引成功率会高很多。另外-Wno-everything是压掉诊断噪音的，内核代码风格本来就通不过 clang 的默认检查，你不需要靠编辑器来告诉你这些。

还有一个容易被忽略的点：--query-driver参数。clangd 需要知道系统上有哪些编译器驱动，才能从驱动里反查出系统头文件路径。如果你用的是 clang 编译内核，把/usr/bin/clang-*写上；如果用的是 gcc，就写/usr/bin/gcc-*。少了这一条，#include <linux/...>之外的很多标准头会解析不了，补全里出现一堆红波浪线。

3.2 索引体积、重建时机与多配置共存

.cache/clangd/index/这个目录在内核上跑一次完整后台索引，体积通常在 3 到 10 GB 之间，取决于你开了多少配置项。它默认生成在源码根目录下，所以第一件事是把.cache/加进.gitignore，别不小心提交上去。第二件事是搞清楚什么时候会触发重建：你改了compile_commands.json、切换了 git 分支导致大量文件变动、或者手动删了缓存目录，都会触发重建。一轮完整索引在 8 核机器上大概十几到几十分钟，期间补全会有降级，这是正常的。

如果你同时维护多个配置（比如 defconfig 和某个自定义的调试配置），不要指望一份compile_commands.json覆盖全部。我的做法是用目录区分：构建产物放build/defconfig/，make O=build/defconfig defconfig && make O=build/defconfig -j$(nproc)，然后在gen_compile_commands.py里指定这个输出目录。生成出来的编译数据库可以放在固定位置，用--compile-commands-dir指过去，切换配置时改一下这个参数再重启 clangd 就行。

还有一种情况是做跨版本对比阅读，比如 v5.15 到 v6.6 的某个子系统改动。这时候别在两个版本目录里都开 clangd 后台索引，内存扛不住。我的办法是只在主版本开 clangd，另一个版本用 ctags 加 cscope 顶着，需要深挖的时候再临时切。说实话，跨版本对比这种活儿，git log --follow配合git diff v5.15..v6.6 -- path/to/dir比在编辑器里来回翻效率高得多。

3.3 跳转不准的几类典型原因

跳转不准这件事，九成不是 clangd 的锅，是配置问题。我把最常见的几种情况列一下，遇到了可以按这个顺序排查。

第一类是SYSCALL_DEFINE这种宏生成函数。内核里系统调用的实现是用宏拼出来的，找不到直接的函数定义是正常现象，clangd 对宏展开后的跳转支持有限。这种时候直接用grep -rn "SYSCALL_DEFINE.*openat"反而更快，或者去arch/x86/entry/syscalls/syscall_64.tbl里看系统调用号和名字的对应关系，再从include/linux/syscalls.h的声明跳到实现。

第二类是同一符号有多个定义点，比如struct file_operations的成员read，全内核有几千个实现。clangd 给的引用列表是准的，但需要你自己按路径过滤。这时候在引用面板上方用路径关键词过滤，比一个个点开看快。

第三类是头文件里的#ifdef分支没生效。你看到的代码是灰的，跳转也点不动，说明当前编译单元没定义那个宏。回去检查compile_commands.json里对应文件的命令，看看-D是否和你的预期一致，通常是配置裁剪掉了相关功能。

提示：遇到“某个文件完全没有补全”的情况，先看 VSCode 底部状态栏的 clangd 图标，点开看它加载了哪个 compile_commands 文件，再看输出面板里 clangd 的日志有没有报错。大多数“莫名其妙不好用”都能在这里找到答案。

4. 在内核里写代码：模块开发与调试实操

4.1 模块骨架与 Makefile 的正确写法

读代码和写代码是两个层次的技能，读懂了不代表能写对。我建议找一个简单的字符设备模块作为练手对象，它能把file_operations、cdev、register_chrdev、module_init/exit这几个核心概念串起来。先看骨架：

// hello_char.c #include <linux/module.h> #include <linux/fs.h> #include <linux/cdev.h> #include <linux/uaccess.h> #define DEV_NAME "hello_char" static dev_t devno; static struct cdev hello_cdev; static int hello_open(struct inode *inode, struct file *filp) { pr_info("%s: open, pid=%d\n", DEV_NAME, current->pid); return 0; } static ssize_t hello_read(struct file *filp, char __user *buf, size_t count, loff_t *ppos) { static const char msg[] = "hello from kernel\n"; size_t len = sizeof(msg) - 1; if (*ppos >= len) return 0; if (count > len - *ppos) count = len - *ppos; if (copy_to_user(buf, msg + *ppos, count)) return -EFAULT; *ppos += count; return count; } static ssize_t hello_write(struct file *filp, const char __user *buf, size_t count, loff_t *ppos) { pr_info("%s: write %zu bytes\n", DEV_NAME, count); return count; } static int hello_release(struct inode *inode, struct file *filp) { return 0; } static const struct file_operations hello_fops = { .owner = THIS_MODULE, .open = hello_open, .read = hello_read, .write = hello_write, .release = hello_release, }; static int __init hello_init(void) { int ret = alloc_chrdev_region(&devno, 0, 1, DEV_NAME); if (ret) return ret; cdev_init(&hello_cdev, &hello_fops); hello_cdev.owner = THIS_MODULE; ret = cdev_add(&hello_cdev, devno, 1); if (ret) { unregister_chrdev_region(devno, 1); return ret; } pr_info("%s: major=%d minor=%d\n", DEV_NAME, MAJOR(devno), MINOR(devno)); return 0; } static void __exit hello_exit(void) { cdev_del(&hello_cdev); unregister_chrdev_region(devno, 1); pr_info("%s: bye\n", DEV_NAME); } module_init(hello_init); module_exit(hello_exit); MODULE_LICENSE("GPL"); MODULE_AUTHOR("me"); MODULE_DESCRIPTION("a minimal char device for learning");

这段代码里每一行都值得单独展开。alloc_chrdev_region是让内核动态分配一个主设备号，比硬编码一个主设备号靠谱得多，硬编码容易和其他驱动撞号；cdev_init把file_operations绑定到cdev上，这一步是“用户态系统调用怎么落到你的函数”这个链路的关键节点；cdev_add才是真正把设备注册进内核。清理顺序必须和初始化顺序相反，先cdev_del再unregister_chrdev_region，顺序反了会有一小段窗口期设备号已经被回收但 cdev 还挂着，属于典型的资源管理 bug。

配套的 Makefile 就几行：

obj-m := hello_char.o KDIR ?= /lib/modules/$(shell uname -r)/build PWD := $(shell pwd) all: $(MAKE) -C $(KDIR) M=$(PWD) modules clean: $(MAKE) -C $(KDIR) M=$(PWD) clean

外挂模块（out-of-tree module）有个坑：这样编译出来的模块，clangd 是看不到编译命令的，因为compile_commands.json是内核树内部生成的。想让它也能跳转，有两个办法。一是把模块源码直接放进内核树里，比如丢到drivers/char/或者samples/下面，改一下对应的 Kconfig 和 Makefile，重新生成编译数据库，索引就能覆盖到。二是用bear -- make或compiledb这类工具拦截真实执行的编译命令，生成一份独立的compile_commands.json，然后单独开一个工作区指向它。我个人更推荐第一种，虽然要动内核树的文件，但对索引最友好，而且能顺带练习写 Kconfig。

4.2 顺着 file_operations 把读写路径读通

写完模块之后再回头读内核里读写路径的代码，感受完全不一样。用户态调一次read()，内核里走的链路大致是：__x64_sys_read进入ksys_read，找到struct file对应的f_op，然后调vfs_read（新版本已经合并进ksys_read的展开逻辑），最终落到file->f_op->read或者file->f_op->read_iter。write同理，ksys_write到vfs_write再到f_op->write_iter。这条链路是理解整个文件系统的入口，把struct file、struct inode、struct file_operations这三个结构体的关系搞清楚，后面看具体文件系统就不会迷路。

read_iter和write_iter这两个成员是关键分水岭。老接口read/write每次调用都要处理用户态缓冲区的拷贝语义，新接口read_iter/write_iter接受struct kiocb和struct iov_iter，天然支持向量 IO 和异步 IO，性能也更好。你现在去看内核里的新代码，绝大多数驱动和文件系统都只实现_iter版本，read/write只作为兼容路径存在。我第一次看iov_iter的时候完全不懂那几个ITER_*类型有什么区别，后来把lib/iov_iter.c里的copy_page_to_iter系列函数读完才理清楚：它本质上是在描述“数据要往哪搬”，是内核地址、用户地址还是 pipe 或者 bvec，不同类型走不同的拷贝函数。

想更快地建立整体印象，可以配合几个工具用。ftrace打开function_graph，过滤vfs_read或者vfs_write，跑一次用户态程序，你就能拿到一条带时间戳的完整调用链，比自己静态翻代码直观得多。命令大致是echo vfs_read > set_graph_function、echo function_graph > current_tracer，然后在trace文件里看结果。这套东西调试驱动的时候特别好用，比到处插printk再重新编译模块快得多。

注意：调试用的printk记得带模块名前缀和日志级别，比如pr_info、pr_err，不要裸用printk不加级别。模块一多，dmesg里全是无主日志，排查时会很痛苦。

4.3 QEMU 加 GDB 把断点打进内核

模块开发真正上强度的是调试环节。在物理机上调试内核风险大，一个死锁或者空指针就把机器搞挂了，而且Oops信息刷完屏幕就没法回看。标准做法是用 QEMU 跑一个自己编译的内核，通过 GDB 远程连接，全程可控。

先准备内核配置，关键是打开调试信息：

cd ~/work/linux-mainline make defconfig scripts/config --enable DEBUG_INFO \ --enable DEBUG_INFO_DWARF5 \ --enable DEBUG_KERNEL \ --enable GDB_SCRIPTS \ --enable KASAN \ --enable DEBUG_FS make -j$(nproc)

DEBUG_INFO是必须的，没有它 GDB 读不到符号。GDB_SCRIPTS会生成vmlinux-gdb.py，提供lx-symbols、lx-dmesg这类内核专用命令，能直接打印内核结构体链表，非常好用。KASAN是内存检测，写驱动阶段强烈建议开着，越界访问和 use-after-free 会第一时间报出来，比事后靠经验猜强太多。

然后启动 QEMU：

qemu-system-x86_64 \ -kernel arch/x86/boot/bzImage \ -append "console=ttyS0 root=/dev/ram rdinit=/init nokaslr" \ -initrd ~/images/rootfs.cpio.gz \ -nographic -s -S -m 2G \ -virtfs local,path=$HOME/share,mount_tag=host0,security_model=none

这里有三个点得解释清楚。-s -S是-gdb tcp::1234加“启动时暂停”的组合，QEMU 会停在第一条指令等你连接调试器。nokaslr绝对不能省，内核地址随机化开着的时候 GDB 拿到的符号地址和实际运行地址对不上，断点会全部失效，这个坑我踩过一次，找了两个小时才发现是 KASLR。-virtfs是 9p 共享目录，把宿主机的一个目录挂进 guest，编译好的.ko模块放这里，guest 里mount -t 9p -o trans=virtio host0 /mnt就能直接insmod，省掉制作镜像的步骤来回复制，效率提升非常明显。

VSCode 侧配一个 launch.json：

{ "version": "0.2.0", "configurations": [ { "name": "kernel-debug", "type": "cppdbg", "request": "launch", "program": "${workspaceFolder}/vmlinux", "miDebuggerServerAddress": "localhost:1234", "miDebuggerPath": "/usr/bin/gdb", "stopAtConnect": true, "setupCommands": [ { "text": "set auto-load safe-path /" }, { "text": "source ${workspaceFolder}/vmlinux-gdb.py" }, { "text": "-enable-pretty-printing", "ignoreFailures": true } ] } ] }

set auto-load safe-path /是让 GDB 允许加载vmlinux-gdb.py，默认安全策略下它会被拒绝加载，症状就是lx-symbols命令不存在。连接之后第一次要在 GDB 控制台手动执行lx-symbols，它会扫描所有已加载模块的符号；之后每次insmod新模块，都要再执行一次lx-symbols才能给新模块下断点。这个细节文档里写得含糊，我第一次用的时候在模块函数上下断点一直失败，就是漏了这一步。

整个流程跑通之后，你可以像调试用户态程序一样，在内核函数上打断点、看变量、单步执行。我最常用的是在hello_open里下断点，然后 guest 里cat /dev/hello_char，看current->pid、filp->f_pos这些值怎么变。这种“看得见”的学习效率，比读十遍文档都高。

5. 常见故障排查与长期使用习惯

5.1 索引与性能类问题速查

环境搭起来之后，日常遇到的问题基本集中在几个固定模式上。我整理了一张速查表，基本上覆盖了我这两年遇到的大部分情况。

这里我想单独说一下“索引完成后变慢”这个现象。clangd 的后台索引是会持续跟踪文件变动的，如果你在用git checkout切分支，或者频繁make产生大量文件变动，它会不停地重新索引。我的习惯是编译期间把 VSCode 的工作区暂时切到别的窗口，编译完再切回来；另外把.git目录和构建输出目录整个排除掉，减少文件监听压力。这些都是小动作，但一天下来省的时间相当可观。

5.2 编译与模块加载类问题

模块加载报错是最常见的入门障碍，insmod出来的错误信息往往很简洁，需要你配合dmesg才能定位。几个高频情况：Unknown symbol in module一般是依赖的符号没有被导出，或者依赖的模块还没加载，用modinfo看依赖、modprobe替代insmod可以自动处理依赖关系。Operation not permitted通常是模块签名校验没关或者内核开了强制签名，调试阶段用自己编译的内核就好，别在发行版自带的签名内核上折腾。Invalid module format十有八九是版本不匹配，用vermagic对比模块和内核对一下。

还有一类问题是内核配置裁剪掉了你需要的功能。比如你写的模块用了class_create相关的接口，但配置里把CONFIG_CLASS那套关掉了，编译能过但加载失败。这种情况看dmesg最后几行，通常会明确告诉你缺什么。我的习惯是在开发阶段用defconfig全量配置，等模块稳定了再逐步裁剪，避免一边调试逻辑一边排查配置。

提示：dmesg -w挂一个终端常驻，配合dmesg -T显示人类可读时间戳，比每次手动敲命令看日志顺手得多。模块加载失败时把最后 20 行贴出来，几乎都能直接搜到答案。

5.3 我自己的阅读路线和一些长期习惯

最后聊点方法层面的东西。内核这么大，没有路线图是读不动的。我建议的顺序是：从init/main.c的start_kernel开始，先看初始化流程怎么把各个子系统拉起来；然后看kernel/sched/理解调度；接着挑一个你感兴趣的子系统深入，比如fs/或者net/；最后再回头看驱动模型和总线框架。这个顺序的好处是先建立全局视角，再看局部细节，不容易迷路。

工具层面有几个习惯我坚持了很久，收益很大。一是给源码树配一个全局的tags并且定期重建，用:tag或者 VSCode 的 Go to Symbol 快速跳定义。二是善用git blame，看到一段奇怪的代码先看是哪次提交、什么原因改的，commit message 里经常有背景说明，比猜强。三是遇到不懂的结构体，用 pahole 看它的内存布局和 padding，理解对齐规则对性能分析很有帮助。四是写模块的时候坚持一个模块只做一件事，日志带统一前缀，退出路径和初始化路径严格对称。

这套环境搭一次大概两三个小时，之后能稳定用很多年。真正花时间的从来不是配置本身，而是搞清楚每个参数背后的意图——为什么要nokaslr、为什么索引要先编译、为什么_iter接口会取代老接口。这些“为什么”搞明白了，换一台机器、换一个内核版本，你都能很快把环境重建起来，而不是每次都从零搜配置。