核心目标：以后遇到 GitHub、官网、README 里的各种安装命令，不再死记硬背，而是能判断：
我拿到的到底是什么？
它是源码还是已经编译好的程序？
每条命令是在下载、解压、编译，还是安装？
Ubuntu 应该优先选择哪种安装方式？
1. 先理解：Linux 中"安装软件"到底是什么
Windows 中我们经常双击：
xxx.exe然后一路"下一步"。
看起来安装只有一个动作，实际上安装程序帮我们偷偷完成了：
下载 / 准备软件
↓
检查依赖
↓
解压文件
↓
复制程序到指定目录
↓
安装库和配置
↓
让系统能够找到程序Linux 只是把这些步骤暴露得更多。
所以我们会看到：
sudo apt install git也会看到：
sudo apt install ./xxx.deb还可能看到：
tar -zxvf xxx.tar.gz
cd xxx
make
sudo make install甚至：
curl https://xxx.com/install.sh | bash这些命令表面差很多，但最终都是围绕：
获得软件
↓
准备依赖
↓
得到可执行程序
↓
把程序放到合适的位置
↓
让系统以后能找到并运行它2. 当前目录和"软件安装位置"不是一回事
这是最容易产生误解的一点。
例如：
cd ~/Desktop
sudo apt install git和：
cd /tmp
sudo apt install git结果通常没有区别。
因为：
apt install不会把 Git 安装进你当前所在的目录。
Linux 会按照自己的目录规范把文件分别放到系统目录，例如：
/usr/bin/ 可执行程序
/etc/ 配置文件
/usr/lib/ 库文件
/usr/share/ 软件共享数据
/var/log/ 日志
/usr/local/bin/ 手动安装的软件经常放这里所以：
当前目录 ≠ 软件安装目录。
但是当命令操作的是"当前目录中的文件"时，当前目录就很重要。
例如：
tar -zxvf redis.tar.gz这里必须能找到：
redis.tar.gz又例如：
make一般会寻找当前目录里的：
Makefile所以可以先记：
apt install 软件名在哪个目录执行通常无所谓。
而：
./xxx
make
tar xxx这种涉及本地文件的命令，就需要考虑当前目录。
3. Ubuntu 最推荐的软件安装方式：APT
Ubuntu 属于：
Debian 系 Linux它主要使用：
APT作为软件包管理工具。
最典型：
sudo apt install git看似只有一条命令，APT 实际会帮我们：
查找软件
↓
找到对应版本
↓
检查 CPU 架构
↓
下载 .deb 软件包
↓
检查依赖
↓
下载依赖
↓
安装软件
↓
记录软件安装信息所以只要 Ubuntu 软件仓库中有：
一般优先使用 APT。
常见命令：
sudo apt update作用：
更新"软件仓库目录"。
注意：
apt update通常不是升级软件本身。
它更像是在告诉系统：
软件仓库现在有哪些软件、有哪些新版本？
更新已经安装的软件：
sudo apt upgrade安装：
sudo apt install git卸载：
sudo apt remove git连配置一起清除：
sudo apt purge git查看某个软件是否存在：
apt search redis4. APT、dpkg 和 .deb 是什么关系
Ubuntu / Debian 的标准软件包格式是：
.deb可以粗略理解成 Windows 世界中的：
.msi例如：
xxx_2.1.0_amd64.deb通常包含：
xxx 软件名
2.1.0 软件版本
amd64 CPU 架构
.deb Debian 软件包安装本地 .deb 时推荐：
sudo apt install ./xxx_2.1.0_amd64.deb而不是优先：
sudo dpkg -i xxx.deb原因在于：
dpkg更加底层。
它主要负责：
安装、删除、管理
.deb软件包。
而：
APT除了能够调用底层软件包系统，还能负责：
软件仓库
下载
依赖关系
升级可以粗略理解：
APT
│
├─ 找软件
├─ 下载软件
├─ 解决依赖
└─ 调用底层包管理
│
dpkg
│
.deb所以 Ubuntu 用户安装本地 .deb：
sudo apt install ./xxx.deb一般最舒服。
5. GitHub Release 到底应该下载哪个文件
GitHub 软件经常在：
Releases中提供很多文件。
例如：
xxx-linux-amd64.tar.gz
xxx-linux-arm64.tar.gz
xxx_amd64.deb
xxx_arm64.deb
xxx.x86_64.rpm
xxx.AppImage
xxx.sha256
xxx.asc
Source code (zip)
Source code (tar.gz)不要看到一堆文件就乱选。
判断顺序：
1. 我的操作系统是什么？
2. 我的 CPU 架构是什么？
3. 这是安装包、预编译程序还是源码？6. 先学会判断 CPU 架构
Ubuntu 中：
uname -m如果显示：
x86_64那么 GitHub 中通常找：
x86_64
amd64
x64这几个名称在常见软件发布中基本都指：
64 位 Intel / AMD PC 架构。
普通 Intel / AMD 笔记本，大多数都是它。
如果：
uname -m输出：
aarch64那么通常应该选择：
arm64
aarch64例如：
树莓派
ARM 服务器
部分开发板
部分 ARM Linux 设备可能使用这种架构。
因此：
x86_64 ≈ amd64 ≈ x64
aarch64 ≈ arm64这个对应关系以后 GitHub 下载软件非常重要。
7. GitHub 常见文件后缀
7.1 .deb
例如：
xxx_amd64.deb这是：
Debian / Ubuntu 软件安装包。
Ubuntu 中通常优先考虑它。
安装：
sudo apt install ./xxx_amd64.deb7.2 .rpm
例如：
xxx.x86_64.rpm主要用于：
Fedora
RHEL
CentOS
Rocky Linux
AlmaLinux等 Red Hat 系 Linux。
你是 Ubuntu：
一般不要选择
.rpm。
7.3 .tar.gz / .tgz
这是：
压缩包。
重点：
.tar.gz只告诉你：
有一堆文件被打包并压缩了。
它并没有告诉你：
里面到底是源码还是已经编译好的软件。
因此可能出现两种情况。
情况 1：里面是预编译程序
例如：
xxx/
├── bin/
├── lib/
└── README可能解压以后就可以运行。
情况 2：里面是源码
例如：
xxx/
├── src/
├── include/
├── Makefile
├── CMakeLists.txt
└── README.md这时候你还需要：
编译所以：
看到
.tar.gz不要立刻判断它是安装包。
先看 Release 描述或者 README。
7.4 .zip
也是：
压缩包。
和 .tar.gz 一样：
后缀本身不能证明里面是源码还是二进制程序。
7.5 .AppImage
这是 Linux 中一种比较方便的：
便携式桌面应用格式。
可以粗略理解成：
Windows 绿色版软件。
下载：
xxx.AppImage有时需要：
chmod +x xxx.AppImage然后：
./xxx.AppImage即可启动。
这里：
chmod +x意思是：
给文件添加"可执行权限"。
不是安装。
7.6 .sh
例如：
install.sh这是：
Shell 脚本。
可能是安装脚本，也可能只是普通脚本。
执行：
bash install.sh或者某些情况下：
./install.sh但是：
不要看到
.sh就直接执行。
尤其是来源不明的脚本。
7.7 .bin
可能是：
已经编译好的二进制程序。
具体如何使用必须看项目说明。
7.8 .sha256
例如：
xxx.tar.gz.sha256这不是软件。
它用于：
校验下载文件有没有损坏或者被修改。
常见验证：
sha256sum xxx.tar.gz然后和官方提供的 SHA256 对比。
7.9 .sig / .asc
一般用于：
数字签名验证。
它们同样不是软件本体。
7.10 Source code (zip)
以及：
Source code (tar.gz)GitHub 每个 Release 基本都会自动提供。
它们就是：
这个 GitHub 仓库对应版本的源码快照。
重点：
不要因为看到
tar.gz就认为这是 Linux 安装包。
例如：
Source code (tar.gz)只是：
源码
+
tar.gz 压缩如果项目官方已经提供：
xxx_amd64.deb通常没必要去下：
Source code除非你就是想自己编译。
8. 源码安装到底是在干什么
例如下载：
redis-x.x.x.tar.gz然后：
tar -zxvf redis-x.x.x.tar.gz第一步仅仅是：
解压。
不是安装。
进入目录：
cd redis-x.x.x然后：
make这里才开始：
编译源码。
源码：
.c
.cpp经过编译：
源代码
↓
编译器
↓
机器能够执行的程序最后：
sudo make install通常是在：
把编译好的程序复制到系统规定的位置。
因此经典源码安装流程：
下载源码
↓
解压
↓
配置编译环境
↓
编译
↓
安装9. ./configure && make && make install
这是 Linux 非常经典的一套源码安装流程：
./configure
make
sudo make install分别对应：
第一步
./configure主要作用：
检查你的计算机环境，并准备编译配置。
例如可能检查：
有没有 gcc？
有没有某个库？
有没有某个头文件？
操作系统是什么？
安装路径是什么？最后可能生成：
Makefile第二步
make作用：
按 Makefile 中的规则编译项目。
可以理解：
源码
↓
make 根据 Makefile 指挥
↓
gcc / g++
↓
目标文件
↓
可执行程序 / 库第三步
sudo make install作用：
把编译结果复制到系统安装目录。
常见：
/usr/local/bin
/usr/local/lib
/usr/local/include所以：
configure
↓
准备
make
↓
编译
make install
↓
安装10. CMake 项目为什么安装命令又变了
现代 C / C++ 项目经常使用：
CMake而不是直接手写 Makefile。
可能看到：
mkdir build
cd build
cmake ..
make含义是：
源代码
↓
CMakeLists.txt
↓
CMake
↓
生成构建文件
↓
make
↓
编译器
↓
程序现代推荐写法也经常是：
cmake -S . -B build
cmake --build build其中：
cmake -S . -B build意思：
源码目录：.
构建目录：build然后：
cmake --build build意思：
编译 build 目录中的项目。
所以：
cmake本身一般不是"安装软件"。
它主要负责：
配置、生成和组织构建过程。
11. curl xxx | bash 到底是什么
经常看到：
curl https://example.com/install.sh | bash拆开：
curl URL作用：
从 URL 获取内容。
如果 URL 返回：
install.sh那么：
|管道会把前面获得的内容交给：
bash执行。
相当于：
下载安装脚本
↓
执行安装脚本安装脚本内部可能执行：
mkdir
cp
chmod
apt
wget
curl
echo等等。
因此：
curl | bash并不是特殊的 Linux 安装技术。
它只是：
下载别人写好的 Shell 脚本，然后立即执行。
因此安全上需要注意：
不要对不可信网站无脑执行
curl xxx | bash。
因为这相当于：
把别人给你的代码直接放到自己电脑上执行。
12. 为什么有时候 apt install 前面还有十几行命令
比如安装某些软件可能先要求：
curl ...
sudo mkdir ...
gpg ...
echo ...
sudo apt update
sudo apt install xxx看起来特别复杂。
实际上真正的安装可能仍然只是：
sudo apt install xxx前面的步骤是在：
添加第三方软件仓库。
原来的 APT：
APT
│
└─ Ubuntu 官方仓库加入软件官方仓库后：
APT
├─ Ubuntu 官方仓库
│
└─ 某软件官方仓库这样以后：
sudo apt updateAPT 不仅会查询 Ubuntu：
还会查询：
这个软件自己的官方仓库然后可以：
sudo apt install xxx以后：
sudo apt upgrade也能统一更新它。
所以很多"安装前几十行命令"的本质其实是：
加仓库
↓
验证仓库
↓
更新仓库信息
↓
apt install13. 软件仓库中的 GPG Key 是什么
添加第三方仓库时，经常看到：
GPG key或者：
gpg相关命令。
它的作用主要是：
验证你下载的软件包确实来自对应的软件发布者，而不是被别人伪造。
大概：
软件发布者
↓
给软件包签名
↓
你的系统拥有对应公钥
↓
APT 验证签名
↓
确认软件包可信所以第三方 APT 仓库常常包含两件事：
仓库地址
+
仓库签名公钥14. Snap 是什么
Ubuntu 中还会看到：
sudo snap install xxx这是另一套软件分发系统：
Snap传统 .deb 软件经常依赖：
系统中已经安装的库而 Snap 倾向于：
把程序运行所需的很多东西一起打包。
优点：
依赖冲突少
不同 Linux 环境更容易运行
安装简单
自动更新方便缺点可能包括：
软件包体积较大
部分软件启动稍慢
文件系统整合方式和传统软件不同因此 Ubuntu 上：
APT
Snap同时存在很正常。
15. Flatpak 是什么
另外还有：
Flatpak它和 Snap 的目标类似：
提供跨 Linux 发行版的软件分发方式。
桌面软件中比较常见。
因此你可能看到：
.deb
Snap
Flatpak
AppImage它们都是不同的软件分发形式。
16. 为什么 Python、Node 又有自己的安装命令
除了操作系统的软件管理器，还有：
编程语言自己的包管理器。
例如：
Python：
pip install requestsNode.js：
npm install axiosRust：
cargo install ripgrep它们和：
apt install管理的层级不同。
例如：
sudo apt install python3通常是在：
给 Ubuntu 系统安装 Python。
而：
pip install requests是在：
Python 环境中安装一个 Python 包。
所以可以这样理解：
操作系统层
│
├─ apt
├─ snap
└─ flatpak
Python 生态
└─ pip
Node.js 生态
└─ npm
Rust 生态
└─ cargo17. 为什么 Linux 安装软件的命令看起来千奇百怪
因为你实际上遇到的是完全不同的情况：
① Ubuntu 官方仓库
↓
apt install xxx
② 下载好的 .deb
↓
apt install ./xxx.deb
③ Snap
↓
snap install xxx
④ AppImage
↓
chmod +x
./xxx.AppImage
⑤ 已经编译好的压缩包
↓
tar 解压
直接运行
⑥ 源码
↓
解压
configure / cmake
make
make install
⑦ 官方安装脚本
↓
curl / wget
bash
⑧ Python 包
↓
pip
⑨ Node.js 包
↓
npm因此：
不是 Linux "没有统一安装规则"。
而是你面对的软件来源和软件形态本来就不一样。
Windows 其实也有：
.exe
.msi
Microsoft Store
winget
zip 绿色版
pip
npm
Steam只是普通 Windows 用户主要接触：
双击 .exe所以这种差别没有 Linux 明显。
18. GitHub Release 实战判断流程
假设：
uname -m输出：
x86_64GitHub 提供：
myapp_amd64.deb
myapp_arm64.deb
myapp.x86_64.rpm
myapp-linux-amd64.tar.gz
myapp-linux-arm64.tar.gz
myapp.AppImage
Source code.zip
Source code.tar.gz你的思考过程应该是：
我是 Ubuntu
↓
优先找 .deb
↓
有
↓
CPU 是 x86_64
↓
x86_64 ≈ amd64
↓
选择：
myapp_amd64.deb然后：
sudo apt install ./myapp_amd64.deb如果没有 .deb：
桌面软件？
↓
可以看看 AppImage如果没有：
看 linux-amd64.tar.gz然后去 README 判断：
这是已经编译好的程序，还是源码？
而：
Source code.zip
Source code.tar.gz通常最后再考虑。
因为那意味着：
你可能需要自己编译。
19. chmod +x 是什么
Linux 文件有三类基础权限：
r = read
w = write
x = execute例如：
chmod +x xxx.sh就是：
给 xxx.sh 添加可执行权限。
之后：
./xxx.shShell 才允许把它当程序执行。
同理：
chmod +x xxx.AppImage也是：
允许执行这个 AppImage 文件。
注意：
chmod +x不是安装。
它只是改变文件权限。
20. ./xxx 为什么前面有 ./
假设当前目录有：
hello运行：
helloShell 通常不会默认在当前目录寻找。
它只会去：
PATH中的目录找。
而：
./hello含义就是：
.
当前目录
/
目录中的
hello也就是：
运行当前目录里的 hello。
所以：
./xxx不是特殊命令。
它就是：
指定一个程序的路径。
21. PATH：为什么安装后可以直接输入程序名
例如：
sudo apt install git安装完成以后：
git就能运行。
为什么不用：
/usr/bin/git？
因为 Shell 有一个环境变量：
PATH查看：
echo $PATH可能得到：
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:...输入：
gitShell 会依次去：
/usr/local/sbin/git
/usr/local/bin/git
/usr/sbin/git
/usr/bin/git等目录寻找。
最后找到：
/usr/bin/git于是运行。
所以可以简单理解：
输入 git
↓
Shell 查询 PATH
↓
找到 /usr/bin/git
↓
运行这也是为什么：
当前目录和：
程序安装目录没有直接关系。
程序安装进：
/usr/bin以后，你站在：
/home
/tmp
/Desktop都可以直接：
git22. 如何查看一个命令到底在哪里
非常实用。
例如：
which git可能输出：
/usr/bin/git说明：
当前执行的 git 是
/usr/bin/git。
还可以：
command -v git作用类似，而且在 Shell 脚本中更加常见。
23. /usr/bin 和 /usr/local/bin 的区别
简单理解：
/usr/bin更多是：
系统包管理器管理的软件。
比如：
apt install git得到的程序经常位于：
/usr/bin而：
/usr/local/bin通常更适合：
用户自己手动安装的软件。
例如：
sudo make install很多项目默认可能把程序放到：
/usr/local/bin这样就可以避免：
手动安装的软件和系统包管理器的软件混在一起。
24. /opt 又是什么
有一些完整的第三方应用会放到：
/opt例如可能出现：
/opt/google/
/opt/xxx/可以理解成：
给比较独立的第三方大型软件准备的位置。
它可能把整个程序目录都放进去。
25. /usr/bin 里的程序和真正的软件全部内容不是一回事
例如一个软件可能包含：
/usr/bin/xxx 可执行程序
/etc/xxx/ 配置
/usr/lib/xxx/ 库
/usr/share/xxx/ 数据
/var/log/xxx/ 日志所以：
一个 Linux 软件通常不是一个单独文件。
APT 安装时会把不同类型的文件分别放到不同目录。
26. 软件"安装""运行""服务启动"是三回事
尤其后面装：
Redis
MySQL
Nginx非常容易混淆。
例如：
sudo apt install nginx这是：
安装 Nginx。
但是 Nginx 是服务器程序，它还可能有：
启动
停止
重启
开机自启例如使用 systemd：
sudo systemctl start nginx启动。
sudo systemctl stop nginx停止。
sudo systemctl restart nginx重启。
sudo systemctl status nginx查看状态。
sudo systemctl enable nginx设置开机启动。
因此一定区分：
安装
≠
运行
≠
启动服务27. 安装软件遇到 sudo 是什么
例如：
sudo apt install gitsudo 的意思可以简单理解为：
临时以管理员权限执行后面的命令。
为什么安装经常需要？
因为：
/usr/bin
/etc
/usr/lib这些系统目录普通用户不能随意修改。
因此需要管理员权限。
但是：
pip install ...
npm install ...等命令是否应该加 sudo，要看具体环境。
不要形成：
安装东西一律 sudo
这种习惯。
28. GitHub 软件选择优先级
Ubuntu 上遇到一个普通软件，可以先按照下面顺序考虑：
① Ubuntu 官方 APT 仓库
↓
② 软件官方 APT 仓库
↓
③ 官方 .deb
↓
④ 官方 AppImage / Snap / Flatpak
↓
⑤ 官方预编译 tar.gz
↓
⑥ 源码编译这不是绝对规则，但对日常使用非常实用。
原因是：
越靠前通常越容易安装、升级和卸载。
29. 为什么源码编译一般放到最后
因为源码安装需要你自己负责更多事情：
编译器
依赖库
编译选项
安装路径
升级
卸载例如：
make
sudo make install安装的软件不一定会被：
apt完整管理。
以后可能：
apt 不知道它是谁卸载也没有：
sudo apt remove xxx那么方便。
因此：
如果只是使用软件，通常优先使用成熟的软件包。
如果为了学习源码、定制功能、需要特殊版本，再考虑源码编译。
30. 遇到安装教程以后，应该怎么读
不要上来就复制粘贴。
先判断每一步属于哪一类：
例如：
wget https://xxx.com/app.tar.gz
tar -zxvf app.tar.gz
cd app
cmake -S . -B build
cmake --build build
sudo cmake --install build你应该翻译成：
wget
↓
下载
tar
↓
解压
cd
↓
进入源码目录
cmake -S . -B build
↓
配置项目
cmake --build build
↓
编译
cmake --install build
↓
安装一旦能这么拆：
再长的安装命令也不会觉得神秘。
31. 常见命令功能速查
apt install从 APT 软件源安装软件。
apt update更新软件仓库信息。
apt upgrade升级已安装的软件。
dpkg -i xxx.deb底层方式安装
.deb。
tar -zxvf xxx.tar.gz解压
.tar.gz。
unzip xxx.zip解压
.zip。
wget URL下载文件。
curl URL获取 URL 内容。
chmod +x xxx给文件增加可执行权限。
./xxx执行当前目录下的 xxx。
make按 Makefile 编译。
make install按 Makefile 规则安装。
cmake配置 / 生成项目构建系统。
which xxx查看当前命令实际对应哪个程序。
uname -m查看 CPU 架构。
systemctl status xxx查看系统服务状态。
32. 最终决策树
以后在 GitHub / 官网看到软件，可以直接按照这棵树判断：
我要安装一个软件
│
├─ Ubuntu APT 仓库里有吗？
│
│ ├─ 有
│ │ └─ apt install
│ │
│ └─ 没有
│
├─ 官方提供 Ubuntu / Debian 的 .deb 吗？
│
│ ├─ 有
│ │ ├─ uname -m 看 CPU 架构
│ │ ├─ x86_64 → amd64
│ │ └─ apt install ./xxx.deb
│ │
│ └─ 没有
│
├─ 官方有自己的 APT 仓库吗？
│
│ └─ 按官方说明添加仓库
│ → apt install
│
├─ 有 AppImage / Snap / Flatpak 吗？
│
│ └─ 根据需求选择
│
├─ 有 linux-amd64.tar.gz 吗？
│
│ └─ 看 README：
│ │
│ ├─ 已经编译好的
│ │ └─ 解压 → 运行
│ │
│ └─ 源码
│ └─ 编译
│
└─ 只有 Source Code
│
└─ README
↓
configure / cmake
↓
make
↓
install33. 最后真正需要记住的东西
不要背：
这个软件执行五条命令
那个软件执行八条命令以后只问：
① 我拿到的是什么？是：
.deb？
AppImage？
压缩好的二进制？
源码？
安装脚本？再问：
② 它现在处于哪个阶段？是：
下载？
解压？
配置？
编译？
安装？
启动？最后问：
③ 为什么这一行命令现在要执行？例如：
wget
→ 下载
tar
→ 解压
cmake
→ 准备构建
make
→ 编译
make install
→ 安装
systemctl start
→ 启动服务这样以后哪怕 README 从来没见过：
curl ...
tar ...
cmake ...
ninja ...
install ...也不用害怕。
因为表面命令可能变：
"下载 → 解压 → 构建 → 安装 → 运行"这条主线不会变。
一句话总纲
Linux 安装软件不是背安装命令。
先判断：
"我拿到的到底是什么？"
再判断：
"我现在是在下载、解压、编译，还是安装？"
命令只是这些步骤使用的工具。