企业官网建设流程全解析

简介：操作系统进程管理实验的C语言实现资源，面向高校操作系统课程学生及需要完成课程设计的开发者，覆盖进程创建、撤销、同步、通信、调度及死锁处理等核心实验内容。压缩包为RAR格式，共9个文件，包含源码文件、头文件、编译生成的目标文件、可直接运行的程序，以及工程配置文件，整体仅19KB，便于分发和快速部署。已有4169人学习浏览，验证了其实用价值。资源通过fork、exec、wait等系统调用演示进程生命周期管理，并涉及信号量、管道、消息队列等同步通信手段，以及先来先服务、短进程优先、时间片轮转等调度算法的实现思路；代码可直接运行观察效果，也可二次修改以适配不同实验要求，有助于从代码层面理解操作系统进程管理机制，适合实验报告撰写与答辩准备。

1. 操作系统进程管理实验：把黑匣子拆成可复现的 C 代码

操作系统这门课里，进程管理是最容易让人挂科的章节之一。课本上 fork() 创建进程、FCFS 和 SPF 调度、信号量 PV 操作，概念都配了流程图，但真要自己写代码跑一遍，很多人第一反应是无从下手。这份 ProcessControl 实验资源把进程控制块、就绪队列和三种调度算法用 C 语言完整落地，压缩包里是 Code::Blocks 工程文件、头文件加 main.c 入口，配置好编译器就能编译运行。适合正在上操作系统实验课、被进程调度报告逼到墙角的本科生，也想用代码验证课本结论的自学者，还有准备面试前快速过一遍进程生命周期和调度实现的求职者。看完这篇，你能搞懂每个文件的作用、调度参数怎么设、以及最容易翻车的地方。

2. 拆包 ProcessControl：文件清单、工程结构与编译环境三件事

2.1 压缩包里每个文件干什么：.cbp 不是凑数

解压 ProcessControl.rar 后看到的文件分三类：工程配置、源码、编译产物。先给一张清单，再逐个说明用途。

.cbp 文件值得多说一句。它本质上是 XML，里面记录着编译器类型、Debug/Release 配置、源文件路径和输出目录。你如果换了 IDE 重新建工程，只要把 main.c 和 ProcessControl.c 两个源文件加进去，头文件指对路径，编译选项选 C99 或 C11，效果和原来一模一样。第一次打开工程的同学，建议用文本编辑器看一眼 .cbp 里的 XML，source 标签下明明白白列着源文件，option 标签里写着编译参数，看懂这几十行以后任何 Code::Blocks 工程出问题你都能自己排查，不用重装 IDE。.depend 和 .layout 是自动生成的辅助文件，提交作业时可以不打包，不影响任何功能。obj 和 bin 是构建产物，bin/Debug 里的可执行文件就是编译后的程序；分发源码时把这两个目录清掉再压缩，体积小很多，也避免别人拿到的是你本机的旧产物。

2.2 ProcessControl.h 的数据结构：PCB 怎么建模

整个实验的地基是进程控制块（PCB）。课本上说 PCB 要记录状态、程序计数器、寄存器、内存边界，但实验模拟到寄存器级别毫无必要，通常只保留调度和状态迁移需要的字段。我一般这样定义：

#define MAX_PROC 16 #define READY 0 #define RUNNING 1 #define BLOCKED 2 #define FINISHED 3 typedef struct pcb { int pid; char name[16]; int arrive_time; /* 到达时间, 单位可以是秒或时间片 */ int need_time; /* 需要的总 CPU 时间 */ int remain_time; /* 剩余时间, 轮转调度递减 */ int priority; /* 优先级, 数字小优先 */ int state; /* READY / RUNNING / BLOCKED / FINISHED */ struct pcb *next; /* 就绪队列链表指针 */ } PCB;

字段从前往后依次是进程号、名字、到达时间、需要的 CPU 时间、剩余时间、优先级、状态、链表指针。state 用宏常量表示，比直接写 0/1/2/3 可读性好得多，也不容易在状态判断里写错数字。next 指针是把 PCB 串成队列的关键，这里用的就是 C 语言最经典的链表操作——插入、删除、遍历三个动作。你要是能把链表的头插、尾插和「删除中间节点要改前驱的 next」写熟，调度队列基本不会出问题。这块用到的指针操作，跟翁恺的 C 语言课里讲链表那几节是一模一样的套路，基础不牢的先去补链表再动调度算法。

这里有个容易混的点：remain_time 和 need_time 是两个字段，不是同一个。FCFS 和 SPF 只需要 need_time 来排序和计算完成时间，时间片轮转每次执行完要递减 remain_time，直到归零才置 FINISHED。把两个字段并成一个的同学，轮转调度跑到一半就会发现进程「越跑越短」，然后整个队列乱掉。定义结构体时把注释写全，能省后面两小时的排错时间。

2.3 编译环境：Code::Blocks 与 Linux 的取舍

这份资源用 Code::Blocks 建工程，在国内高校实验环境里是最低摩擦的方案。装好 Code::Blocks（自带 MinGW）之后直接双击 .cbp，点 Build 就能编译，不需要额外配置。如果你习惯 VSCode，配好 C/C++ 插件、把编译器路径指对，新建空项目把三个源文件加进去，同样能跑，vscode 配置 c 语言环境那套流程在这里完全适用。Code::Blocks 左下角有 Debug 和 Release 两个编译目标，做实验用 Debug 就行，它带调试信息、编译优化默认关闭，跑出来的结果和源码逻辑一一对应；Release 开了优化后代码执行顺序可能和你写的不完全一致，调试时只会添乱。

但有一个必须先说清的边界：实验中如果涉及 fork()、exec()、wait() 这类系统调用，它们是 POSIX 接口，Windows 的 MinGW 不提供。常见处理办法是把实验拆成两个层面看——调度模拟部分（纯粹的数据结构加算法）在 Windows 下随意编译；真实的进程创建、进程间通信要在 linux 操作系统环境里跑，WSL 或虚拟机都行。我在 linux 上习惯直接命令行编译：

gcc -Wall -g main.c ProcessControl.c -o process_control ./process_control

-Wall 把警告全亮出来，-g 保留调试信息给 gdb 用。很多同学拿着 .cbp 在 Windows 下一编译报 undefined reference to 'fork'，就以为资源是坏的，其实只是跑错了环境。先确认代码里是否真的调用了 fork，再用对应的环境编译，问题立刻消失。main.c 的典型流程是：先初始化一批 PCB 实例，填好到达时间和服务时间；再依次调用 FCFS、SPF、RR 三个调度函数；最后打印每个进程的开始时间、完成时间，并计算平均等待时间和平均周转时间。代码里如果看到 create_process() 这类函数，它做的事就是把一个结构体实例挂到就绪队列尾部，并不是真的调用操作系统 API 创建进程。搞清楚「模拟」和「真实调用」的界限，读这份资源就不会被绕晕。

3. fork/exec/wait 三件套：进程生命周期在 Linux 下的 C 落地

3.1 fork()：返回值是三岔路口

真实进程的创建靠 fork()。它的行为可以用一句话概括：调用一次，返回两次。父进程收到子进程的 pid，子进程收到 0，出错时返回 -1。这个返回值就是代码分流的开关。

#include <stdio.h> #include <unistd.h> #include <sys/wait.h> int main(void) { pid_t pid = fork(); if (pid < 0) { perror("fork failed"); return 1; } else if (pid == 0) { /* 子进程从这里开始独立执行 */ printf("child: pid=%d, my parent=%d\n", getpid(), getppid()); } else { /* 父进程分支 */ printf("parent: pid=%d, created child=%d\n", getpid(), pid); } return 0; }

fork 通过复制父进程的内存映像创建子进程，子进程从 fork 返回点开始继续走，而不是从 main 重新开始。所以 if-else 的两个分支分别对应父子进程的「下半场」。值得注意的是，子进程会复制父进程的 stdout 缓冲区，如果父进程在 fork 之前已经 printf 过但还没刷新，子进程可能把父进程的残留内容再打印一遍，这就是实验里「输出重复」这类玄学问题的根源。解决方式是 fork 前加 fflush(stdout)，或者干脆用 setbuf(stdout, NULL) 关掉缓冲。getpid() 和 getppid() 拿当前进程和父进程的 pid，调试父子关系时很好用。

Linux 上的 fork 现在用的是写时复制（COW）机制，父进程和子进程初始共享同一份物理内存，只有某一方真正要写时才复制页面。这也是 fork 创建子进程很快的原因。实验报告里写「fork 开销小是因为 COW」，比只写「复制进程映像」高一个档次，这个知识点老师基本都会追问。

3.2 exec()：替换内存映像，失败才返回

fork 复制出来的子进程和父进程跑的是同一份代码，如果想让它执行另外一个程序，就要用 exec 系列函数。exec 会用新程序的内存映像整体替换当前进程，替换成功后不返回，只有出错才带着错误码回来。

pid_t pid = fork(); if (pid == 0) { /* 子进程执行外部程序 */ execl("/bin/echo", "echo", "hello from exec", NULL); perror("execl failed"); /* 走到这里说明 exec 失败 */ exit(1); } wait(NULL); /* 父进程等待子进程结束 */

execl 的第一个参数是程序路径，第二个是 argv[0]，之后是参数列表，最后以 NULL 结尾。子进程调用 execl 成功后被完全替换，后面的代码再也不会执行，所以 perror 和 exit 必须紧跟在 exec 后面——这两行是保底逻辑，exec 失败了要让你知道为什么。见过太多人 exec 后面接着写十行业务代码，exec 成功了这些代码永远不执行，程序行为跟预期完全对不上。实验里经常用 exec 启动一个子进程去跑排序或计算任务，父进程用 wait 等着收结果。

如果参数比较多，用 execvp 配合数组更灵活，不用把参数一个个写死在代码里：

char *args[] = { "./sort_proc", "input.txt", NULL }; execvp(args[0], args); /* 按 PATH 搜索可执行文件 */ perror("execvp failed"); exit(1);

execvp 第一个参数是程序名，第二个参数是参数数组，最后以 NULL 结尾。路径写绝对路径最稳妥，用相对路径时要注意子进程的工作目录继承自父进程，你以为的「当前目录」可能不是你以为的那个，这是 exec 找不到程序最常见的隐藏原因。

3.3 wait()：防止僵尸进程，回收退出状态

子进程退出后不会立刻消失，它会残留一个 PCB 让父进程读取退出状态，这个状态叫僵尸（zombie）。父进程不调用 wait/waitpid 回收，僵尸就一直在进程表里占位。实验中你执行 ps 看到 defunct 进程，九成是没调 wait。

int status; pid_t child = wait(&status); if (WIFEXITED(status)) { printf("child %d exited, code=%d\n", child, WEXITSTATUS(status)); } /* 非阻塞轮询版本: 不挂起父进程 */ pid_t ret = waitpid(child, &status, WNOHANG); if (ret == 0) { printf("child still running\n"); }

wait 是阻塞调用，父进程会一直等到任意子进程退出。waitpid 更精细，可以指定等哪个子进程，加上 WNOHANG 后不阻塞，配合轮询可以在父进程继续做别的事的同时检查子进程状态。WIFEXITED 判断子进程是否正常退出，WEXITSTATUS 取出退出码，这两个宏在实验里用来验证子进程的 exec 是否执行成功。如果父进程同时 fork 了多个子进程，就需要在循环里反复调用 waitpid，直到返回 -1 表示没有子进程可等了。父进程先于子进程退出时，子进程会被 init 进程收养，这是孤儿进程（orphan），跟僵尸完全两回事：僵尸是「死了没被收尸」，孤儿是「活着但爸爸没了」。实验报告里把这两个概念写清楚，比背定义更有说服力。

这份资源里的 ProcessControl.c 走的是「模拟」路线：它用 PCB 结构体和 state 字段模拟进程从创建到结束的完整生命周期，调度算法在内存里操作队列，不涉及真实的进程切换。理解 fork/exec/wait 的作用之后，再回去看模拟代码会更有感觉——每个被创建出来的 PCB 节点，对应现实里一次 fork 产生的子进程；state 从 READY 到 RUNNING 再到 FINISHED 的迁移，就是真实操作系统里进程状态机的简化版。先看懂真实系统调用，再理解模拟代码，实验报告里两者互相对照，深度立刻不一样。

4. 三种调度算法用 C 实现：FCFS、SPF、RR 的参数与坑

4.1 FCFS：顺序执行也要处理 CPU 空闲窗口

先来先服务是最朴素的策略：谁先到达谁先运行。但实现时有一个容易漏的窗口——CPU 可能空闲。进程 1 在第 0 时刻到达，进程 2 在第 5 时刻到达，如果进程 1 服务时间只有 2，CPU 在 2 到 5 之间是空的，这段空闲不能计入任何进程的等待时间。

typedef struct { int pid; int arrive; int service; int start; int finish; } Job; void fcfs(Job jobs[], int n) { int cpu_time = 0; for (int i = 0; i < n; i++) { if (cpu_time < jobs[i].arrive) { cpu_time = jobs[i].arrive; /* CPU 空闲, 推进到到达时刻 */ } jobs[i].start = cpu_time; cpu_time += jobs[i].service; jobs[i].finish = cpu_time; printf("P%d: start=%d finish=%d\n", jobs[i].pid, jobs[i].start, jobs[i].finish); } }

cpu_time 变量表示 CPU 的当前时间线。每次调度前先判断下一个进程到达没有，没到就把时间线拉到它的到达时刻，再把服务时间累加上去。start 是真正开始执行的时刻，finish 是结束时刻。平均等待时间 = sum(start - arrive) / n，平均周转时间 = sum(finish - arrive) / n，这两个公式是实验报告里必须出现的。很多人的错误是把 start 直接当成上一个 finish，无视进程到达时间的间隔，算出来的等待时间偏大甚至为负，老师一眼就能看出逻辑漏洞。调试时建议打印一行中间结果：每个进程的 start 减去 arrive 是多少，逐项核对，比最后只看平均值更容易定位是哪个进程算错了。

4.2 SPF 短进程优先：非抢占与抢占是两套写码

短进程优先（SPF）分两类。非抢占式在每次选择进程时，从「已到达且未完成」的进程里挑服务时间最短的；抢占式（也叫 SRTF）更进一步，每个时刻如果有新进程到达且它的剩余时间比当前运行进程短，就立刻切换。实验通常要求实现非抢占版本，代码核心是一个选择函数：

int pick_shortest(Job jobs[], int n, int current_time) { int idx = -1; int min = 1 << 30; for (int i = 0; i < n; i++) { if (jobs[i].arrive <= current_time && !jobs[i].done) { if (jobs[i].service < min) { min = jobs[i].service; idx = i; } } } return idx; /* 返回 -1 表示当前没有可运行的进程 */ }

这个函数的关键过滤条件是 jobs[i].arrive <= current_time，把「还没到达」的进程排除掉。如果返回值是 -1，说明 CPU 需要等待新进程到达，此时把 current_time 推进到下一个到达时刻，再重新选。服务时间相等时要加第二排序键，比如 pid 小的先运行，否则每次运行结果可能不同，报告里没法复现。抢占版则要在每次新进程到达时比较 remain_time，代码复杂一档，但核心还是「比较剩余时间，谁短谁上」。主调度循环用 while 包住：选进程、执行、标记完成、推进时间，直到所有进程 done。SPF 的缺点——长进程可能饿死，在报告里用一组极端数据（一个超长任务加一串短任务）演示一遍，比空谈理论有说服力得多。

4.3 时间片轮转：q 的取值决定你是「交互」还是「批处理」

时间片轮转（RR）把 CPU 时间切成固定大小的片，每个就绪进程轮流跑一个时间片，没跑完就放回队尾。它需要队列支持，并且每次执行时用剩余时间递减。

#define MAX_PROC 16 void rr(Job jobs[], int n, int quantum) { int remain[MAX_PROC]; int queue[MAX_PROC]; /* 用数组模拟环形队列, 存进程下标 */ int head = 0, tail = 0; int time = 0, done = 0; for (int i = 0; i < n; i++) remain[i] = jobs[i].service; for (int i = 0; i < n; i++) queue[tail++] = i; while (done < n) { int idx = queue[head]; head = (head + 1) % MAX_PROC; int slice = remain[idx] < quantum ? remain[idx] : quantum; time += slice; remain[idx] -= slice; printf("P%d run %d, remain %d, time %d\n", jobs[idx].pid, slice, remain[idx], time); if (remain[idx] == 0) { jobs[idx].finish = time; done++; } else { queue[tail] = idx; tail = (tail + 1) % MAX_PROC; } } }

这里用环形数组模拟就绪队列，精华是队头出队、未完成的进程从队尾重新入队。slice 取 quantum 和剩余时间的最小值，保证最后一个时间片不会超出。while 的终止条件是 done == n，如果忘记在 remain == 0 时累加 done，程序会无限循环，这是轮转实验最常见的死循环来源。时间片 q 的大小直接影响平均周转时间：q 取 1 时响应极快但上下文切换频繁；q 取一个大于所有服务时间的值就退化成 FCFS。做实验时建议至少跑两组 q 值（比如 q=1 和 q=4）对比数据，再把「q 越小响应越快、但切换开销越大」这个 trade-off 写进报告，这就是加分项。

4.4 数据怎么组织：三个算法一张表

实验验收时老师最常问的是「三个算法对比结果呢」。数据建议用表格呈现，而不是散落的 printf 输出：

平均等待时间和平均周转时间的计算公式上文已经给了。带权周转时间 = 周转时间 / 服务时间，它消除服务时间长短的影响，用来衡量调度的相对效率，值越接近 1 说明进程越快被完成。几组数据跑出来基本能验证课本结论：SPF 的平均等待时间通常优于 FCFS，RR 在 q 小的时候响应好但平均周转时间不一定占优。数据对不上理论时，先回头查 CPU 空闲窗口有没有处理、时间片 slice 有没有取 min，这两个位置是出错高发区。这套「结构体数组 + 队列 + 时间统计」的套路印象深一点，后面接着做虚拟存储器管理实验时你会发现，只是把 PCB 换成了页表项，骨架一模一样。

5. 进程同步与通信排错：管道、信号量与死锁的五个现场

5.1 管道阻塞：write 端没关干净，read 端等到天荒地老

管道是最经典的进程间通信方式，但实现细节里有个教科书很少强调的规则：管道是半双工的，数据单向流动；读写双方必须把不需要的端关闭，否则管道不会出现 EOF，read 会一直阻塞。

int fd[2]; if (pipe(fd) < 0) { perror("pipe"); return; } pid_t pid = fork(); if (pid == 0) { close(fd[0]); /* 子进程关读端 */ write(fd[1], "hello", 5); close(fd[1]); /* 写完后关写端 */ exit(0); } close(fd[1]); /* 父进程关写端 */ char buf[16]; int n = read(fd[0], buf, sizeof(buf)); /* 读到 5 字节, 或到 EOF */ close(fd[0]);

管道在 fork 之后同时被父子进程持有，所以每一侧都有两个文件描述符。子进程关闭读端、父进程关闭写端，这是「各关各的无关端」的标准姿势。最隐蔽的坑是父进程忘了 close(fd[1])：这样系统里仍然存在一个有效的写端（父进程自己握着），管道的引用计数不为零，read 永远不会返回 EOF，父进程就卡死在 read 上，这种问题表面看像玄学，实际就是 fd 引用计数没数清。排查时第一件事就是数清楚 fd 的引用：几个进程 fork 出去，就有几份读端几份写端，除了真正需要的那一个，其余全部关掉。

5.2 信号量 PV 顺序：P 了两次没 V，就是永久冬眠

信号量用在多进程访问共享资源时，保护临界区不被同时进入。POSIX 信号量在支持的平台上可直接用，关键是 empty/full 初值和 PV 顺序。

#include <semaphore.h> #define BUFFER_SIZE 4 sem_t empty, full, mutex; /* 初始化: empty=4, full=0, mutex=1, 必须在 fork 之前完成 */ void producer(int id) { while (1) { sem_wait(&empty); /* 先申请空位 */ sem_wait(&mutex); /* 再锁缓冲区 */ /* 写入一个数据 */ sem_post(&mutex); sem_post(&full); /* 数据量 +1 */ } }

正确顺序是先 P(empty) 再 P(mutex)。如果有人把顺序颠倒，先抢 mutex 再等 empty，当缓冲区满且 mutex 被同一进程持有时，其他生产者进不来临界区，消费数据的进程即使持有 full 信号量也进不来——所有进程互相等，这就是死锁现场。信号量操作的两个原则：一是初始值必须反映资源的真实数量，empty 是缓冲区空位数，full 是已用位数；二是每次 P 必须对应一次 V，少一次 V 就有一个进程永远等不到。实验里常见的「第二次运行就卡住」现象，八成是某个分支里漏了 sem_post。共享内存配合信号量使用时，还要注意 sem_init 必须在 fork 之前执行，否则只有发起初始化的那个进程能看到正确的信号量状态，另一个进程拿到的是未初始化内存里的垃圾值。

5.3 死锁的预防与检测：资源分配顺序是性价比最高的手段

死锁四个必要条件——互斥、持有并等待、不可剥夺、循环等待。实验里最省事的预防手段是破坏「循环等待」：给所有资源编号，规定每个进程只能按编号递增顺序申请资源。这样环就形成不了，因为环意味着存在一个进程申请了编号更大的资源后回头申请更小的，这违反规则。实现上就是给每个资源的 acquire 之前加一层编号检查，成本极低，效果却扎实。

检测算法则复杂一些，常见做法是维护一张资源分配表和请求表，模拟分配过程：循环找到能完全满足需求的进程，让它运行完释放资源，然后继续扫，如果在某一步没有任何进程可以被满足，说明存在死锁。这个算法本质是个反复扫描的循环，写在报告里作为死锁检测的加分实现，比只写概念强很多。注意模拟时要用副本数据，不要把进程真的结束掉。

5.4 五条踩坑实录：现象、原因、解决

坑 1：fork 在 Windows 编译报错现象：Code::Blocks 默认的 MinGW 编译器报一堆 undefined reference to 'fork'。 原因：fork 是 POSIX 接口，Windows 的 C 运行库没有实现。 解决：把进程创建相关代码放到 WSL 或 linux 操作系统里编译运行；Windows 端只保留不依赖系统调用的调度模拟代码。

坑 2：fork 之后 printf 输出重复现象：子进程把父进程的 printf 内容原样又打了一遍。 原因：fork 复制了父进程的 stdout 缓冲区，缓冲区里的内容被子进程继承并再次刷新。 解决：fork 之前 fflush(stdout)，或 setbuf(stdout, NULL) 关掉缓冲。

坑 3：RR 调度进程「越跑越短」现象：轮转调度过程中进程的剩余时间小于实际已执行时间，数据对不上。 原因：把 need_time 和 remain_time 混成一个字段，递减时把总需求也改了。 解决：结构体里拆成两个字段，need_time 恒定不变，只递减 remain_time。

坑 4：read 管道永远不返回现象：父进程 read(fd[0]) 一直阻塞，程序挂死。 原因：父进程没有关闭自己的写端 fd[1]，管道 EOF 永远到不了。 解决：fork 后按「各关各的无关端」原则关闭多余描述符，数清引用计数。

坑 5：信号量初始化位置不对现象：多个进程共享的信号量状态不一致，PV 操作后计数错乱。 原因：sem_init 被放在 fork 之后执行，只有当前进程能看到初始化结果。 解决：信号量必须在 fork 之前完成初始化，或用有名信号量保证全局可见。

6. 实验验收与调试：让结果经得起逐行追问

6.1 老师最爱问的三个问题

实验验收时，光有运行截图不够，老师会顺着输出逐行追问。第一个问题：平均等待时间是怎么算出来的。你要能当场写出公式，并指到代码里对应的变量。第二个问题：时间片 q 为什么选这个值。答案是「在小 q 和大 q 之间做了对比实验」，把两张表的差别讲出来。第三个问题：进程的四个状态在代码里怎么迁移。把 state 字段的赋值点找出来，能顺着代码走一遍状态机，这一关基本就过了。

6.2 调试组合拳：gdb 加 printf 双轨

我习惯的做法是编译带上 -g 和 -Wall，printf 负责宏观流程，gdb 负责微观定位。

gcc -Wall -g main.c ProcessControl.c -o process_control gdb ./process_control (gdb) break fcfs (gdb) run (gdb) print jobs[0] (gdb) next

gdb 里最常用的几招：break 打断点、run 开跑、next 单步、print 看变量。要是在某个 if 分支里发现 state 值不对，print 一眼就能看到。再配合 printf 在关键节点打标记，输出里就能看出某个进程卡在了哪个函数哪一行。实验报告里放一段 gdb 截图说明「我如何定位到问题」，比放十张运行截图更有说服力。

从那以后我做这类实验，都强制自己先花一刻钟把 PCB 结构体和三个时间公式写在一张纸上，再动键盘。数据结构和验收标准先立住，写代码只是把纸上的逻辑翻译成 C。这个习惯救了我很多次，希望帮到你。

本文还有配套的精品资源，点击获取