ARTICLE DETAIL

建站实战干货

来自一线的建站与推广经验沉淀,每一条都经过真实交付验证。

Ubuntu / Linux 软件安装完整笔记

2026/10/3 6:41:33 拓冰建站 浏览量
Ubuntu / Linux 软件安装完整笔记 核心目标以后遇到 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 最推荐的软件安装方式APTUbuntu 属于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 用户安装本地.debsudo 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.10Source 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前面的步骤是在添加第三方软件仓库。原来的 APTAPT │ └─ 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 又有自己的安装命令除了操作系统的软件管理器还有编程语言自己的包管理器。例如Pythonpip install requestsNode.jsnpm install axiosRustcargo 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 是服务器程序它还可能有启动 停止 重启 开机自启例如使用 systemdsudo 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 安装软件不是背安装命令。 先判断 “我拿到的到底是什么” 再判断 “我现在是在下载、解压、编译还是安装” 命令只是这些步骤使用的工具。