企业官网建设流程全解析

1. 先聊聊我为什么要整理这份命令清单

干这行久了，你会发现一个特别真实的现象：每天敲得最多的命令，往往不是那些花里胡哨的骚操作，而是来回就那几十条。我电脑的终端历史记录里，翻来覆去出现的就是ls、cd、grep、docker ps、git status这些基础货，但恰恰是这些基础货，用不对的时候最容易卡壳。

入行前几年，我特别迷信“背命令”，恨不得把 Linux 常用命令大全全文背下来。后来发现完全没必要，因为工具太多了，今天用 Docker，明天调 HDFS，后天写 MATLAB 脚本，你不可能每一条命令都记在脑子里。真正高效的思路是：把高频命令按场景整理成自己的速查笔记，用到的时候三秒钟查出来，比死记硬背靠谱得多。这也是我做这份“个人使用-常用命令”清单的初衷。

这份清单不是什么系统教程，看起来更像是我在命令行世界里摸爬滚打多年后沉淀下来的“口袋笔记本”。内容包括 Linux 基础操作、Git 版本控制、容器编排、服务调试、数据处理等日常高频场景，每一类都附带了我在实际项目中踩过的坑和总结出来的命令用法。无论你是刚入行的运维新人、转行做后端开发的程序员，还是天天跟集群打交道的数仓工程师，按图索骥都能省下不少查文档的时间。

1.1 从“记不住”到“记笔记”的转变

很多人有个误区，觉得记不住命令就是技术不行。我见过工作七八年的老开发，照样会为了一条tar解压参数去翻手册。命令行这东西，本质上就是工具的“操作面板”，面板上按钮那么多，谁能全部记住呢？

我自己总结了一套整理命令笔记的方法。不是把网上的“Linux 常用命令大全”复制粘贴过来就完事，那样存了也不会看。我的做法是：每遇到一个场景，就先把解决当前问题的命令记录下来，后面再遇到同类问题时去翻笔记，顺手把命令跑一遍，如果发现更好用的参数就补上去。这样积累下来的笔记，每条命令都带着真实的上下文，下次用的时候一眼就能看懂。

1.2 这份清单适合谁

如果你还处在复制粘贴命令、跑完不知道什么意思的阶段，这份清单能帮你建立一条清晰的“场景-命令”映射关系。比如你看到“查看端口是否被占用”，就能想到netstat -tunlp | grep或ss -tunlp；看到“容器日志一直刷屏”，就能想到docker logs -f --tail这类组合。

如果你是老手，这部分内容可能大部分你都见过，但其中关于排查思路和参数细节的说明，说不定也能帮你查漏补缺。毕竟命令行工具更新迭代很快，很多新参数和技巧，平时不专门去研究是真的不知道。

2. Linux 基础命令：用得最频繁的高频场景

Linux 命令是整份清单的地基。无论你后续用 Docker、K8s 还是 Git，最终都要落在操作系统这个层面上。我按日常使用频率排个序，把真正高频的操作分成三类：系统状态查看、文件处理和日志追踪、权限与进程管理。

2.1 系统状态查看与网络定位

查 IP 是最高频的操作之一，但很多人只知道ifconfig，这台机器没装 net-tools 就直接抓瞎。我现在的习惯是优先用ip addr，系统自带，输出格式也干净。如果只是想看某个网卡的 IP，可以加ip addr show eth0，或者在后面接| grep inet过滤一下，只留 IP 信息。

# 查看所有网卡 IP ip addr # 只查看 eth0 的 IP 地址 ip addr show eth0 | grep inet

说到网络排查，ping和telnet属于连通性测试的入门命令，但项目里经常碰到“外网能通、内网端口就是连不上”的情况。这时候我一般先用telnet 目标IP 端口测端口通不通，再用nc -vz 目标IP 端口做一次快速探测。如果端口不通，接下来就要上traceroute一步步看数据包在哪一跳断了。

举一个我自己的例子。有次排查一个服务间调用超时，两台机器 ping 是通的，但业务端口怎么都连不上。我先在客户端机器上执行telnet 10.0.0.8 8080，提示 Connection refused，确认是目标端口没有监听；再上服务器执行ss -tunlp | grep 8080，发现那个进程压根没起来，最后查出来是启动脚本里一个环境变量写错了。整个过程五分钟搞定，靠的就是这条排查链路。

2.2 文件处理和日志追踪

日志是后端和运维排查问题的救命稻草。Linux 下查看日志，最核心的两条命令就是tail和grep，组合起来用能解决 80% 的日志排查需求。

# 实时跟踪日志输出 tail -f app.log # 跟踪日志并从最后 200 行开始显示 tail -200f app.log # 从日志中过滤关键字，并显示前后 5 行 grep -n -C 5 "ERROR" app.log

tail -f是实时跟踪日志文件新增内容的利器，配合grep做关键字过滤，基本能替代专门的日志平台做快速定位。grep -C 5这个参数很容易被人忽略，它的意思是把命中关键字的上下文各 5 行也打印出来，排查问题的时候能少走很多弯路。

文件操作方面，du -sh *查看目录占用空间大小、df -h查看磁盘剩余空间都是日常必备。大目录定位也别一个个找了，直接du -h --max-depth=1 | sort -hr，一层层往深处看，磁盘满的问题基本十分钟内定位到。

2.3 权限与进程管理

线上环境最怕一个字：乱。文件权限不对导致服务起不来，是新手和老手都会踩的坑。我后来养成了一个习惯，修完配置先ls -l看一眼权限和属主属组，确认没问题再重启服务。

进程管理里，ps -ef | grep java是排查进程是否存在的标准姿势，但ps -ef输出信息太全，看起来费劲。我一般会配合grep -v grep把 grep 自身进程过滤掉，或者用pgrep -f java直接拿 PID。如果想知道某个 PID 对应的完整启动命令，可以看/proc/PID/cmdline：

# 查看某个进程的完整启动命令 cat /proc/12345/cmdline | tr '\0' ' ' # 显示进程的 CPU 和内存占用排行 top -o %CPU

top 命令跟 Windows 的任务管理器差不多，但功能强很多。top -o %CPU可以按 CPU 占用率排序，一眼就能看到是哪个进程在“吃”资源。动态刷新界面里，按P键按 CPU 排序，按M键按内存排序，这两个快捷键比鼠标点来点去快多了。

3. Git 命令：版本控制里的日常操作流

Git 是我日常接触频率仅次于 Linux 命令的工具。一个人折腾项目还好，一旦进团队协作，分支管理、代码合并、冲突解决这些动作天天都在发生。我整理 Git 常用命令时，没有按文档顺序罗列，而是按照“日常开发流程”来组织，这样更贴近真实使用场景。

3.1 工作区、暂存区、提交区的三区概念

理解 Git，关键是理解它的三区模型：工作区（你正在编辑的文件）、暂存区（准备提交的内容）、版本库（已提交的历史）。很多命令操作理解不了，都是因为对这三区的关系不清楚。

日常开发中最常用的流程是：

# 查看当前仓库状态 git status # 将文件加入暂存区 git add . # 提交到版本库 git commit -m "本次修改说明" # 推送到远程仓库 git push origin main

这三步走下来，一个完整的本地修改-提交-推送流程就完成了。但实际工作中往往没这么顺。我经常会碰到把不该提交的文件加进了暂存区的情况，这时候需要用git reset HEAD 文件名把文件从暂存区撤回来，工作区的内容保持不变。

# 从暂存区撤出，不改动工作区文件 git reset HEAD 文件名 # 撤销工作区的修改（危险操作，慎用） git checkout -- 文件名

git checkout -- 文件名这条命令必须提醒一句：它是把工作区的文件还原成暂存区或版本库里的内容，一旦执行，你本地改的东西就没了。用之前先git status看清楚，确认这个文件确实不想要了再执行。

3.2 分支操作与合并冲突

团队协作里，分支管理是门必修课。我从早期一锅粥地直接在 main 上改代码，到后来老老实实按 feature 分支开发，踩过不少坑。现在我的习惯是每开发一个功能就拉一个分支，功能完成后再合并回主分支。

# 查看本地和远程全部分支 git branch -a # 基于当前分支新建并切换 git checkout -b feature/optimize-api # 拉取远程最新代码并合并到当前分支 git pull origin main # 合并指定分支到当前分支 git merge feature/optimize-api

合并冲突是团队协作里最让人头疼的事。以前我一看到CONFLICT就慌，后来总结出一个思路：不要慌着删别人的代码，先把冲突段落里的<<<<<<<、=======、>>>>>>>标记看懂，左边是当前分支的内容，右边是合并进来的分支的内容，然后逐段选择保留哪部分。

# 查看冲突文件列表 git status # 解决冲突后标记为已解决 git add 冲突文件 # 继续完成合并 git commit

解决完冲突，一定要在本地编译跑一遍，确认没有问题再 push。线上环境因为合并没有验证导致代码互相覆盖的问题，我见过不止一次。

3.3 撤销与历史修改的兜底方案

Git 给了你犯错的机会，但也要求你足够熟悉撤销的几种方式。我自己的经验是，撤销命令一定要分清场景，不然很容易把整个历史搞乱。

• 如果只是提交信息写错了，用git commit --amend -m "新的提交信息"可以修改最近一次提交的信息。
• 如果代码已经提交但还没推送到远程，想回退到上一个提交，用git reset --soft HEAD~1，这样文件会保留在工作区，只是撤销了 commit。
• 如果代码已经推送到远程，并且团队其他人可能已经拉取过，千万不要用 reset，要用git revert生成一个反向提交。

# 修改最近一次提交信息 git commit --amend -m "改好的提交说明" # 回退到上一个提交，保留工作区修改 git reset --soft HEAD~1 # 生成一个新的反向提交，安全地回退 git revert HEAD

revert和reset的区别，简单理解就是：reset 是回到过去，会改写历史；revert 是沿着历史继续往前，新增一个提交来抵消之前的内容。回到过去这件事，只有你自己一个人开发时才适合干，团队协作场景下一律用 revert，这是我在生产环境里学到的教训。

4. Docker 与 K8s：容器环境下的常用命令

容器化普及之后，Linux 命令的使用场景开始和容器命令深度绑定。本地开发环境、测试环境、生产环境，到处都在跑容器。我整理这部分命令时，重点放在“快”上：一个容器诊断问题，怎么用最少的命令链快速定位。

4.1 Docker 镜像与容器的生命周期管理

Docker 的核心概念就两个：镜像（Image）和容器（Container）。镜像好比是模板，容器是模板运行起来的实例。我日常最常用的 Docker 命令基本围绕这两个对象展开。

# 查看运行中的容器 docker ps # 查看所有容器（包含已停止的） docker ps -a # 进入运行中容器的交互式终端 docker exec -it 容器ID /bin/bash # 停止、启动、重启容器 docker stop 容器ID docker start 容器ID docker restart 容器ID # 构建镜像 docker build -t 镜像名:标签 .

调试容器内部问题的时候，docker exec -it 容器ID /bin/bash是我的首选命令。进去之后先看进程、看网络、看文件，基本跟操作一台普通 Linux 机器一样。如果容器里没有 bash，就换成/bin/sh，更轻量一些。

查看容器日志也是高频操作。Docker 日志的统一出口是标准输出，所以应用里console.log或者System.out.println的输出都能直接通过docker logs拿到：

# 查看容器最近 200 行日志 docker logs --tail 200 容器ID # 实时跟踪容器日志 docker logs -f 容器ID

4.2 Kubernetes 的基本操作

到了 K8s 环境，你会发现原来 docker ps 能看的东西，现在都打散到了多个命名空间和多个 Pod 里。K8s 的命令体系比 Docker 复杂不少，但核心思路是一致的：先看资源状态，再进 Pod 排查。

# 查看当前命名空间下的 Pod kubectl get pods # 查看所有命名空间下的 Pod kubectl get pods -A # 查看 Pod 详细信息（事件、状态、调度情况） kubectl describe pod Pod名称 # 进入 Pod 内部进行排查 kubectl exec -it Pod名称 -- /bin/bash # 查看 Pod 日志 kubectl logs -f Pod名称

K8s 排查问题，我一般遵循“三层递进”的顺序：第一层kubectl get pods看状态，发现 Pod 没 Running 或者一直 CrashLoopBackOff，就进入第二层kubectl describe pod看事件，里面有镜像拉取失败、资源不足、健康检查失败这些具体原因；第三层才是kubectl logs看应用日志。很多人一上来就 logs，结果日志里什么都没有，反而浪费时间。

4.3 资源查看与端口占用排查

容器环境的资源排查和物理机略有不同。Docker 这边，docker stats能实时看到每个容器的 CPU 和内存占用，效果类似宿主机上的 top 命令：

# 实时查看所有容器的资源占用 docker stats # 查看容器的端口映射 docker port 容器ID

遇到端口冲突的时候，我一般会在宿主机上先用ss -tunlp | grep 端口号确认端口被哪个进程占用，再docker ps看看是不是有容器的端口映射和宿主机已有进程冲突了。有一次排查线上服务启动失败，就是这个原因：新容器映射的 8080 端口，被宿主机上一个残留的 Java 进程占着，容器的端口根本绑不上，得先处理掉旧进程再重启容器。

K8s 环境里查端口被谁占用要麻烦一些，通常要看 Service、Endpoint 和 Pod 的对应关系。kubectl get svc -A看服务，kubectl get endpoints -A看后端的实际 IP 和端口，一层层对上。大部分时候，问题出在 Service 选择器（selector）写错了，导致 Endpoint 里没有对应的 Pod。

5. Nginx、Vim、GDB：服务配置与调试工具

这三样工具在传统运维和后端开发场景里出现的频率非常高。Nginx 是流量入口的第一道关卡，Vim 是服务器上改配置的必备编辑器，GDB 则是排查 C/C++ 程序崩溃和性能问题的利器。把它们放在一起，因为都和服务端“调、试、改”相关。

5.1 Nginx 配置校验与热重载

Nginx 是一个高性能的 Web 服务器和反向代理服务器。很多人配置 Nginx 的时候，写完配置文件直接重启服务，结果语法有误，服务直接挂掉，线上访问瞬间中断。我自己的习惯是：改完配置，先做语法检查，再优雅重启。

# 检查 Nginx 配置语法 nginx -t # 热重载配置（不中断服务） nginx -s reload # 查看 Nginx 版本号 nginx -v

nginx -t会告诉你配置文件有没有语法错误、引用的文件路径是否存在。nginx -s reload是平滑加载新配置，加载过程中已建立的连接不会被中断，特别适合线上环境。很多新手分不清 restart 和 reload 的区别：restart 是把 Nginx 进程杀掉再重新启动，存在短暂的服务不可用窗口；reload 是重新加载配置文件，不中断现有的 worker 进程，生产环境优先选 reload。

5.2 Vim 的高效编辑模式

服务器上没有图形界面，改配置基本靠 Vim。很多人第一次进 Vim 不知道怎么退出，这种“进得去出不来”的尴尬是每届菜鸟都躲不过的坎。Vim 的核心是模式切换：普通模式、插入模式和命令模式。

# 打开文件 vim /etc/nginx/nginx.conf # 按 i 进入插入模式，开始编辑 # 编辑完按 Esc 回到普通模式 # 输入 :wq 保存并退出

让我梳理一条最短的 Vim 命令链路：打开文件 → 输入/搜索关键字，例如搜索 server_name → 按n跳到下一个匹配 → 按i进入编辑模式修改 → 按Esc→ 输入:wq保存退出。这套流程能覆盖 80% 的服务器文件修改场景。

Vim 里还有一个非常有用的可视模式，按v进入，移动光标选中文本，再按y复制、d删除。剪切粘贴不再依赖鼠标，效率非常高。刚上手的时候可能会觉得别扭，但坚持两周，你会发现自己已经离不开它了。

5.3 GDB 调试的基础流程

GDB 是 Linux 下调试 C/C++ 程序的神器。平时写代码我不怎么用 GDB，但程序一崩溃，尤其是出现 core dump 的时候，GDB 就是救命稻草。调试之前，编译的时候要加-g选项，保留调试信息，否则 GDB 看不到函数名和行号。

# 调试可执行程序 gdb ./app # 带参数调试 gdb --args ./app --config=app.conf # 分析 core dump 文件 gdb ./app core # 在 GDB 内部常用的命令 # b main 在 main 函数打断点 # run 运行程序 # bt 查看函数调用栈 # info locals 查看当前函数的局部变量 # quit 退出 GDB

程序崩溃后最常用的操作是bt，查看崩溃时的函数调用栈，能直接定位到是哪个函数在什么调用链路上出的问题。这个过程好比是交通事故现场勘查，先看痕迹，再还原事故发生的过程。配合info registers查看寄存器的值，很多内存相关的崩溃原因都能顺藤摸瓜查出来。

6. 开发环境与数据链路：HDFS、Conda、ADB、MATLAB

这一部分更像是一个开发者和数据处理工程师的“工作台”。HDFS 是大数据生态的存储底座，Conda 是 Python 环境管理的绝佳工具，ADB 是 Android 开发调试的连接桥，MATLAB 则是算法研究和数据仿真的重武器。这几样东西看着杂，但它们有一个共同点：日常操作高度依赖命令行。

6.1 HDFS 文件操作

HDFS 全称 Hadoop Distributed File System，是分布式文件系统。它的命令风格模仿了 Linux 文件系统命令，但前缀是hdfs dfs或hadoop fs。

# 查看目录下的文件列表 hdfs dfs -ls /data # 创建目录 hdfs dfs -mkdir -p /data/warehouse # 上传本地文件到 HDFS hdfs dfs -put local.txt /data/ # 下载 HDFS 文件到本地 hdfs dfs -get /data/result.txt ./ # 查看文件内容 hdfs dfs -cat /data/result.txt | head -100

HDFS 命令和 Linux 命令最大的区别在于路径是 HDFS 命名空间里的路径，不是本地路径。写脚本的时候最容易踩的坑就是路径写错。我一般先hdfs dfs -ls /看一眼根目录结构，然后再往下走。还有一个要注意的：hdfs dfs -mkdir -p才会自动创建多级父目录，不加-p时父目录不存在会报错。

6.2 Conda 环境管理

玩 Python 项目最怕的就是环境依赖冲突。不同项目依赖不同版本的包，如果全装在一个 Python 环境里，一段时间后就是一团乱麻。Conda 解决的就是这个问题：为每个项目创建独立的环境，互不干扰。

# 创建指定 Python 版本的环境 conda create -n myenv python=3.9 # 激活环境 conda activate myenv # 退出当前环境 conda deactivate # 查看所有环境 conda env list # 导出当前环境配置 conda env export > environment.yml

conda env export > environment.yml这条命令特别适合团队协作。新建机器时只需要conda env create -f environment.yml就能复现一模一样的 Python 环境，省去了手动安装依赖包的繁琐步骤。

我踩过的一个坑是 Conda 和系统自带的 Python 混用。在激活 Conda 环境后，终端输入的python应该是环境里的 Python，但有时候 shell 的 PATH 优先级不对，又把系统的 Python 找出来了。解决办法是在激活环境后先执行which python，确认清楚再用，避免装包装错到系统 Python 里。

6.3 ADB 调试与 MATLAB 脚本化

ADB（Android Debug Bridge）是 Android 开发和测试人员的标配工具。我平时用 ADB 最多的是抓取 Android 设备的日志和安装调试包。

# 查看连接设备 adb devices # 安装应用 adb install app.apk # 抓取设备日志并过滤关键字 adb logcat | grep "AndroidRuntime" # 进入设备 shell adb shell # 从设备拉取文件到本地 adb pull /sdcard/test.mp4 ./

MATLAB 的命令行使用分两种场景：交互式命令行直接跑和脚本文件批量跑。交互式命令行适合快速验证算法，脚本文件适合完整的流程处理。MATLAB 命令的常用习惯是加分号抑制输出，分号是“这条命令不打印结果”，在脚本里能避免刷屏。

# 清除变量和命令窗口 clear; clc; # 查看变量的详细信息 whos # 运行脚本 run('myscript.m') # 显示绘图窗口 plot(x, y); grid on; xlabel('X轴'); ylabel('Y轴');

写 MATLAB 脚本时，我养成了一个习惯：所有关键代码片段都用%%分节，这样可以在编辑器里按“节”运行，调试效率会高很多。这个习惯和写 Python 时用 Jupyter Notebook 的 cell 是一个逻辑。

7. 常见问题与排查技巧实录

命令行用得越多，遇到的报错就越五花八门。这里把我这些年踩过的一些典型坑和排查技巧整理成清单，希望对你有用。

7.1 命令找不到怎么办

最常见的报错就是command not found。遇到这个，先不要慌，大多数情况是命令没装或者没有加入 PATH。

# 查看某条命令是否存在 which nginx # 或者 type nginx # 临时加入 PATH export PATH=/usr/local/nginx/sbin:$PATH # 永久加入 PATH（写入 profile 文件） echo 'export PATH=/usr/local/nginx/sbin:$PATH' >> ~/.bashrc source ~/.bashrc

排查思路是：先用which看命令是否存在，如果存在但没有执行成功，基本就是 PATH 的问题；如果which没输出，说明命令没装，先yum install或apt install。这里有一个小技巧：很多命令安装后，bin 目录不在默认 PATH 里，比如 Nginx 安装后默认在/usr/local/nginx/sbin，如果不把这个目录加进 PATH，直接敲nginx就会 command not found。

7.2 端口被占用的快速定位

端口被占用是开发调试里最普遍的问题之一。启动服务时报“Address already in use”，十有八九是之前的进程没有彻底退出，或者端口被其他服务占用了。

# 查看谁占用了端口 ss -tunlp | grep 8080 # 或者 netstat -tunlp | grep 8080 # 直接杀掉占用端口的进程 kill -9 $(ss -tunlp | grep 8080 | awk '{print $7}' | cut -d'=' -f2 | cut -d'/' -f1)

这里我把kill -9的复合命令也写出来了，但我要多嘴提醒一句：kill -9是强制杀死进程，生产环境慎用，因为进程可能正在处理请求或者写数据，直接被干掉的后果是数据损坏或服务不可恢复。更稳的做法是先kill PID（默认 SIGTERM），给进程一个优雅退出的机会，没有效果再考虑kill -9。这条经验是真实事故换来的，有次我直接用kill -9杀掉了一个正在写索引的进程，结果索引文件损坏，花了半天才重建干净。

7.3 用 alias 收纳高频命令

命令行高手和新手一个很明显的区别就是：高手会定义一堆自己的 alias。把一长串命令缩成一个简短的关键词，不仅敲起来快，还不容易记错。

# 常用缩写 alias ll='ls -lh' alias la='ls -a' alias grep='grep --color=auto' alias q='exit' # 工程化缩写 alias gp='git pull' alias gc='git commit -m' alias dps='docker ps' alias k='kubectl'

这些 alias 写在~/.bashrc或~/.zshrc里，保存后执行source立即生效。用 alias 最有成就感的一次是：我把一条特别长的 K8s 日志查询命令浓缩成了klog，后来每次排查问题都靠它一步到位，团队同事看到了还专门找我抄配置。

7.4 一份可以抄作业的命令速查表

最后，我把高频命令整理成一个速查表，方便你直接抄到自己的笔记里。

这张表远不是全部，但已经覆盖了日常工作中 80% 以上的高频操作。剩下的 20%，靠的是遇到具体问题时的搜索能力，以及把答案沉淀到笔记里的习惯。

8. 最后再分享一点我的个人习惯

命令行这条路，我最大的心得就是：不要试图背下所有命令，而是要建立一套“遇到问题 → 快速定位 → 解决 → 记录”的闭环。

记录这件事，以前我用文本文件，后来改用 Markdown 笔记，现在直接维护一个自己的速查脚本仓库。每次遇到新的问题，我先搜索、再实践，跑通了就顺手把命令整理进笔记里，加一行注释说明是解决什么问题的。一年下来，这份“个人使用-常用命令”清单已经积累了几百条条目，涉及 Linux、Git、Docker、K8s、Nginx、HDFS、Conda、ADB、MATLAB 等各式各样的工具。

另一件让我受益很深的事是：所有命令，我都尽量在本地虚拟机里先跑一遍，确认无误后再到生产环境操作。命令行工具本身不会犯错，犯错的是人，敲错参数、选错目录、搞错环境，这类低级错误谁也避免不了。多一层验证，就少一次事故。

最后一个小技巧：把最常用的命令做成一页纸速查表，打印出来贴在显示器旁边。别小看这种“原始”的方式，在终端里折腾半天查命令的时间，远比你抬头看一眼纸条多得多。你的命令行功底，不是看你会多少命令，而是看你在关键时刻能不能又快又准地用对那一条命令。