在 Linux 系统中，查看进程的命令非常丰富，针对不同的排查需求（如查看实时负载、精准定位某个程序、分析进程关系等），有不同的实用工具。以下是按使用场景分类的常用进程查看命令：
📸 基础静态快照：ps
ps（Process Status）用于显示某一时刻的进程静态快照，非常适合在脚本中使用或快速检查系统状态。
ps aux：最经典的组合，查看系统所有进程的详细信息（包括用户、CPU/内存占用、启动时间等）。ps -ef：以标准格式查看所有进程，能清晰看到父进程ID（PPID）。ps auxf：以树状结构展示进程，可以直观地看到进程之间的父子依赖关系。- 组合查找：通常会配合
grep来筛选特定进程，例如ps aux | grep nginx。
📊 实时动态监控：top与htop
如果你需要像 Windows 任务管理器一样实时观察系统的资源变化，这两个命令是首选。
top：系统自带的实时监控工具。默认按 CPU 占用排序，运行中可以按P键按 CPU 排序，按M键按内存排序，按k键输入 PID 可以直接杀死进程。htop：top的增强版（通常需单独安装）。界面更友好，支持彩色高亮、鼠标点击操作、横向/纵向滚动，查看起来更加直观。
🎯 精准定位与进程树：pgrep、pidof、pstree
当需要针对特定进程进行精准操作时，这些工具非常高效。
pgrep：直接通过进程名查找并返回 PID。例如pgrep nginx会直接输出 nginx 的进程号，比ps | grep更干净。pidof：根据程序名查找进程 ID，例如pidof mysqld。pstree：以树状图的形式可视化展示进程及其父子关系，非常适合分析服务的启动依赖。
🔍 进阶专项排查工具
在排查系统性能瓶颈或异常进程时，以下命令能提供更深层的信息：
/proc文件系统：Linux 下一切皆文件，/proc/PID/目录下包含了该进程最底层的权威信息（如status状态、cmdline完整命令行、fd打开的文件描述符等）。lsof：列出某个进程打开的所有文件（在 Linux 中，网络连接、硬件设备等也被视为文件）。strace：追踪进程执行时的系统调用和接收到的信号，是深度调试程序卡死或报错的神器。iotop：类似 top，但专门用于监控进程的磁盘 I/O 读写情况。
💡 常用命令速查表
| 命令 | 核心特点 | 典型使用场景 |
|---|---|---|
| ps | 静态快照，无实时性 | 脚本调用、快速查看进程详细信息 |
| top / htop | 实时动态刷新，交互性强 | 监控系统整体负载、排查 CPU/内存飙升 |
| pgrep / pidof | 精准查询 | 快速定位某个程序的 PID |
| pstree | 树状可视化 | 分析进程间的父子启动关系 |
| lsof / strace | 深度追踪 | 调试进程打开的文件、网络连接或系统调用 |
你可以根据当前是想“看一眼状态”、“实时监控”还是“深度调试”，来灵活选择对应的命令。
实际的代码示例和对应的显示结果解析。
📸 场景一：静态快照查看 (ps)
ps命令就像给当前系统进程拍了一张照片。最常用的两个组合是ps aux和ps -ef。
1. 查看所有进程的详细信息 (ps aux)
psaux|head-n5显示结果及解析：
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 1 0.0 0.1 169316 13004 ? Ss May31 0:01 /sbin/init root 2 0.0 0.0 0 0 ? S May31 0:00 [kthreadd] www-data 1234 0.5 2.0 212348 20000 ? S 10:00 0:10 nginx: worker process这段ps aux命令的输出信息展示了 Linux 系统中几个非常典型且关键的进程。我们可以逐行拆解，来深入理解它们各自承担的角色以及各项指标的具体含义：
🚀 进程 1：系统的“老祖宗” (PID 1)
root 1 0.0 0.1 169316 13004 ? Ss May31 0:01 /sbin/init
- PID 1 (/sbin/init)：这是 Linux 系统中第一个被启动的进程，也是所有其他用户空间进程的“祖先”。如果 PID 1 挂了，整个系统就会崩溃（Kernel Panic）。在现代 Linux 系统中，
/sbin/init通常是指向systemd的软链接。 - STAT (Ss)：
- S：代表Sleeping（可中断睡眠）。说明它大部分时间都在等待某些事件发生，不占用 CPU。
- s：代表它是会话领导者 (session leader)，负责管理整个用户会话。
- TIME (0:01)：自 May31（5月31日）启动以来，它累计只消耗了 1 秒钟的 CPU 时间。这非常正常，因为 init 进程主要负责调度其他服务，自己并不干重活。
⚙️ 进程 2：内核的“大管家” (kthreadd)
root 2 0.0 0.0 0 0 ? S May31 0:00 [kthreadd]
- [kthreadd]：这是 Linux内核的线程管理器。它的主要工作是帮助内核创建和管理其他的内核线程。
- VSZ/RSS (0 / 0)：你会发现它的虚拟内存和物理内存占用都是 0。这是因为它运行在内核空间，而不是普通的用户空间，所以常规的
ps命令统计不到它的内存占用。 - 方括号 []：在
ps输出中，名字被方括号[]包起来的，通常都是内核线程。
🌐 进程 1234：干活的 Web 服务器 (Nginx Worker)
www-data 1234 0.5 2.0 212348 20000 ? S 10:00 0:10 nginx: worker process
- USER (www-data)：这个进程是由
www-data用户运行的。这是 Web 服务（如 Nginx、Apache）的标准安全实践，不使用 root 权限来运行对外提供服务的进程，可以防止网站被黑客攻破后直接获取系统最高权限。 - COMMAND (nginx: worker process)：这是 Nginx 的工作进程。Nginx 采用“多进程”模型，通常有一个
master process（负责管理配置和调度）和多个worker process（负责实际处理用户的网页请求）。 - 内存占用：
- VSZ (212348 KB)：虚拟内存约 207 MB。
- RSS (20000 KB)：实际占用的物理内存约 19.5 MB。这是判断它真实消耗内存的核心指标。
- STAT (S)：处于可中断睡眠状态，正在安静地等待网络请求的到来。
- %CPU (0.5)：当前瞬间占用了 0.5% 的 CPU，说明服务器当前非常空闲，没有太大的访问压力。
💡 重点指标科普：VSZ 与 RSS 的区别
在分析内存时，这两个指标经常让人困惑：
- VSZ (Virtual Memory Size)：进程理论上能访问的总内存（包含代码、共享库、已申请但还没用的内存）。这个数值通常很大，参考意义有限。
- RSS (Resident Set Size)：进程实际占用了多少物理内存条的空间。排查内存占用过高问题时，主要看 RSS。
📋 总结
这段输出描绘了一个非常标准的 Linux 服务器运行状态：
- 系统根基稳固：init 和 kthreadd 正常运行。
- 业务服务健康：Nginx 以低权限用户运行，内存和 CPU 占用都很低，处于待命状态。
- 无异常进程：没有看到高负载的进程，也没有出现僵尸进程（STAT 为 Z 的进程）。
2. 查看进程树与父子关系 (ps -ef --forest)
ps-ef--forest|grepsshd显示结果及解析：
root 1023 1 0 09:00 ? 00:00:00 /usr/sbin/sshd -D root 5678 1023 0 10:30 ? 00:00:00 \_ sshd: root@pts/0 root 5680 5678 0 10:30 pts/0 00:00:00 \_ -bash- 通过树状结构，可以清晰看到
bash的父进程是sshd: root@pts/0，而它的祖父进程是/usr/sbin/sshd。
📊 场景二：实时动态监控 (top)
top命令会持续刷新，适合观察系统负载的动态变化。
运行命令：
top显示结果及解析（界面截取）：
top - 20:30:15 up 10 days, 3:20, 2 users, load average: 0.50, 0.40, 0.35 Tasks: 120 total, 1 running, 119 sleeping, 0 stopped, 0 zombie %Cpu(s): 5.0 us, 2.0 sy, 0.0 ni, 92.0 id, 0.5 wa, 0.0 hi, 0.5 si, 0.0 st MiB Mem : 7980.0 total, 1200.0 free, 3500.0 used, 3280.0 buff/cache PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 1234 mysql 20 0 2500000 500000 10000 S 45.0 6.1 120:30.50 mysqld 5678 root 20 0 100000 5000 3000 R 5.0 0.1 0:05.20 top这段top命令的输出信息非常清晰，整体来看，这台服务器的运行状态非常健康，负载很低。
为了让你更深入地理解，我们逐行拆解这些数据的含义，并挖掘其中隐藏的系统信息：
📊 第一部分：系统整体状态区（前4行）
第1行：系统运行时间与负载top - 20:30:15 up 10 days, 3:20, 2 users, load average: 0.50, 0.40, 0.35
- 20:30:15：当前系统时间。
- up 10 days, 3:20：系统已经连续运行了 10 天 3 小时 20 分钟，说明系统很稳定，近期没有发生过意外重启。
- 2 users：当前有 2 个用户登录了系统。
- load average: 0.50, 0.40, 0.35：这是系统的平均负载，分别代表过去 1 分钟、5 分钟、15 分钟内的平均活跃进程数。
- 分析：数值非常低（远低于 1.0）。这意味着 CPU 非常空闲，没有任何进程在排队等待处理，系统毫无压力。
第2行：进程（任务）统计Tasks: 120 total, 1 running, 119 sleeping, 0 stopped, 0 zombie
- 120 total：系统当前总共有 120 个进程。
- 1 running：只有 1 个进程正在使用 CPU（其实就是下面的
top命令本身）。 - 119 sleeping：119 个进程处于休眠状态，正在等待某些事件（如等待网络请求或用户输入）。
- 0 zombie：僵尸进程为 0，这是一个非常好的信号。如果有僵尸进程（Z），说明有程序退出后没有被父进程正确回收，可能会耗尽系统资源。
第3行：CPU 使用率明细%Cpu(s): 5.0 us, 2.0 sy, 0.0 ni, 92.0 id, 0.5 wa, 0.0 hi, 0.5 si, 0.0 st
- 5.0 us (user)：用户空间（应用程序）占用了 5% 的 CPU。
- 2.0 sy (system)：内核空间（系统调用）占用了 2% 的 CPU。
- 92.0 id (idle)：CPU 空闲率高达 92%，说明绝大部分时间 CPU 都在“休息”。
- 0.5 wa (wait)：等待 I/O（如磁盘读写）的时间仅占 0.5%。如果这个数值很高（比如超过 20%），通常意味着磁盘读写遇到了瓶颈。
- 0.0 st (steal)：如果是云服务器，这个数值代表被宿主机或其他虚拟机“偷走”的 CPU 时间。为 0 说明你的虚拟机资源独享性很好，没有受到“吵闹的邻居”影响。
第4行：物理内存使用MiB Mem : 7980.0 total, 1200.0 free, 3500.0 used, 3280.0 buff/cache
- 7980.0 total：总物理内存约为 8 GB。
- 1200.0 free：完全未被使用的空闲内存。
- 3500.0 used：应用程序实际使用的内存。
- 3280.0 buff/cache：被系统用作磁盘缓存的内存。
- 分析：Linux 的内存管理机制非常智能，它会把暂时不用的内存拿来做缓存（buff/cache）以加速文件读取。当应用程序需要内存时，这部分缓存会立刻释放出来。因此，你的实际可用内存 ≈ free + buff/cache，即 1200 + 3280 = 4480 MB，内存资源非常充裕。
📋 第二部分：进程详情列表区
这部分展示了当前消耗资源最多的进程，默认按 CPU 使用率降序排列。
进程 1：MySQL 数据库1234 mysql 20 0 2500000 500000 10000 S 45.0 6.1 120:30.50 mysqld
- PID 1234, USER mysql：进程号为 1234，由 mysql 用户启动。
- VIRT 2500000：虚拟内存使用了约 2.5 GB（包含代码、共享库等，不代表实际物理内存占用）。
- RES 500000：常驻物理内存使用了约 500 MB。这是判断进程实际吃多少内存的核心指标。
- S (Status)：状态为
S(Sleeping)，处于可中断的休眠状态，正在等待数据库请求。 - %CPU 45.0：当前瞬间占用了 45% 的 CPU 资源。结合前面系统总 CPU 使用率只有 8% (5% us + 2% sy) 来看，这台机器可能是多核 CPU（例如 8 核），MySQL 占满了其中半个核左右的资源，属于正常的数据库业务负载。
- %MEM 6.1：占用了总内存的 6.1%。
- TIME+ 120:30.50：该进程自启动以来，累计占用了 CPU 的时间为 120 分 30 秒。
进程 2：top 监控命令5678 root 20 0 100000 5000 3000 R 5.0 0.1 0:05.20 top
- PID 5678, USER root：由 root 用户运行。
- S (Status)：状态为
R(Running)，因为它正在前台运行并刷新界面，所以它自己就是那个唯一的running进程。 - %CPU 5.0：
top命令本身刷新界面也消耗了 5% 的 CPU。
💡 总结
这是一台运行极其平稳、资源非常富余的 Linux 服务器。
- CPU：92% 的空闲率，毫无瓶颈。
- 内存：8G 内存只用了一半左右，且没有任何 Swap（交换分区）使用的迹象（如果有 Swap 使用，通常会多显示一行 Swap 数据），说明物理内存完全够用。
- 进程：没有僵尸进程，唯一的业务进程 MySQL 运行状态正常。
load average最高是1吗
并不是，load average（系统平均负载）并没有 1 的上限。
很多人误以为负载最高是 1（或者 100%），是因为把它和 CPU 使用率（%CPU）搞混了。其实，load average 的具体上限取决于你服务器的 CPU 逻辑核心数。
为了让你彻底明白，我们可以用一个经典的**“过桥/车道”理论**来打比方：
🚗 什么是 load average？
假设你的 CPU 核心是一条单车道。
- load average = 0.5：表示这条路上只有半辆车，非常通畅，车随到随走。
- load average = 1.0：表示这条路刚好被占满。虽然车还能走，但已经没有一点富余空间了。
- load average = 1.5：表示路已经被占满（1.0），还有 0.5 辆车正在排队等着过桥。这时候系统就开始出现延迟了。
🖥️ 多核 CPU 的上限是多少？
现在的服务器或电脑基本都是多核的。如果你的 CPU 有 4 个核心，就相当于有4 条并行的车道。
- 这时候，load average = 4.0才相当于单核时的 1.0（刚好占满）。
- 只有当 load average 超过 4.0（比如 5.0、6.0），才说明 4 条车道都堵死了，有进程在排队。
所以，load average 的“满分上限” = 你系统的 CPU 逻辑核心总数。
💡 怎么判断你的负载是否过高？
你可以通过命令nproc或grep -c 'model name' /proc/cpuinfo查看你的 CPU 逻辑核心数。
运维界通常有一个**“0.7 法则”**来评估系统健康度（以单核为例，多核请按比例换算）：
| 负载数值 (以单核为例) | 状态评估 | 建议操作 |
|---|---|---|
| < 0.7 | 🟢健康 | 系统资源充裕，无需担心。 |
| 0.7 ~ 1.0 | 🟡预警 | 系统开始变忙，建议关注是否有异常任务。 |
| > 1.0 | 🔴过载 | 进程开始排队，系统响应变慢，必须排查。 |
| > 5.0 | 💀严重 | 系统可能已经卡死，随时面临崩溃风险。 |
举个例子：
如果你有一台8 核的服务器：
- load average 在5.6(8 * 0.7) 以下，都是非常健康的。
- 直到 load average 达到8.0，系统才算真正被“跑满”。
- 如果 load average 飙升到12.0，说明有 4 个核心工作量的任务在排队，这时候你就需要赶紧用
top看看是哪个进程在捣乱了。
🎯 场景三：精准定位进程 (pgrep与pstree)
当你只知道程序名，想快速拿到 PID 或者看它的启动结构时。
1. 快速查找 PID (pgrep)
pgrep-lfnginx显示结果及解析：
1234 nginx: master process /usr/sbin/nginx 1235 nginx: worker process-l显示进程名，-f显示完整的命令行。比用ps aux | grep再过滤要干净得多。
2. 可视化进程树 (pstree)
pstree-p|grepsystemd显示结果及解析：
systemd(1)-+-ModemManager(890)-+-{gdbus}(912) | `-{gmain}(913) |-NetworkManager(888) |-sshd(1023)---sshd(5678)---bash(5680)这段pstree命令的输出结果，非常直观地展示了 Linux 系统中几个核心服务的“家族族谱”和层级关系。括号里的数字代表的是进程的 PID（进程号）。
我们可以从上到下，逐层拆解这个进程树，看看它们各自在系统中扮演什么角色：
👑 根节点：systemd(1)
systemd(1)是整个进程树的根，也就是系统的1号进程。
- PID 1：它是 Linux 系统启动后运行的第一个程序，是所有用户空间进程的“老祖宗”。
- 核心职责：负责初始化系统、启动和管理各种后台服务（也就是我们常说的守护进程，Daemon）。你看到的 ModemManager、NetworkManager 和 sshd 都是由它直接或间接拉起来的。
📡 分支一：ModemManager(890)
ModemManager(890)-+-{gdbus}(912) 和 -{gmain}(913)
- ModemManager：这是一个专门用于管理移动宽带设备（如 2G/3G/4G/5G 上网卡、内置无线模块）的守护进程。如果你的电脑或服务器插了 SIM 卡上网，就是它在后台工作。
- {gdbus}(912) 和 {gmain}(913)：注意它们的名字被花括号
{}包裹，这代表它们是 ModemManager 内部的线程 (Threads)，而不是独立的进程。gmain通常是 GLib 库的主事件循环线程，负责处理主要的逻辑。gdbus负责处理 D-Bus 通信（Linux 中进程间互相喊话的一种机制）。
🌐 分支二：NetworkManager(888)
NetworkManager(888)
- 这是 Linux 系统中最常见的网络管理服务。
- 它的任务是自动检测和配置你的网络接口，无论是插网线（以太网）、连 Wi-Fi，还是通过上面的 ModemManager 连接移动网络，都是由它统一调度和管理的。
🔐 分支三：sshd 远程登录链路
sshd(1023)---sshd(5678)---bash(5680)
这条链路非常经典，它完整地展示了一次远程 SSH 登录的全过程：
- sshd(1023)：这是 SSH 服务的主守护进程（Server Daemon）。它由 systemd 启动后，会一直安静地监听服务器的 22 端口，等待远程用户来连接。
- sshd(5678)：当你（或某个用户）从远程电脑成功连接到这台服务器时，主进程
sshd(1023)会专门“克隆”出一个新的子进程sshd(5678)，用来专门服务这一次特定的连接会话。 - bash(5680)：当你的身份验证通过后，这个专属的 sshd 子进程会为你启动一个 Shell 环境（这里是
bash）。你现在在终端里敲的每一个命令，其实都是这个 bash(5680) 进程在执行。
💡 总结一下
这张进程树图谱描绘了一个非常标准的 Linux 服务器运行状态：
- systemd(1)作为大管家稳坐中军帐。
- ModemManager和NetworkManager在后台默默管理着网络连接。
- sshd 链路清晰地记录了你（或管理员）是如何通过网络远程连接到这台机器，并获取到一个命令行操作界面的。
🔍 场景四：深度排查 (/proc与lsof)
当进程出现异常（比如内存泄漏或文件句柄耗尽），需要深入“解剖”它。假设我们要排查 PID 为1234的进程。
1. 查看进程的真实内存与状态 (/proc/[PID]/status)
cat/proc/1234/status|grep-E"Name|State|VmRSS|VmSize"显示结果及解析：
Name: mysqld State: S (sleeping) VmSize: 2560000 kB VmRSS: 512000 kB这段/proc/[PID]/status的截取信息，非常精准地揭示了 MySQL 数据库进程（mysqld）当前的核心运行状态和真实的内存消耗情况。
我们可以逐项拆解这些指标，看看它们背后代表的实际意义：
📊 逐行深度解读
Name: mysqld
这是该进程对应的命令名称。mysqld是 MySQL 数据库的服务端守护进程，也就是实际在后台提供数据库服务的核心程序。State: S (sleeping)
进程当前处于可中断睡眠（Sleeping）状态。
这完全正常，并不代表数据库“睡着了”或停止工作。它意味着mysqld当前没有繁重的计算任务，正在安静地等待新的数据库请求（比如你的 SQL 查询）或网络 I/O 的到来。一旦有请求进来，它会立刻被唤醒并投入工作。VmSize: 2560000 kB
这是进程的虚拟内存大小（Virtual Memory Size），约等于2.44 GB。
它包含了进程能访问的所有内存（包括代码、共享库、已申请但还没实际使用的内存等）。这个数字通常很大，但并不代表它真实吃掉了这么多物理内存，参考意义相对有限。VmRSS: 512000 kB
这是进程的常驻内存集大小（Resident Set Size），约等于500 MB。
这是最核心、最需要关注的指标！它代表了mysqld进程当前实际占用在物理内存条上的空间。如果你在排查服务器内存为什么被吃光了，或者担心 MySQL 占用内存过高，VmRSS就是最真实的判断依据。
💡 总结与运维建议
结合这段信息来看，你的 MySQL 数据库目前处于非常健康的待机状态：
- 进程状态正常（Sleeping 待命）。
- 实际物理内存占用（500 MB）在合理范围内，没有发生内存泄漏或异常飙升的迹象。
💡 延伸排查小技巧：
如果你发现VmRSS异常高（比如远超你在 MySQL 配置文件my.cnf中设置的innodb_buffer_pool_size等内存参数之和），通常意味着有隐性的内存消耗。这时候可以重点排查以下几个方向：
- 连接数是否失控：每个数据库连接都会独占一部分内存缓冲区，连接数过多会成倍消耗内存。
- 是否有烂 SQL：某些没有加
LIMIT的复杂查询（如GROUP BY）可能会在内存中创建巨大的临时表。 - 监控开销：如果开启了
performance_schema，在高并发下它自身也会消耗几百 MB 的内存。。
2. 查看进程打开了哪些文件 (lsof)
lsof-p1234|head-n5显示结果及解析：
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME mysqld 1234 mysql cwd DIR 8,1 4096 12345 /var/lib/mysql mysqld 1234 mysql txt REG 8,1 12345678 67890 /usr/sbin/mysqld mysqld 1234 mysql 3u IPv4 12345 0t0 TCP *:mysql (LISTEN)这段lsof -p 1234的输出信息，就像是为 MySQL 进程（PID 1234）做了一次“随身物品大检查”，清晰地列出了它当前正在使用的核心文件和系统资源。
我们可以逐行拆解，看看这些缩写背后的具体含义：
📂 第一行：进程的“家” (cwd)
mysqld 1234 mysql cwd DIR 8,1 4096 12345 /var/lib/mysql
- cwd (Current Working Directory)：代表进程的当前工作目录。
- DIR：表示这是一个目录（Directory）。
- /var/lib/mysql：这是 MySQL 默认存放数据文件（如数据库表、索引等）的核心目录。这说明
mysqld进程是以这个目录为“大本营”在运行的。
⚙️ 第二行：程序的本体 (txt)
mysqld 1234 mysql txt REG 8,1 12345678 67890 /usr/sbin/mysqld
- txt：在 Linux 术语中，它代表程序的代码段（Text），也就是可执行程序的二进制文件本身。
- REG：表示这是一个常规文件（Regular file）。
- /usr/sbin/mysqld：这是 MySQL 服务端程序的实际安装路径。系统正是通过执行这个文件来启动数据库服务的。
🌐 第三行：对外服务的窗口 (TCP 监听)
mysqld 1234 mysql 3u IPv4 12345 0t0 TCP *:mysql (LISTEN)
- 3u：这是文件描述符（FD）。数字
3是系统分配给这个资源的编号；字母u代表该进程对这个资源拥有读写（Read/Write）权限。 - IPv4：表示这是一个 IPv4 协议的网络连接。
- TCP *:mysql (LISTEN)：这是最关键的信息！
- TCP：使用 TCP 协议进行通信。
- *：代表监听服务器上的所有网卡/IP地址（即 0.0.0.0）。
- mysql：这里直接显示了服务名，它对应的是 MySQL 的默认端口3306。
- LISTEN：表示进程正处于监听状态，随时准备接受来自客户端（如你的电脑、后端程序）的连接请求。
💡 总结一下
通过这短短三行信息，我们就能精准掌握 MySQL 的核心运行脉络：
- 它把
/var/lib/mysql当作存放数据的家。 - 它的程序本体位于
/usr/sbin/mysqld。 - 它正在通过3306 端口敞开大门，监听并等待外界的连接。
💡 运维排查小技巧：
如果你的应用程序连不上数据库，除了检查防火墙，就可以用lsof -i :3306或类似的命令看看 MySQL 是否真的在监听0.0.0.0:3306（允许任意IP连接）还是只监听了127.0.0.1:3306（只允许本机连接）。
你可以直接在 Linux 终端里输入这些命令，对比一下实际的显示结果，这样能帮你更快地掌握它们的用法！
