Kubernetes kubectl 实战手册：从排障到日常运维的完整命令指南

凌晨两点手机告警把整个群都炸醒了——生产环境的某个节点直接 NotReady业务 Pod 像多米诺骨牌一样接二连三进入 Pending。经历过这种场面的人应该都懂微信群里所有人都在等你一句话我先看下集群状态。这时候你敲下的第一条命令往往就决定了这次故障是大问题还是小问题。在 K8S 这个生态里kubectl 就是我们和整个集群打交道的唯一窗口。不管是查看集群状态、排查 Pod 异常、滚动更新业务还是处理存储和配置问题没有它寸步难行。这份手册不是把官方文档的命令抄一遍而是我从接手各种乱七八糟的集群到跑生产环境微服务再到搭监控、迁 GPU 任务一路踩过来的命令笔记和使用心得。也许你刚学 K8S也许你正在为手头的集群焦头烂额按场景翻对应的章节会比对着 kubectl --help 一个个试高效得多。1. 面对一套陌生集群先摸清家底再动手很多初学者拿到一套集群第一反应就是 kubectl get pods。我理解这种急切但最好先花两分钟搞清楚自己在哪儿、连的是谁、集群有多大。尤其是别人交接过来的环境手一抖连错集群的事情我见过不止一回。1.1 kubeconfig 的加载顺序连错集群的根源kubectl 连接集群靠的是 kubeconfig 文件它的加载顺序是命令行里--kubeconfig参数 环境变量$KUBECONFIG 默认路径~/.kube/config。超过九成我明明配了 A 集群怎么操作到 B 集群去了的诡异现象源头都是环境变量里残留了旧集群的 KUBECONFIG 路径。所以我切到新环境的第一件事永远是验证身份# 查看当前使用的上下文context kubectl config current-context # 列出所有可用的上下文 kubectl config get-contexts # 切换到指定上下文 kubectl config use-context production # 查看当前 kubeconfig 里的集群信息 kubectl config view --minifykubectl cluster-info也值得养成习惯它会返回控制面组件kube-apiserver、kube-controller-manager、kube-scheduler 等的地址。如果返回的是一堆内网 IP说明这份 kubeconfig 是从集群内部导出的你在办公室根本连不上它对端。解决的套路是把 kubeconfig 里 server 字段改成外网可达的 LB 或 DNAT 地址。1.2 从节点视角建立集群资源全貌确认连接无误后我再把节点和集群的整体情况扫一遍# 查看所有节点-o wide 会输出 IP、内核版本、容器运行时等关键信息 kubectl get nodes -o wide # 查看节点详细信息包括状态、污点、资源分配情况 kubectl describe node node-name # 查看节点上的污点Taints和标签Labels这决定了 Pod 能不能调度上去 kubectl get nodes --show-labels-o wide是我用得最频繁的参数多列输出能省掉我大量的 describe 时间。在内核版本那一列你能一眼看出集群里的节点是不是混用了不同内核在容器运行时那一列能看出是 containerd 还是 docker。如果是混用时长的集群节点滚动升级时很容易踩内核模块不兼容的坑。kubectl describe node里最值得关注的是 Conditions 部分Ready、MemoryPressure、DiskPressure、PIDPressure以及 Allocated resources 部分。前者告诉你节点当前健不健康后者告诉你节点能不能再塞下新的 Pod。有时候一个节点明明显示 Ready但你创建 Pod 依然 Pending多半就是 Allocated resources 已经把 CPU 或内存瓜分完了Node 上没有足够的可分配余量。1.3 API 资源的全局视角不只是 PodKubernetes 的 API 资源远比很多人想象的多。只盯着 Deployment 和 Pod 的人遇到 ConfigMap、PVC 这些问题时容易抓瞎。我习惯用这两个命令建立全局观# 列出当前集群支持的所有 API 资源 kubectl api-resources # 只看命名空间级别的资源 kubectl api-resources --namespacedtrue # 只看集群级别的资源比如 Node、Namespace、PV 等 kubectl api-resources --namespacedfalsekubectl get all这个命令是个典型的伪全量它只会列出几类最常用的资源ServiceAccount、ConfigMap、Secret、PVC 这些统统不包含在内。所以你kubectl get all -n default看到一片正常不代表这个命名空间里没有隐藏的问题。排查的时候要按资源类型一个一个看或者结合kubectl get resource -A的方式逐个排查。2. 工作负载Deployment、StatefulSet、DaemonSet 的增删改查工作了负载是我日常打交道最多的对象。这一章按创建、查看、变更、回滚四个环节把命令串起来讲顺便说清楚很多教程里没讲的为什么。2.1 创建方式的选择命令式与声明式的边界先看三种创建方式# 方式一kubectl run创建一个测试 Pod kubectl run nginx-test --imagenginx # 方式二kubectl create deployment创建一个 Deployment kubectl create deployment nginx-prod --imagenginx:1.25 --replicas3 # 方式三kubectl apply声明式创建或更新 kubectl apply -f deployment.yamlkubectl run是纯粹的测试玩具直接创建一个 PodPod 挂了就没了没人会拿kubectl run管生产。kubectl create在对象已经存在的情况下会直接报错而kubectl apply则会把 YAML 里声明的内容和集群里的现状做比对有差异就更新没差异就保持现状。这种声明式的做事方式才是 Kubernetes 的哲学你只管说最终要什么集群自己想办法收敛到这个状态。在 GitOps 流程里kubectl apply -f几乎是唯一的选择因为它允许你把集群状态完全放在 Git 仓库里做版本管理每次部署只是让集群向仓库里的声明收敛。2.2 扩缩容、滚动更新与回滚业务流量高峰来了扩容是家常便饭# 指定副本数扩容/缩容 kubectl scale deployment nginx-prod --replicas8 # 基于 HPA 自动扩缩容时可以调整最小/最大副本数 kubectl autoscale deployment nginx-prod --min3 --max10 --cpu-percent70做镜像升级时推荐用set image而不是直接edit改 YAML# 修改镜像版本 kubectl set image deployment/nginx-prod nginxnginx:1.26-alpine # 追踪滚动更新的进度 kubectl rollout status deployment/nginx-prod # 查看更新历史 kubectl rollout history deployment/nginx-prod # 回滚到上一个版本 kubectl rollout undo deployment/nginx-prod # 回滚到指定历史版本 kubectl rollout undo deployment/nginx-prod --to-revision2默认情况下 Deployment 的更新策略是 RollingUpdate滚动过程会先起新 Pod等新 Pod 就绪后再销毁旧 Pod保证全程不中断服务。控制滚动速度的两个关键参数是maxSurge和maxUnavailablemaxSurge表示滚动过程中最多允许超出期望副本数多少个maxUnavailable表示最多允许多少个副本不可用。比如期望 5 个副本maxSurge25%、maxUnavailable25% 时滚动过程中维持的总副本数会在 4 到 7 之间波动。如果你的服务是强依赖数据库的结构一次全量替换和新旧流量混跑可能引发锁竞争滚动参数就得调保守一些。2.3 视图与筛选从海量 Pod 中快速定位集群规模一大kubectl get pods刷出来的内容根本看不过来。我常用的几个筛选姿势# 全命名空间查看所有 Pod kubectl get pods -A # 按标签选择器过滤 kubectl get pods -l appnginx,envprod # 只看失败状态的 Pod kubectl get pods --field-selectorstatus.phaseFailed # 只看某个节点上的 Pod kubectl get pods -A --field-selectorspec.nodeNamenode01 # 输出指定字段比如只看 Pod IP 和所在节点 kubectl get pods -o custom-columnsNAME:.metadata.name,IP:.status.podIP,NODE:.spec.nodeName标签选择器-l是 K8S 里最灵活的组合拳。排查问题的时候我通常先-l appxxx把相关 Pod 筛出来再用-o wide看它们被调度到了哪些节点最后kubectl describe pod name逐一确认状态。--field-selector则适合做异常巡检比如找出所有 Failed、Unknown 状态的 Pod一条命令就把可疑对象全部揪出来。2.4 节点维护与 Pod 优雅下线节点要换内核、要缩容不能直接把机器关了否则上面的 Pod 就成了孤儿。标准操作是 cordon标记不可调度 drain驱逐已有 Pod# 标记节点为不可调度新 Pod 不会再上去 kubectl cordon node01 # 驱逐节点上的 Podignore-daemonsets 表示驱逐时跳过 DaemonSet 管理的 Pod kubectl drain node01 --ignore-daemonsets --delete-emptydir-data # 维护完成后恢复调度 kubectl uncordon node01这里有三个容易踩的坑第一--ignore-daemonsets不加的话DaemonSet 的 Pod比如日志采集、监控 agent会因为无法被驱逐而卡住整个 drain第二如果 Pod 使用了 emptyDir必须加--delete-emptydir-data才肯走第三如果业务没有配置 PodDisruptionBudgetPDBdrain 会把副本一次性全部打掉服务直接断掉。所以生产上给关键业务配好 PDB 是必须的# 查看当前命名空间下的 PDB kubectl get pdb -A单节点集群比如很多人测试用的 one-node k8s没有高可用的概念drain 一个节点等于把集群整个停掉这种环境更适合直接重启机器或者迁移到云上这也是很多教程和真实项目会选择把测试环境直接部署到单机然后按不停服需求迁移到云 ECS 的原因。迁移动作本身说白了就是先在新环境把工作负载、ConfigMap、PVC 都就位再通过 Service 切换流量的过程。3. Service、Endpoint 与 Ingress网络排查的完整链路网络不通是 K8S 排障的重灾区。讲这一章之前先把链路理清楚用户请求 - Ingress/NodePort/LoadBalancer - Service - Endpoint - Pod IP - 容器端口。任何一环断了表现都是访问不通但根因可能完全不同。3.1 Service 类型与 Endpoint 检查# 查看 Service kubectl get svc # 查看 Service 详情注意 Selector 和 Endpoints 字段 kubectl describe svc service-name # 查看 Endpoint注意是 endpoints kubectl get endpoints # 查看更细粒度的 EndpointSlice kubectl get endpointsliceskubectl describe svc里有一个特别重要的字段叫 Endpoints它显示的是 Service 后面实际关联的 Pod IP 列表。如果这个字段是空的或者和你的 Pod IP 对不上问题基本就锁定在标签选择器写错了——Service 的 selector 没匹配到任何 Pod自然就没有 Endpoint。很多人在这里会填一个大坑kubectl 的命令是kubectl get endpoints不是kubectl get endpoint。缩写ep两个都可以但endpoint这个资源类型在 K8S 里是不存在的。如果敲了kubectl get endpoint返回No resources found那不是真的没有是你资源名写错了。3.2 用临时调试 Pod 验证连通性承接上面的情况完成这步检查之后仍然需要验证 DNS 和服务发现是否正常。先创建一次性的调试 Pod# 创建一个临时使用的调试容器执行完命令就删掉 kubectl run tmp-debug --rm -it --imagebusybox --restartNever -- sh # 进入容器后先看 DNS 解析是否正常 nslookup service-name.namespace.svc.cluster.local # 再直接请求 Service 的 ClusterIP 和端口 curl http://service-cluster-ip:port # 或者通过服务名访问同 namespace 下可以直接用服务名 curl http://service-name:port为什么要特意起一个 busybox 的临时 Pod而不是直接kubectl exec进业务 Pod 里 curl因为业务镜像基本都是精简版连curl、ping、nslookup都没有。用调试 Pod 的好处是工具链干净用完即焚不给业务 Pod 增加额外进程。如果业务 Pod 里能通但临时调试 Pod 里不通优先怀疑 CoreDNS。检查一下 kube-system 命名空间下的 CoreDNS Pod 是否正常kubectl get pods -n kube-system -l k8s-appkube-dns kubectl logs -n kube-system -l k8s-appkube-dns --tail503.3 端口转发本地调试的利器有时候你不想进入集群内部只想在本地连一下某个服务的端口比如连数据库管理工具、调 API 接口port-forward是最快的通道# 把 Service 的 80 端口转发到本地的 8080 端口 kubectl port-forward svc/nginx-prod 8080:80 # 把某个 Pod 的 3306 端口转发到本地的 3306 端口 kubectl port-forward pod/mysql-0 3306:3306port-forward本质上是 kubectl 通过 API Server 和 kubelet 建立的一条临时隧道不改动集群里的任何网络配置特别适合排查问题和临时调试。但你要知道它的性能瓶颈很重只适合低流量场景。我见过有人拿它做压测结果是 API Server 直接被挤爆所有业务跟着遭殃。高并发的流量验证务必走 Ingress 或 LoadBalancer 的真实链路。3.4 压测前的网络链路检查提到高并发结合很多人在做的迁移和压测场景我习惯在压测前跑一遍下面这些命令确认网络链路没有隐患# 确认 kube-proxy 的工作模式ipvs 模式性能远好于 iptables kubectl logs -n kube-system -l k8s-appkube-proxy --tail10 | grep ipvs # 确认 Ingress Controller 的就绪状态和副本数 kubectl get pods -n ingress-nginx # 确认 Service 的 Endpoint 数量正常没有被异常摘除 kubectl get endpoints -Aiptables 模式在大量 Service 和并发连接下规则链会变得非常长性能衰减很明显。IPVS 模式则是内核态哈希表查找性能和稳定性都更好。压测如果打不出预期的 QPS先从 kube-proxy 模式、内核参数和节点资源上限查不要一上来就怪应用代码。4. 日志、事件与容器内调试看不见的 Kubernetes 状态K8S 排障和传统排障有个很大的不同容器挂了不等于 Pod 挂了Pod 挂了不等于工作负载挂了每一层都有抽象所以你必须掌握看内部状态的命令。4.1 日志追踪与多容器场景最常用的日志命令几乎每天都要敲# 查看 Pod 日志 kubectl logs pod-name # 实时跟踪日志流 kubectl logs -f pod-name # 只看最近 100 行 kubectl logs --tail100 pod-name # 看最近 10 分钟的日志 kubectl logs --since10m pod-name如果 Pod 里有多个容器必须用-c指定容器名否则 kubectl 会提示你选择。这个细节新手经常踩kubectl logs pod-name -c container-name更关键的是容器崩溃的场景。一个 Pod 反复 CrashLoopBackOff你kubectl logs看到的通常是当前容器的新日志真正有用的崩溃前日志在上一个容器里# 查看上一个容器的日志容器崩溃退出前留下的内容 kubectl logs pod-name --previous这个--previous参数是我排查 CrashLoopBackOff 的第一板斧。很多应用是启动阶段连数据库失败然后秒退如果只看当前日志会发现进程根本没输出什么但上一份日志里往往写着数据库连接被拒绝。4.2 describe 与 Events 的时间线还原kubectl describe被称为排障界的万金油什么都能看kubectl describe pod pod-name kubectl describe node node-name kubectl describe pvc pvc-name kubectl describe svc service-namedescribe 输出里最底下有一段 Events 事件记录了这个对象最近经历的关键动作包括调度、拉镜像、挂载卷、健康检查失败等。但注意describe 里的事件只是最近的一小部分对于反复重启、持续报错的场景我更推荐直接查事件流# 全命名空间查看事件按时间排序 kubectl get events -A --sort-by.lastTimestamp # 只看 Warning 级别的事件 kubectl get events -A --field-selector typeWarning # 关注某个 Pod 的事件 kubectl get events --field-selector involvedObject.namepod-nameEvents 按 LastTimestamp 排序后你能还原出故障的完整时间线几点几分镜像拉取失败、几点几分容器被 OOMKilled、几点几分节点被标记为不可调度。这种时间线视角比一个个 describe 来得高效得多。4.3 exec 进容器与临时调试容器需要进入容器内部看现场标准姿势是kubectl exec -it pod-name -- /bin/sh # 如果容器里有 bash 也可以用 bash kubectl exec -it pod-name -- /bin/bash但不是所有容器都有 shell很多 distroless 镜像里连/bin/sh都不存在。Kubernetes 1.20 之后的版本提供了kubectl debug能通过临时容器的方式给正在运行的 Pod 注入一个调试容器共享进程命名空间# 在目标 Pod 上创建临时调试容器 kubectl debug pod-name -it --imagebusybox # 如果目标 Pod 启动失败可以复制一份出来调试 kubectl debug pod-name -it --copy-todebug-pod-name --containercontainer-name --imagebusybox还有一种场景是节点本身出了问题你想直接看节点上的状态但节点没有 SSH 登录权限。这时候可以# 在节点上创建调试容器需有相应权限 kubectl debug node/node-name -it --imagenginx4.4 文件拷贝与资源用量有时需要把容器里的 dump 文件、日志包、配置拉出来分析用kubectl cp就行kubectl cp namespace/pod-name:/path/to/file ./local-file查看资源使用率是定位性能问题的基本操作# 查看节点 CPU、内存实时用量 kubectl top node # 查看 Pod 的实时资源用量 kubectl top pod # 按 CPU 使用率排序 kubectl top pods -A --sort-bycpu前提是你部署了 metrics-server。kubectl top的数据对排查节点明明没跑几个业务为什么内存显示这么高之类的问题特别有用。很多人把所有 Pod 都调度到同一个节点业务请求一高top 命令一刷就暴露了资源争抢的真相。5. 存储与配置PV/PVC、ConfigMap、Secret 的日常操作网络链路跑通了、业务 Pod 健康了存储和配置就是下一个容易出幺蛾子的地方。5.1 PV/PVC/StorageClass 链路排查PVC 一直 Pending是存储这块出现频率最高的故障。完整链路检查如下# 查看 PVC 状态 kubectl get pvc -A # 查看 PV 状态 kubectl get pv # 查看 StorageClass kubectl get sc # 查看某个 PVC 的详细事件 kubectl describe pvc pvc-namePVC Pending 的常见原因和排查路径PVC 指定了 storageClassName但集群里不存在这个 StorageClass -kubectl get sc确认名称新的 name 与旧 name 名牌不匹配时不会自动创建动态供给。StorageClass 存在但对应的 provisioner比如云厂商的 CSI 插件没部署或状态不健康 - 查看kubectl get pods -n kube-system里存储相关的 controller Pod。静态供给场景下PV 和 PVC 的容量或访问模式不匹配 - 查看 PV 的capacity和 PVC 的accessModes。动态供给创建的云盘达到上限或欠费 - 查看 storageclass 对应云厂商控制台。如果只是查看存储卷的容量我习惯用一条命令kubectl get pvc -A -o custom-columnsNS:.metadata.namespace,NAME:.metadata.name,CAP:.status.capacity.storage,STATUS:.status.phase5.2 ConfigMap 与 Secret创建、更新与热加载日常创建配置文件# 从目录创建 ConfigMap kubectl create configmap app-config --from-fileconfig/ # 从键值字面量创建 kubectl create configmap app-config --from-literalkey1value1 --from-literalkey2value2 # 从文件创建 Secret kubectl create secret generic app-secret --from-filesecret.txt # 查看 Secret 内容base64 编码 kubectl get secret app-secret -o jsonpath{.data.password} | base64 -d这里要敲响两个警钟。第一个警钟kubectl get secret默认显示的是 base64 编码后的内容base64 只是编码不是加密。如果你的 Secret 里有数据库密码、API Key千万不要直接贴到仓库或聊天工具里。生产环境建议使用 SealedSecret、ExternalSecret 这类工具至少也要对 Secret 做 Git 加密。第二个警钟修改 ConfigMap 后Pod 里的配置不会自动热更新。如果应用是通过环境变量注入配置的改 ConfigMap 后必须重启 Pod 才生效# 滚动重启 Deployment使新的 ConfigMap 配置生效 kubectl rollout restart deployment/deployment-name如果应用是通过 volume 挂载 ConfigMap 的K8S 会自动把新配置同步到卷里但应用自身是否监听配置文件变化并重新加载又是另一回事。很多中间件都有自己的 reload 机制reload 的前提是配置文件真的变了这个同步过程有延迟。所以最稳妥的做法永远是改完 ConfigMap 或者 Secret 后kubectl rollout restart对应的 Deployment别指望热更新能覆盖所有应用场景。6. 一次真实故障的完整排查链路把命令串起来用前面按资源类别拆开了讲这一章用一个完整的故障场景把这些命令串起来走一遍。场景很典型一套单节点 K8S 环境上跑了整套微服务业务方反馈某个服务一直起不来部分 Pod Pending部分 Pod CrashLoopBackOffService 能解析但请求不通。听到这种描述你的排查路径应该是线性的。6.1 全局扫描与现象确认第一步不看单个 Pod先看全局# 找出所有异常状态的 Pod kubectl get pods -A | grep -v Running如果输出里有一堆 Pending 的 Pod先看它们卡在哪一层kubectl describe pod pending-pod-namedescribe 的 Events 部分常见以下几种导致 Pending 的情况0/1 nodes are available: 1 Insufficient cpu.- 节点 CPU 不够请求的 CPU 超过节点的可分配量。0/1 nodes are available: 1 node(s) had taint {node-role.kubernetes.io/master: }, that the pod didnt tolerate.- Pod 不能容忍节点上的污点默认不会被调度到控制面节点。FailedScheduling due to PersistentVolumeClaim is not bound- 依赖的 PVC 没就绪。单节点集群最麻烦的地方在于控制面组件和业务 Pod 抢同一台机器的资源。你kubectl top node一看可能发现内存已经被各种系统组件吃光了。这种场景的解法很直接要么清理闲置镜像和日志要么把请求量调小要么迁移到资源更充裕的云主机上。6.2 追踪 CrashLoopBackOff 的根因Pending 的问题解决后又有一批 Pod 在 CrashLoopBackOff这时候按我给的经验来# 先看当前容器日志 kubectl logs pod-name # 如果是重启过必须看上一个容器的日志 kubectl logs pod-name --previous # 同时观察事件判断是不是 OOMKilled kubectl get events --field-selector involvedObject.namepod-name --sort-by.lastTimestamp日志和事件分开看会漏信息。我见过最典型的例子容器日志里报的是connected to database failed从字面上看像数据库地址配错了但事件列表里显示的却是OOMKilled说明是内存 limit 设置过小进程还没把连接池建好就被系统杀了。如果不看事件只看日志你可能会在数据库配置上浪费一整天。确定是 OOMKilled 之后做法不是直接加大节点内存而是先检查这两份东西# 查看当前 Deployment 的资源限制 kubectl get deployment name -o yaml | grep -A5 resources # 查看节点实际可分配资源 kubectl describe node node-name | grep -A10 Allocated resources如果 limit 设得远比 request 大会导致节点资源超卖Pod 密集时某个 Pod 被 OOM 杀死其实是资源竞争的结果。调优方向是让 request 与 limit 尽量接近实际使用量而不是盲目加内存。6.3 网络链路的分层验证Pod 都 Running 了Service 也能解析但业务说请求不通。这时候按分层验证的思路来排# 第一步进入业务 Pod验证本机端口是否在监听 kubectl exec -it pod-name -- curl localhost:8080/health # 第二步验证 Service 的 ClusterIP 是否通 kubectl exec -it pod-name -- curl http://cluster-ip:port/health # 第三步验证服务名是否通走 DNS 解析 kubectl run tmp-debug --rm -it --imagebusybox --restartNever -- wget -qO- http://service-name:port/health # 第四步如果 NodePort 也不通检查 kube-proxy 和节点安全组 kubectl logs -n kube-system -l k8s-appkube-proxy --tail20第一二步验证的是 Pod 本身和 Service 转发第三步验证的是 DNS 到 CoreDNS 这条链路第四步验证的是南北向流量。每一步之间若是失败故障范围就缩小一层这也正是排查思路的价值所在。如果应用相同 namespace 下能通、跨 namespace 不通优先怀疑 NetworkPolicy如果 NodePort 在集群外不通集群内却通优先怀疑云平台安全组和防火墙规则。这套链路跑完九成网络类故障都能定位到具体层。6.4 压测与迁移场景的命令配合把上面这套链路配合压测和迁移一起看才能真正感受到命令的价值。做迁移到云上并且做高并发验证这类工作时我的命令顺序通常是迁移前kubectl get pods -A摸清所有微服务kubectl get pvc -A盘点有状态服务的存储kubectl get configmaps,secrets -A收集配置和密钥这一套清单直接决定迁移要搬运哪些东西。迁移中新环境kubectl apply -f一套声明式 YAML 拉起来全部工作负载用kubectl rollout status确认每个 Deployment 收敛完成。压测前kubectl top node看资源基线kubectl get endpoints -A确认后端都有健康 Endpoint如果有 Prometheus 监控则顺手把采集目标状态一起确认。压测中kubectl top pod观察各 Pod 资源曲线kubectl get events盯异常事件一旦某个副本被 OOM 或探针失败能第一时间看到。这套流程跑下来迁移和压测就不是玄学而是一步步可以被命令验证的过程。最后分享一个小习惯我在每个集群的运维笔记里都维护一个命令速查页每次踩完坑就把那条救命命令记进去旁边标注当时的排查思路。版本升级、集群迁移的时候翻一翻这本笔记比临时搜任何官方文档都管用。K8S 的命令多到你不可能全背下来但出问题时知道该用哪一条、为什么用它这件事是真的能靠积累练出来的。