Ubuntu / Linux 软件安装完整笔记

核心目标：以后遇到 GitHub、官网、README 里的各种安装命令，不再死记硬背，而是能判断：

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 redis

4. 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.deb

7.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 update

APT 不仅会查询 Ubuntu：

还会查询：

这个软件自己的官方仓库

然后可以：

sudo apt install xxx

以后：

sudo apt upgrade

也能统一更新它。

所以很多“安装前几十行命令”的本质其实是：

加仓库
↓
验证仓库
↓
更新仓库信息
↓
apt install

13. 软件仓库中的 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 requests

Node.js：

npm install axios

Rust：

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 生态
└─ cargo

17. 为什么 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_64

GitHub 提供：

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.sh

Shell 才允许把它当程序执行。

同理：

chmod +x xxx.AppImage

也是：

允许执行这个 AppImage 文件。

注意：

chmod +x 不是安装。

它只是改变文件权限。

20. ./xxx 为什么前面有 ./

假设当前目录有：

hello

运行：

hello

Shell 通常不会默认在当前目录寻找。

它只会去：

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:…

输入：

git

Shell 会依次去：

/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

都可以直接：

git

22. 如何查看一个命令到底在哪里

非常实用。

例如：

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 git

sudo 的意思可以简单理解为：

临时以管理员权限执行后面的命令。

为什么安装经常需要？

因为：

/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
↓
install

33. 最后真正需要记住的东西

不要背：

这个软件执行五条命令
那个软件执行八条命令

以后只问：

① 我拿到的是什么？

是：

.deb？
AppImage？
压缩好的二进制？
源码？
安装脚本？

再问：

② 它现在处于哪个阶段？

是：

下载？
解压？
配置？
编译？
安装？
启动？

最后问：

③ 为什么这一行命令现在要执行？

例如：

wget
→ 下载

tar
→ 解压

cmake
→ 准备构建

make
→ 编译

make install
→ 安装

systemctl start
→ 启动服务

这样以后哪怕 README 从来没见过：

curl …
tar …
cmake …
ninja …
install …

也不用害怕。

因为表面命令可能变：

“下载 → 解压 → 构建 → 安装 → 运行”这条主线不会变。

一句话总纲

Linux 安装软件不是背安装命令。

先判断：
“我拿到的到底是什么？”

再判断：
“我现在是在下载、解压、编译，还是安装？”

命令只是这些步骤使用的工具。