Linux内核进程创建核心：从do_fork到kernel_clone重构解析

搞内核的兄弟应该都见过这个变化5.x内核里那个经典入口do_fork悄悄退场取而代之的是kernel_clone。我最早是在翻kernel/fork.c时发现的心里还愣了一下以为代码回退到某个开发分支了。后来顺着提交记录一看才明白这不是简单的改名而是把fork/clone这一族代码做了一次系统性重构。用户态看到的fork()、vfork()、clone()内核态里天天要用的kernel_thread()最后全部收束到同一个函数上——kernel_clone。凡是跟进程、线程创建相关的疑难杂症循着调用栈追到深处最终都会站在这个函数门口。这篇文章准备把kernel_clone彻底拆开它为什么会出现、调用链怎么走、参数结构体每个字段是什么意思、copy_process内部几百行代码到底按什么顺序做了什么、以及我在实际排查中踩过的坑和用过的工具。适合刚接触内核开发、想弄懂进程创建全流程的读者也适合遇到fork类问题却不知道从哪下手的开发者。1. 从do_fork到kernel_clone一次不得不做的重构老内核里进程创建的核心入口是do_fork它的原型在相当长一段时间里保持着这种风格long do_fork(unsigned long clone_flags, unsigned long stack_start, unsigned long stack_size, int __user *parent_tidptr, int __user *child_tidptr, unsigned long tls);看起来也不算太离谱但你只要在这个函数上增加任何一个语义参数就得把整条调用链上所有上层函数全部跟着改。内核里真正会调用do_fork的地方远不止系统调用入口kernel_thread()、kthread_create()、以及后来逐渐出现的clone3准备逻辑都要跟这一长串参数对齐。参数越来越多逐个排列下去可读性下降更麻烦的是扩展成本高得离谱。5.x的重构方向很明确把参数封装进一个结构体函数只接收结构体指针。于是就有了static pid_t kernel_clone(struct kernel_clone_args *args)从do_fork到kernel_clone的改名本质是一套接口的重新设计并不是新增一个并列函数。老代码里很多do_fork的调用点全部迁移到kernel_clone逻辑一脉相承但参数从散装改成了打包。这个过程中维护者顺手把很多原本散落各处的参数合法性检查统一收口到copy_process里让进程创建的核心路径变得更清晰。举一个具体的例子。clone3系统调用落地时新增了set_tid数组、cgroup参数这类东西。如果还沿用do_fork那种散装参数风格光是兼容新旧接口就要写一堆丑陋的桥接代码。但有了kernel_clone_args结构体clone3的解析层只需要把用户传入的数据翻译成结构体字段后面所有函数零改动就能继续工作。设计者可以像搭积木一样给结构体加字段同时通过CLONE_*标志位控制哪些字段有效这让ABI的演进变得平滑很多。说句实在话初看这个改名可能觉得只是风格洁癖但深入进去会发现参数结构体化是内核接口演进里非常重要的一步棋。往小了说把一个函数的签名稳定住往大了说它决定了后续能不能安全地扩出clone3这种新接口。kernel_clone就是这一系列设计的枢纽。2. 三大入口如何汇合到kernel_clone理解kernel_clone先要搞清楚谁会调它。进程创建这件事用户态看到的接口五花八门但内核态的入口无非三大类fork/vfork/clone三个系统调用以及只供内核内部使用的kernel_thread。2.1 用户态系统调用入口以x86_64为例应用层调用fork()时glibc封装实际发起的是clone系统调用带SIGCHLD标志。内核收到__NR_clone或者老的__NR_fork、__NR_vfork之后在kernel/fork.c里分别走对应的包装函数最终都构建一个struct kernel_clone_args然后调kernel_cloneSYSCALL_DEFINE0(fork) { struct kernel_clone_args args { .exit_signal SIGCHLD, }; return kernel_clone(args); }vfork的入口也类似区别在于它会额外设置CLONE_VM和CLONE_VFORK并依然使用SIGCHLD。而clone系统调用的包装函数则要麻烦一些因为参数太多老式clone有一部分参数要从用户态栈里取这涉及用户栈访问的拷贝逻辑。这里有个很多人忽视的细节用户态fork()和vfork()在x86_64上并不一定真的走__NR_fork和__NR_vforkglibc可能直接用clone系统调用实现。内核里保留SYSCALL_DEFINE0(fork)更多是给那些确实使用老系统调用号的场景做兼容。所以你在/proc/kallsyms里看到__do_sys_clone调用频率远高于__do_sys_fork就不要觉得奇怪。2.2 clone3的现代入口clone3系统调用是后来加入的它的设计理念和clone完全不同。clone的老问题在于参数太依赖寄存器与用户栈布局不同架构上的参数传递规则不同还容易出TOCTOU类的安全问题。clone3干脆让用户态传入一个结构体指针内核先把整个结构体拷贝到内核空间再逐字段校验最后翻译成kernel_clone_argsSYSCALL_DEFINE2(clone3, struct clone_args __user *, uargs, size_t, size)注意这里的size参数。clone_args是允许扩展的新内核会定义更多字段用户态传入的size表示自己使用的结构体长度。如果用户态结构体比内核当前支持的短内核对未提供的字段自动取零如果比内核支持的长内核会校验未知标志位并拒绝。这样做既保证了向前兼容也避免了老式clone那种从用户栈现场抠参数的脆弱方式。2.3 内核态kernel_thread入口内核自己创建内核线程入口是kernel_thread()它在很多驱动里都能见到。它的实现并不复杂本质上就是组装一个kernel_clone_args然后调kernel_clonepid_t kernel_thread(int (*fn)(void *), void *arg, unsigned long flags) { struct kernel_clone_args args { .flags ((lower_32_bits(flags) | CLONE_UNTRACED) ~CSIGNAL), .exit_signal (lower_32_bits(flags) CSIGNAL), .fn fn, .fn_arg arg, }; return kernel_clone(args); }注意它在flags里强制加了CLONE_UNTRACED。这意味着内核线程创建时ptrace机制不会介入不会向调试器报告任何事件。这是内核线程与用户进程最本质的一个区别。另外一个容易错过的小点kernel_thread里.fn字段不为空。这个字段到了copy_process里会被特殊判断直接决定新任务走内核线程的初始化路径还是一个完整的用户态进程复制路径。可以说fn字段是kernel_clone_args里最“轴心”的一个开关后面讲copy_process的时候你会看到它带来的连锁差异。3. kernel_clone_args逐字段拆解想深入理解kernel_clone绕不开struct kernel_clone_args。我在5.15内核里常看到的定义大致是这样struct kernel_clone_args { u64 flags; int __user *pidfd; int __user *child_tidptr; int __user *parent_tidptr; const char *name; int exit_signal; u64 stack; u64 stack_size; u64 tls; pid_t *set_tid; size_t set_tid_size; int (*fn)(void *); void *fn_arg; };每个字段都有明确的分工下面逐个过。关于flags它继承自老do_fork的clone_flags是控制进程创建行为的总开关。所有CLONE_*标志位都汇聚在这里。后面的字段是否有效很大程度由flags里的对应位决定比如设置CLONE_CHILD_SETTID时child_tidptr才有意义设置CLONE_PARENT_SETTID时parent_tidptr才有意义。pidfd是CLONE_PIDFD标志引入的产物。用户态通过clone3创建进程时内核可以顺便返回一个代表新进程的pidfd文件描述符写进用户态地址。这个机制让进程存活状态变得可以用poll或epoll监听远比传统的waitpid异步化容易。老式clone系统调用没有专门字段放pidfd只能复用parent_tidptr的位置返回fd所以kernel_clone里一上来就要做检查if (args-pidfd (clone_flags CLONE_PARENT_SETTID)) return -EINVAL;因为CLONE_PIDFD和CLONE_PARENT_SETTID都会向用户态写入值但地址是同一个同时使用就会产生干扰内核直接拒绝这种组合。child_tidptr和parent_tidptr是给线程库用的。以NPTL为例线程创建时设置这两个地址内核在新线程首次被调度或退出时往这些地址写特定值。parent_tidptr在CLONE_PARENT_SETTID时负责把新线程的pid写回父进程指定地址child_tidptr在CLONE_CHILD_CLEARTID和CLONE_CHILD_SETTID时分别负责退出时清空、创建时写入字段这是futex机制加速线程同步的基础。name字段属于后来的扩展。它让内核线程创建时可以直接指定线程名字省去了创建后再调kthread_rename之类操作的麻烦。kthread_create路径里会用这个字段把task的可读名字在copy_process阶段就定下来。exit_signal决定子进程在退出时向父进程发送哪个信号。常规fork时它是SIGCHLD所以父进程能用wait()捡到子进程状态线程创建时它通常为0表示不产生信号子线程退出不干扰父进程的wait逻辑。kernel_clone里对exit_signal还有一个隐藏用途下面讲到ptrace事件选择时会看到。stack和stack_size用于指定用户态调度栈。线程创建时调用者往往已经准备好一块新栈这些字段告诉内核新进程的用户栈位置和大小。普通fork时栈是父进程当前栈的延续不需要这两个字段。tls字段用于CLONE_SETTLS指定新进程的线程局部存储描述符。这个字段在不同架构上的语义略有差异但整体都是把用户态线程库需要的TLS信息传递给新任务。set_tid和set_tid_size是clone3新增的能力。它允许用户指定新进程在某些层级的PID命名空间里具体使用什么PID编号。举个例子如果进程处于多级PID命名空间你可以在最内层指定一个固定PID让某些对启动顺序敏感的应用可以复现。这个字段在老式clone里完全不存在是结构体化重构之后才能安全塞进来的典型新特性。fn和fn_arg专门给内核线程用。fn就是新内核线程要执行的函数指针fn_arg是这个函数收到的参数。只要fn不为空copy_process就会放弃复制用户态地址空间转而去构建一个没有mm的内核线程。从这些字段能看出kernel_clone_args其实合并了很多原本分散在不同系统调用里的参数让进程创建的全部信息以统一结构流入同一个函数。也正因如此内核态对参数做集中校验变得容易用户态各种标志组合的合法性检查也清晰了。4. copy_process内部流水线逐段拆解kernel_clone本体代码量并不大真正干活的是copy_process。如果你把copy_process比作一条流水线kernel_clone就是流水线入口的调度员负责选择ptrace事件、处理vfork等待、把子进程加入运行队列以及向用户态写回各种返回值。下面按顺序拆这条流水线。4.1 入口检查与内核线程分支copy_process一进来先做一堆标志位合法性校验。大量CLONE_*组合是有硬性约束的比如CLONE_THREAD要求同时设置CLONE_SIGHAND和CLONE_VM因为线程组必须共享信号处理函数和内存空间。内核里这些检查写得很直白标志位组合不合法直接返回错误。紧接着是一个关键分支if (args-fn) { p-mm NULL; p-flags | PF_KTHREAD; } else { retval copy_mm(clone_flags, p); }args-fn不为空说明这是kernel_thread路径。新任务直接不设置mm并打上PF_KTHREAD标记。内核线程是没有用户地址空间的它访问用户内存时必须借用其他进程的active_mm这是调度器层面处理的事。这里不调用copy_mm等于把几百行内存复制逻辑直接跳过内核线程创建速度远快于用户进程fork这是原因之一。4.2 dup_task_struct与内核栈分配继续往下走核心步骤是dup_task_struct。这一步要为新任务分配task_struct本体、thread_info以及内核栈。老内核里thread_info常常内嵌在task_struct中内核栈则单独分配。随着CONFIG_THREAD_INFO_IN_TASK的普及很多架构把thread_info并进了task_struct内核栈改由CONFIG_VMAP_STACK机制从vmalloc区域分配。这个变化影响很大如果内核栈从vmalloc分配虚拟地址空间更大栈溢出检测更从容但也意味着fork时分配栈可能因为vmalloc空间不足而失败。dup_task_struct这一步本质上做了一次浅拷贝把父进程的task_struct内容复制一份再重置那些必须是新任务独立的字段比如tasks链表节点、pid相关结构、各种锁的初始状态等。这里没有任何用户态数据的复制性能开销主要取决于结构体大小和架构相关字段的初始化。4.3 共享与复制资源的顺序讲究copy_process中段是一连串copy_*函数它们负责决定哪些资源共享、哪些资源复制。典型顺序大约是copy_sighand、copy_signal、copy_files、copy_fs、copy_namespaces、copy_mm、copy_io、copy_thread等。为什么顺序有讲究因为后续步骤可能会失败而已经复制成功的部分需要相应清理。比如先复制信号相关结构再复制文件表如果文件表复制失败内核要能安全回滚信号结构的引用计数。这个顺序是经过长时间调试稳定下来的不是随便排的。CLONE_FILES控制是否共享文件描述符表CLONE_FS控制是否共享根目录和当前工作目录CLONE_SIGHAND和CLONE_SIGNAL控制信号处理与信号状态共享。线程组至少要共享文件表、文件系统信息、信号处理函数和内存空间这些标志位在线程创建时被glibc一次性设置好。copy_mm是用户态fork成本的主要来源。好消息是它也不会真的复制全部物理内存。在CLONE_VM未设置时copy_mm会调用dup_mm为新进程建立一份页表副本并让所有页面标记为只读且可写时复制。也就是说fork之后父子进程的虚拟地址空间内容都一样但实际物理页是共享的直到某一方写入才触发缺页中断复制页面。这就是为什么现代操作系统的fork()比大多数人想象中轻量。4.4 sched_fork与调度实体初始化copy_process还会调用sched_fork为新任务的调度器相关状态做初始化。这里做的事包括新任务初始优先级继承自父进程、task_struct里的se字段重新初始化、cgroup的调度组信息关联等。新任务还没有被唤醒状态被标记为TASK_NEW这是后续wake_up_new_task将要处理的关键状态。很多初学者会问为什么copy_process里不直接把新进程唤醒而要等回到kernel_clone里再唤醒原因是copy_process存在失败可能在它内部只负责把新任务准备好并挂入进程链表成功与否在返回后才知道。把唤醒动作放在kernel_clone的成功路径上逻辑更清晰也方便ptrace在子进程真正运行前介入。4.5 alloc_pid与进程号分配新任务必须有自己的PID。alloc_pid负责分配struct pid以及各个PID命名空间层级的编号。如果启用了多级PID命名空间还需要为每一层命名空间分配一个对应的nr值。alloc_pid失败会返回-EAGAIN这直接影响用户态fork的errno后面排查部分会展开讲。分配完PID后新任务的pid、tgid等字段会被填充。对于线程创建tgid继承自父进程的线程组IDpid则是新线程自己的编号。这就是同一个线程组里所有线程的tgid相同、pid各异的底层来源。4.6 vfork_done的巧思kernel_clone开头那段代码里有一个容易被忽略的completion变量if (clone_flags CLONE_VFORK) init_completion(vfork);这个vfork对象实际上是放在kernel_clone的栈上的。如果设置了CLONE_VFORKcopy_process末尾会把p-vfork_done指向父进程栈上的这个completion同时执行get_task_struct(p)防止子进程过早释放。子进程在执行execve()或者退出时内核会调用mm_release()其中会complete(vfork_done)把父进程从wait_for_completion_killable(vfork)里唤醒。这样vfork就实现了“子进程先运行父进程阻塞等待”的语义。vfork这名字虽然看着像“几乎不复制”但内核实现上借助了复制与共享的组合本质是等待机制的同步。4.7 尾声的cgroup与安全钩子现代内核在copy_process尾部还会调用cgroup_can_fork、cgroup_post_fork以及security_task_fork之类的钩子。这些钩子在容器场景里非常关键比如cgroup的pids控制器就可以在cgroup_can_fork阶段直接拒绝新的进程创建返回-EAGAIN。这也就是为什么你即使没到系统全局的pid_max限制也可能因为cgroup限制而fork失败。从整体看copy_process基本架构是“先浅复制再逐资源决定共享或深复制最后挂链表加钩子”。它是对老do_fork实现思路的延续但在5.x被整理得更结构化。5. copy_thread与ret_from_fork的入口魔法进程创建不是把task_struct复制完就完事新任务必须有一个明确的执行入口。这个入口的设定发生在copy_thread函数中。虽然名字带copy但它实际上是在构造新任务的初始寄存器上下文。对于用户态进程copy_thread会把父进程当前的pt_regs复制到新任务的内核栈然后把用户态的系统调用返回值寄存器改成0。这正是fork语义的底层实现父进程从内核返回到用户态时系统调用返回值是新子进程的PID子进程被切换调度后从同一个位置返回用户态时看到的是0。对于内核线程情况完全不同。copy_thread检测到PF_KTHREAD标志后不再复制父进程的寄存器而是清零寄存器上下文并把fn和fn_arg放到特定位置将新任务的thread.sp指向一个统一的启动路径。这个路径在x86_64上叫ret_from_fork。ret_from_fork从字面理解就是“从fork返回”但它面对的任务类型不同后续路径也不同。对于普通用户进程它负责调用schedule_tail完成调度器收尾然后切换回用户态对于内核线程它从栈上取出fn和fn_arg跳转到fn(arg)执行等fn返回后再调用do_exit清理线程栈。这个设计非常精妙。内核线程不自己负责退出清理它的函数fn只要正常返回ret_from_fork路径会自动兜底。很多写内核线程模块的开发者容易忽略这一点以为自己得在fn里手动do_exit其实不需要但如果确实需要带退出码退出也可以显式调用do_exit(code)。6. 实机观察kernel_cloneftrace、kprobe与内核模块理论讲了这么多不亲手观察一遍总觉得隔了一层。如果是5.x内核下面这几招都可以直接在自己机器上试。6.1 用ftrace看kernel_clone调用树最直观的方式是function graph跟踪。挂载tracefs并把kernel_clone设为跟踪目标mount -t tracefs tracefs /sys/kernel/tracing echo kernel_clone /sys/kernel/tracing/set_graph_function echo function_graph /sys/kernel/tracing/current_tracer echo 1 /sys/kernel/tracing/tracing_on然后在另一个终端随便执行一个会fork的命令比如bash -c echo hello。过一会儿来看跟踪结果cat /sys/kernel/tracing/trace | grep -A 80 kernel_clone你会看到kernel_clone调用了copy_process而copy_process内部又展开一系列子调用dup_task_struct、copy_files、copy_mm、alloc_pid等全都清晰可见。这比单纯读源码更能建立整体直觉。如果你用的一些发行版默认没开CONFIG_FTRACE或者符号不可见可以试试先查一下cat /sys/kernel/tracing/available_filter_functions | grep kernel_clone有输出就能挂。6.2 用kprobe事件直接抓参数知道kernel_clone第一个参数是struct kernel_clone_args *后可以在x86_64上用kprobe抓它的参数。这里有个小坑flags在结构体的第一个字段所以首先可以试试直接取args-flags。不过tracefs的kprobe语法对结构体偏移不够友好更省事的做法是直接用bpftracebpftrace -e kprobe:kernel_clone { printf(comm%s flags0x%llx fn%p\n, comm, ((struct kernel_clone_args *)arg0)-flags, ((struct kernel_clone_args *)arg0)-fn); }如果内核开了BTF这种结构体字段访问可以直接工作。没开BTF就用最朴素的方案只打印arg0指针值bpftrace -e kprobe:kernel_clone { printf(kernel_clone called from %s, args%p\n, comm, arg0); }注意普通用户需要root权限或者给bpftrace配置capability。内核函数名是否可见也受符号表影响但kernel_clone是全局符号大多数内核配置下都能抓到。6.3 用一个最小内核模块验证kernel_thread如果只是静态读源码对fn路径的理解始终有点抽象。我习惯写一个最简模块来验证// SPDX-License-Identifier: GPL-2.0 #include linux/module.h #include linux/kthread.h #include linux/delay.h static int test_fn(void *data) { pr_info(test kernel thread running, pid%d mm%p\n, current-pid, current-mm); return 0; } static int __init test_init(void) { pid_t pid; pr_info(module init, calling kernel_thread\n); pid kernel_thread(test_fn, NULL, CLONE_FS | CLONE_FILES | CLONE_SIGHAND); pr_info(kernel_thread returned pid%d\n, pid); return 0; } static void __exit test_exit(void) { pr_info(module exit\n); } module_init(test_init); module_exit(test_exit); MODULE_LICENSE(GPL);编译加载后看dmesg你应该会看到内核线程打印出来的pid是一个新分配的内核线程号mm为NULL。这个实验能帮你确认PF_KTHREAD路径下mm确实为空。注意模块里不需要额外做线程清理test_fn返回后内核会自动走do_exit。7. 常见问题与排查实录这类代码的坑往往出现在真实场景里。我挑几个自己或同行实际踩过的问题按现象、原因、排查顺序来写。7.1 fork频繁返回EAGAIN最典型的故障表现是应用层fork()失败errno为EAGAIN日志里能看到Resource temporarily unavailable。第一反应是看系统级限制cat /proc/sys/kernel/threads-max、cat /proc/sys/kernel/pid_max、ulimit -u。但很多情况下这三个值都正常问题出在cgroup的pids控制器上。容器环境下/sys/fs/cgroup/pids.max可能设了上限一旦达到上限cgroup_can_fork会直接拒绝新任务。copy_process里alloc_pid失败、dup_task_struct失败、cgroup限制、RLIMIT_NPROC限制都会映射到-EAGAIN。排查时不要只看应用层日志先dmesg -T翻一遍内核日志。如果看到fork: Cannot allocate memory字样十有八九是内核栈或task_struct分配问题继续看有没有vmalloc: allocation failure。如果什么内核日志都没有那多半是cgroup或rlimit这类用户可配置的限制。7.2 CONFIG_VMAP_STACK与内核栈分配失败5.x内核普遍启用了CONFIG_VMAP_STACK新任务的内核栈从vmalloc区域分配。vmalloc虽然能分配比直接映射区更大的虚拟地址空间但它不是无限的。一个典型的故障是线程数量达到数万级别时新线程创建突然失败dmesg里出现vmalloc: allocation failure。原因往往不是物理内存不够而是vmalloc虚拟地址空间耗尽或者碎片化。kernel_clone对新进程中dup_task_struct这一步返回-ENOMEM用户态看到fork失败。这种情况下解决办法是降低单机线程密度或者检查是否有内核态内存泄漏反复申请大块vmalloc区域。用grep Vmalloc /proc/meminfo可以大致估算使用水线。7.3 kernel_thread回调里的操作限制写内核线程模块最常踩的坑是在fn函数里直接操作用户态内存。内核线程没有mmcurrent-mm是空的copy_to_user/copy_from_user这类接口会直接失败。正确的做法是临时借用目标进程的mm先get_task_mm拿引用再kthread_use_mm绑定用完kthread_unuse_mm并mmput释放。还有一个细节kernel_thread创建的线程和父内核线程之间文件表、文件系统信息、信号处理是否共享完全取决于调用时传的flags。常见习惯是传CLONE_FS | CLONE_FILES | CLONE_SIGHAND让内核线程随父线程共享这些资源。如果什么都不传新线程会有一整套独立副本虽然也能工作但可能带来意外的资源开销和语义差别。7.4 ptrace事件与信号设置的关联调试器有时会把fork事件报告成clone事件或者反过来。原因藏在kernel_clone对trace类型的选择逻辑里if (!(clone_flags CLONE_UNTRACED)) { if (clone_flags CLONE_VFORK) trace PTRACE_EVENT_VFORK; else if (args-exit_signal ! SIGCHLD) trace PTRACE_EVENT_CLONE; else trace PTRACE_EVENT_FORK; }这里判断标准不是“是不是线程”而是exit_signal是否等于SIGCHLD。如果调用者用clone创建了一个exit_signal不是SIGCHLD的进程ptrace会把它当作clone事件处理。反过来如果一个线程创建时带了SIGCHLD它会被报告成fork事件。遇到这类现象回来看这个判断逻辑就能对号入座。7.5 clone3与传统clone的兼容问题某些glibc版本会优先尝试clone3只有在内核返回ENOSYS时才回退到clone。如果你自编译内核时把clone3相关配置关了或者用了老一代内核用户态应用可能偶发创建进程失败但也可能完全无感取决于glibc的fallback覆盖是否完整。排查时可以用strace -f -e traceclone,clone3直接看应用实际发起了哪个系统调用避免在内核日志里瞎猜。8. 一点实操心得最后分享一个我个人用起来很顺手的技巧。如果你怀疑某次进程创建卡在了kernel_clone的某一段又不想重新编译内核加日志那就用ftrace的function_graph同时挂上kernel_clone和copy_process再复现一次现场。不要急着去翻源码先用工具把实际调用路径固定下来。对比成功和失败两份trace的差异点往往一眼就能看出是卡在copy_mm、alloc_pid还是cgroup钩子上。另一个体会是读这种大函数时千万不要从头到尾顺序硬啃。先抓住三个关键分支args-fn是否为空、CLONE_VFORK是否设置、CLONE_THREAD和CLONE_SIGHAND等组合标志的共享关系剩下的细节再顺着调用图展开。把这几条主线理清后copy_process那几百行代码就变得有脉络可循。