跨平台软件包管理实战：Linux与Windows安装卸载全指南

1. 动手之前，先把"软件包"这件事想清楚

1.1 软件包到底是什么

不少人刚接触 Linux 时，第一反应是"安装软件怎么这么麻烦"。在 Windows 上双击 exe 就完事了，到了 Linux 却要敲命令、加源、等下载，看起来绕了一大圈。但你真正折腾过几次之后就会发现，Linux 的软件包管理机制，本质上是在帮你做"依赖管理"和"统一回收"这两件 Windows 默认不擅长的事。

软件包的官方定义是一组文件的集合，通常包含可执行程序、动态库、配置文件、文档和安装脚本。它还有一个最核心的东西：元信息。元信息里记录了版本号、依赖关系、冲突项、安装路径等。Debian 系的 .deb 和 Red Hat 系的 .rpm 都是这种格式。Windows 上的 msi、appx，甚至你双击的那个 setup.exe，本质上也是软件包，只是封装方式不同、管理粒度更粗。

如果你用生活类比来理解：软件包就像超市里已经配好料的食材包，官方源就是你信任的供货商，包管理器是那个帮你检查菜谱（依赖）、把配料分门别类放进柜子（安装）、过期了还能帮忙扔掉（卸载）的家政阿姨。Windows 传统安装工具更像外卖，送到手就能吃，但你几乎不知道里面用了哪些底料，想清理干净更是千难万难。

1.2 两种操作系统在软件管理上的根本差异

Windows 和 Linux 在安装卸载软件这件事上，思路完全不同。Linux 从诞生起就是多用户、多任务系统，软件被拆成一个个小包，共享系统资源，依赖关系靠包管理器统一维护。你安装一个 Python 应用，它会自动帮你把 Python 运行时、相关库一起拉下来，卸载时也能精确移除属于它的文件，前提是你用的是包管理器装的。

Windows 则是从单机桌面系统演化过来的，最初没有统一的应用商店概念。每个软件厂商自己打包，自己决定装到哪个目录，自己依赖哪个版本的运行库。经典的"DLL 地狱"就是这样来的：软件 A 需要 v1 的 dll，软件 B 需要 v2 的 dll，两者不能共存，你装完 B 再打开 A 就直接崩溃。

这也是为什么 Windows 后来推出了 MSI（Windows Installer）、AppX、WinGet 这些标准化方案，本质上是在向 Linux 的包管理哲学靠拢。理解了这一点，你在两个系统之间切换时就不会觉得别扭了，反而能明白：Linux 的"麻烦"换来的是系统整洁和可追溯性，Windows 的"方便"换来的是灵活但其代价是环境混乱。

1.3 会装也要会卸，卸载比安装更见功力

很多人只关注怎么装，忽略了卸载。实际上，卸载做不好，系统的存储占用、注册表残留、启动项垃圾会越积越多。Linux 下你 remove 一个包，如果忘了 autoremove，残留的依赖库会一直躺在系统里。Windows 下你用控制面板卸载程序，很多软件的配置文件、缓存目录、计划任务依然留在原地。

所以这篇内容不只是教你敲几条安装命令，而是把"装"和"卸"当作一个闭环来梳理。你既要知道 apt install 怎么用，也要知道 dpkg -P 的区别；既要会双击 setup.exe，也要会用 winget uninstall 清理残余。下面按系统分别展开。

2. Linux 下的安装与卸载：从 apt 到 dnf

2.1 Debian/Ubuntu 系：apt 与 dpkg 配合使用

Debian 系目前最常用的包管理工具是 apt，它底层调用 dpkg。dpkg 负责处理单个 .deb 包的安装、卸载、查询，但不会自动处理依赖；apt 则是一个更高层的工具，会自动从软件源拉取依赖包、解决版本冲突。

安装软件包的基本命令：

bash复制# 先更新本地包索引，这会从源服务器拉取最新的包列表
sudo apt update

# 安装软件，例如 nginx
sudo apt install nginx

# 安装指定版本
sudo apt install nginx=1.18.0-0ubuntu1.4

这里我要强调一下 apt update 的重要性。新手最容易犯的错误就是直接 apt install，结果提示"无法定位软件包"或者装到一个很旧的版本。因为本地索引文件记录的还是过去某个时刻的包列表，新加入的软件、新版本你根本看不到。我见过不少人在国内镜像源配好之后忘了 update，然后一直装不上想要的软件。正确习惯是：第一次配好源之后立刻 update，之后每次要装新软件前先 update 一次，花不了几秒。

卸载软件包的命令：

bash复制# 只卸载程序，保留配置文件
sudo apt remove nginx

# 完全卸载，连配置文件一起删
sudo apt purge nginx

# 清理不再需要的依赖包
sudo apt autoremove

# 清理下载的安装缓存 (.deb 文件)
sudo apt clean

remove 和 purge 的区别常被忽略。remove 默认不删除 /etc 下的配置文件和 /var/lib 下的数据，你重装回来配置还在。purge 则是彻底清干净。对于生产服务器，我倾向于 purge，尤其是数据库、Web 服务这类带配置的软件，你不 purge，下次装回来可能带着旧配置直接冲突，排查起来非常痛苦。

还需要提一下 dpkg 本身的用法。有时候你在网上下了个 .deb 包，想手动安装：

bash复制# 安装一个 .deb 文件
sudo dpkg -i xxx.deb

# 如果依赖缺失导致报错，用下面命令修复依赖
sudo apt --fix-broken install

# 查看系统里已安装的包
dpkg -l

# 查看某个包是否安装
dpkg -l | grep nginx

dpkg -i 装 .deb 时如果报依赖错误，不要慌，那是正常现象。dpkg 不会自动帮你装依赖，你需要先 apt --fix-broken install 来补救。很多网友在论坛问"dpkg 安装报错怎么办"，其实答案就在这。

2.2 Red Hat 系：yum 与 dnf 的家族延续

CentOS、RHEL、Fedora 以及国内一些服务器系统用的是 rpm 底层，yum 和 dnf 是上层管理器。dnf 是 yum 的下一代，Fedora 和 CentOS 8+ 默认用 dnf，但很多老脚本还在写 yum。好在 dnf 和 yum 的命令风格几乎一致，你记住一套就行。

常用操作：

bash复制# 安装
sudo dnf install nginx

# 卸载
sudo dnf remove nginx

# 清理缓存
sudo dnf clean all

# 查看已安装
sudo dnf list installed

# 查看某个文件属于哪个包
sudo dnf provides /usr/bin/nginx

Red Hat 系有一点和 Debian 系不同，它没有直接从"移除保留配置"和"彻底清除"的简单命令区分。dnf remove 默认会删除配置文件，这和 apt purge 差不多。所以你在 Red Hat 系上不用纠结 remove vs purge，直接用 dnf remove 就行。

如果你拿到一个 .rpm 文件，手动安装命令是：

bash复制sudo rpm -ivh xxx.rpm

# 升级安装
sudo rpm -Uvh xxx.rpm

# 卸载
sudo rpm -e xxx

rpm -e 卸载时如果报依赖被其他包需要，你就得先处理依赖方。这种场景在服务器上不少见，比如你想卸载旧版 OpenSSL，但 yum/dnf 里的某些包还链着它，就不能硬卸。处理思路是先看依赖链条，或者用 --nodeps 强行卸载，但我不建议新手用 --nodeps，除非你非常清楚后果，否则可能把系统搞到连包管理器都跑不了。

2.3 源码编译安装与第三方源

apt、dnf 只能装官方源里有的软件。有些软件官方源没有，或者版本太旧，你就需要走第三方源或者源码编译。

第三方源的典型例子是 Node.js 的 nodesource、Docker 的官方源、nginx 官方源。操作思路都一样：先把源的 GPG 公钥和源列表加进去，然后 update/refresh，再 install。但这种操作有风险，第三方源可能和系统自带包版本产生冲突。我的建议是只在确有必要时添加，添加后注意优先级设置，不要随便 apt upgrade 把系统核心组件升到第三方源的版本。

源码编译是另一条路：

bash复制# 下载源码包
wget https://example.com/xxx.tar.gz
tar -xzf xxx.tar.gz
cd xxx

# 检查环境，生成 Makefile
./configure --prefix=/usr/local/xxx

# 编译并安装
make
sudo make install

源码编译最大的坑是环境依赖。configure 阶段会检查 gcc、make、各种开发库是否齐全，缺一个就报错。装开发库在 Debian 系是 build-essential，Red Hat 系是 "Development Tools" 组：

bash复制# Debian/Ubuntu
sudo apt install build-essential

# Red Hat/CentOS
sudo dnf groupinstall "Development Tools"

源码编译卸载很麻烦，没有统一的卸载命令。如果 Makefile 支持，可以 sudo make uninstall；不支持的话就得手工删文件。这也是为什么我建议普通用户优先用包管理器，源码编译留给真正需要定制参数的高级场景。

2.4 清理残留：卸载不只是 remove 命令

Linux 卸载软件后，系统里通常还会留下一些东西：/etc 下的配置（如果你用了 remove 而不是 purge）、/var/log 下的日志、/var/lib 里的数据、用户目录下的配置文件。

我常用的清理检查方法：

bash复制# 查看自动安装且不再需要的依赖
sudo apt autoremove --dry-run

# 搜索系统里和软件名相关的文件（以 nginx 为例）
sudo find / -name "*nginx*" 2>/dev/null

# 查看 /etc 下残留的配置目录
ls /etc | grep nginx

autoremove 尤其重要。你安装软件时 apt 会拉一大堆依赖，卸载主软件时这些依赖不会自动清除，常年累积可能占据几个 GB 的空间。我见过一台跑了几年的 Ubuntu 服务器，apt autoremove 之后直接释放了 3 个多 GB，而且系统运行更稳定了，因为残留库版本冲突的概率也降低了。

实操建议： 每次卸载完软件，养成依次执行 autoremove 和 clean 的习惯。这两个命令一执行，能让你的系统长期保持清爽。如果你用的是企业生产环境，建议在维护窗口期操作，autoremove 有极小概率误删被其他软件隐式依赖的包，执行前先看 --dry-run 的输出最稳妥。

3. Windows 下的安装与卸载：从双击 exe 到 winget

3.1 传统安装向导流程与陷阱

Windows 用户最熟悉的安装方式就是下载 setup.exe，双击，下一步下一步完成。这个流程本身没什么好讲的，但有几个细节值得注意：

第一个是安装路径。很多软件安装时默认装在 C:\Program Files，如果你是机械硬盘且 C 盘分区不大，装几个大型软件就满了。我个人的习惯是统一软件安装目录，比如 D:\Software，单独给软件分一个盘。这样重装系统、备份恢复时都方便，不会出现"C 盘满了但 D 盘空空如也"的尴尬局面。

第二个是"自定义安装选项"。有些安装包默认勾选了附加组件、快捷方式、开机自启、浏览器插件等。尤其国内下载站来的安装包，经常捆绑一堆东西。我第一次装某压缩软件时没仔细看，结果附带装了一个全家桶浏览器，卸载时还互相纠缠。所以安装时多花 30 秒看一遍勾选项，能省下后面一小时的清理时间。

第三个是安装包来源。这一点怎么强调都不过分：只从软件官网或者 Microsoft Store 下载。 网上各种"高速下载""绿色破解版"站点，很多都改过安装包，轻则捆绑推广软件，重则中木马。这不是危言耸听，我处理过好几台被这类安装包拖垮的机器。

3.2 MSI、EXE 和 AppX：三种常见封装格式

Windows 下的安装包格式五花八门，但最常见的就三种：

MSI：微软原生的安装包格式，基于 Windows Installer 服务。它天然支持静默安装、卸载、修复，企业用组策略分发软件几乎都走 MSI。MSI 的文件会登记在系统"已安装程序"列表里，卸载时也比较干净。

EXE：最常见，但"EXE"其实是笼统的称呼。有的是用 InstallShield、NSIS、Inno Setup 等工具打包的向导式安装程序，本质上包了一个 MSI 或者自定义脚本；有的是绿色软件的自解压包，解压就能运行；还有的是真·可执行程序加一堆资源文件。不同工具打的 EXE，静默安装参数完全不同，这在下文会详细讲。

AppX / MSIX：从 Windows 8 开始出现的新格式，微软想用它在权限隔离、自动更新、干净卸载方面对标 Linux 的包管理。Microsoft Store 里下载的应用基本是这种格式。好处是卸载非常干净，沙箱隔离也好，坏处是系统默认只信任商店签名，想装第三方 AppX 还需要改设置、装证书。

我之前被一个 MSI 安装问题坑过半天：某个软件卸载之后，再重新安装时提示"已有另一版本正在安装"。这是因为 MSI 的事务日志没清理干净，后来我用 Windows Installer CleanUp 工具（或者直接删注册表里的对应条目）才搞定。这类问题在 Windows 上很常见，看到报错不要急着重装系统，先查 Windows 事件日志，再对应处理。

3.3 命令行安装：winget、Chocolatey 和静默参数

如果你日常和 Linux 打交道，肯定会怀念命令行装软件的效率。Windows 现在也有对应的方案，最主流的是 winget（Windows Package Manager）和 Chocolatey。

winget 是微软官方工具，Windows 10 1709 之后的系统可以通过应用商店安装，Windows 11 自带。基本用法：

powershell复制# 搜索软件
winget search nginx

# 查看软件详细信息
winget show nginx

# 安装
winget install nginx

# 卸载
winget uninstall nginx

# 列出已安装软件
winget list

winget 的优势是官方维护、仓库源干净、操作简单。它默认会从官方源下载软件，但注意它安装的可能是软件官方自己的安装包，而不是商店版，所以卸载时记录的是那个软件自己的卸载程序。对于依赖仓库里没有的软件，你还可以用 winget install --manifest 指定本地清单文件。

Chocolatey 是另一个社区驱动的包管理器，需要先装一个引导程序：

powershell复制# 以管理员身份运行 PowerShell
Set-ExecutionPolicy Bypass -Scope Process -Force
[System.Net.ServicePointManager]::SecurityProtocol = [System.Net.ServicePointManager]::SecurityProtocol -bor 3072
iex ((New-Object System.Net.WebClient).DownloadString('https://community.chocolatey.org/install.ps1'))

# 安装软件
choco install nginx

# 卸载
choco uninstall nginx

Chocolatey 的包定义文件是公开的，你可以看它到底执行了什么操作。它比 winget 更"能打"，支持给安装命令传参，适合自动化场景。但代价是你得信任社区维护者的打包质量，所以企业环境里通常还会加一层审核。

如果你不想引入包管理器，只是想在批处理里静默装一个 exe，就需要知道各家安装工具的静默参数：

我试过用 Scoop 来管理开发工具，它和 winget、choco 的思路不同：Scoop 默认装到用户目录，不需要管理员权限，也不污染系统目录。对于开发环境这种频繁切换工具链的场景特别友好，卸载一个软件就是 scoop uninstall 一条命令，干净利落。你可以把 winget 理解为"系统级管家"，Scoop 理解为"用户级工具盒"，两者不冲突，可以并存。

3.4 彻底卸载 Windows 软件的关键点

Windows 卸载软件最大的痛点是残留。控制面板卸载程序之后，你很可能会在以下位置发现遗留文件：

• C:\Program Files\软件名（没删干净的目录）
• C:\ProgramData\软件名
• C:\Users\用户名\AppData\Local 或 Roaming 下的软件目录
• 注册表 HKEY_LOCAL_MACHINE\SOFTWARE 和 HKEY_CURRENT_USER\SOFTWARE 下的键值
• 计划任务、服务、开机启动项

我推荐一条相对彻底的卸载路径：

1. 优先用 winget uninstall 或控制面板正常卸载，不要着急删目录。
2. 卸载后用第三方工具全盘扫描残留。我实测过 Geek Uninstaller，它会在软件卸载后自动检查注册表和文件系统残留，比手动查找省事很多。同类工具还有 Revo Uninstaller，功能更全但偏重。
3. 手动删除前面列出的目录，注意确认里面对应软件，不要误删其他软件的共享文件。
4. 清理注册表。这个要谨慎，修改注册表前最好先导出备份，或者用注册表编辑器里的"查找"功能定位软件关键字，逐项删除。不懂的键值建议直接忽略，不要为了追求"绝对干净"而误删系统关键项。

关于"绿色软件"再补充一句：所谓绿色版就是把软件的所有文件放一个目录，运行前写一次注册表或者免注册。卸载时直接删目录就行，系统里基本不留东西。但它没有自动更新机制，自己拉取的新版本可能覆盖老文件导致脏数据。所以绿色版适合临时工具、便携场景，常用软件还是建议走官方安装。

4. 跨平台常见场景对比：一个软件在两边怎么装

4.1 常见软件包对照表

很多时候我们并不是纠结"怎么装"，而是"同一个软件，在 Linux 和 Windows 上分别应该怎么装"。我整理了一个常用对照表，方便你查漏补缺：

这张表的核心思路是：Linux 先用官方源找，找不到再去第三方源或下载包；Windows 优先用 winget，因为它会自动匹配安装包格式并处理卸载记录。不过 winget 拉取到的某些软件版本可能比官网慢，因为仓库更新有延迟。你是追求稳定还是追求新版本，这是个取舍问题，没有标准答案。

4.2 WSL、国产 Linux 发行版的特别提醒

现在很多人用 WSL（Windows Subsystem for Linux）在 Windows 里跑 Linux 环境。WSL 里装的 Linux 是完全独立的软件包环境，和 Windows 本身的程序没有直接关系。你在 WSL 里 apt install nginx，这个 nginx 只能从 WSL 的 Linux 内核访问，Windows 侧的程序不能直接调用它，除非你配置端口转发或者用 WSL 的 localhost 转发机制。

实战中我遇到过一个典型错误：WSL 提示"适用于 Linux 的 Windows 子系统必须更新到最新版本"，然后让我运行 wsl --update。这个更新操作需要在 PowerShell 或者 CMD 里以管理员权限执行：

powershell复制wsl --update
wsl --shutdown

更新之后重新进入发行版，再执行 sudo apt update 继续安装流程。这类问题不涉及 WSL 本身的软件包安装逻辑，只是 Windows 组件的版本过期。

关于国产 Linux 发行版（比如麒麟、统信 UOS），它们的软件包管理底层仍然是 Debian 系，所以 apt 命令完全适用。但要注意它们的软件源默认指向国内服务器，仓库里的包版本可能比 Ubuntu 官方源旧，而且某些软件只发布了针对特定 CPU 架构的 .deb 包，下载前一定要先确认架构。比如 x86_64 和 ARM64（如飞腾、鲲鹏）的包不能混用，硬装会直接报错，错误信息类似"软件包架构不匹配"。

4.3 同一场景下的安装思路：从需求反推命令

我发现很多初学者最大的障碍不在命令本身，而在于"不知道该用包管理器还是源码编译"。这里给一个我长期使用的决策流程：

第一步，看官方文档。现代主流软件都会在官网写清楚支持的安装方式，比如 Nginx 官网给了各发行版的源配置方法。跟着官方走永远是风险最低的。

第二步，官方没有或者嫌麻烦，就用系统源。apt install 或 dnf install 一条命令解决，依赖自动处理，卸载也干净。

第三步，系统源版本太旧，才考虑第三方源或手动下载安装包。

第四步，真的需要定制编译参数（比如想给 Nginx 增加特定模块），才走源码编译。

这个流程适用 Linux 和 Windows。Windows 侧的顺序是：商店版优先，然后 winget，然后再去官网下安装包，最后才是绿色版工具。按照这个思路，你不用背命令也能选对方案。

5. 常见报错与排查技巧实录

5.1 Linux 侧高频报错和处理

"无法定位软件包"：最常见原因是没执行 apt update，或者软件源列表里没有对应的源。处理方法是先 sudo apt update，再重试；如果还不行，检查 /etc/apt/sources.list 或 /etc/apt/sources.list.d/ 下的源配置，确认源地址是否可访问、是否匹配当前系统版本（比如 Ubuntu 22.04 用了 20.04 的源就会出现各种诡异问题）。

"下列软件包有未满足的依赖关系"：这是 apt 最常见的报错之一。典型处理套路：

bash复制# 尝试修复依赖关系
sudo apt --fix-broken install

# 如果提示某个包被 hold 住了
sudo apt-mark unhold 包名

# 检查是否有多个源的包版本冲突
apt-cache policy 包名

从 Kali 这类滚动发行版装软件时，我还遇到过"apt-get 无法定位软件包"的情况。这时要看源配置里是否启用了对应的仓库组件。Kali 常用 /etc/apt/sources.list 加 deb 行，但某些工具在 Kali 里被单独分到了 kali-tools 仓库，不加源永远找不到。

"E: Could not get lock /var/lib/dpkg/lock"：这个报错是另一个包管理进程还在运行，或者上次意外中断导致锁没释放。排查步骤：

bash复制# 找出占用锁的进程
ps aux | grep apt

# 如果进程确实存在，等它结束；如果不存在，删除锁文件
sudo rm /var/lib/dpkg/lock
sudo rm /var/lib/apt/lists/lock

我强烈不建议在不确定的情况下直接删锁文件。我曾经在系统刚开机时直接删锁，结果 apt 卡在"正在读取数据库"状态，最后只能靠 dpkg --configure -a 修复。正确姿势是先 ps 确认没有 apt 相关的存活进程，再考虑删锁。

"BADSIG"或者公钥错误：一般发生在添加第三方源之后。处理思路是重新拉取公钥：

bash复制sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 错误里的KEY_ID

不过 apt-key 已经过时了，新版系统更推荐用 /etc/apt/trusted.gpg.d/ 目录来管理公钥。如果你看到 apt-key 相关警告，先确认系统是否还有旧配置残留，再决定要不要迁移。

5.2 Windows 侧高频报错和处理

"此应用无法在你的电脑上运行"：这类报错原因很多，可能是架构不匹配（32 位系统装 64 位软件），可能是安装包本身损坏，也可能是系统版本过旧。先查系统类型：设置 -> 系统 -> 系统信息，确认系统架构；再确认软件支持的最低系统版本。比如你看到"指定的可执行文件不是此操作系统平台的有效应用程序"这类提示，几乎可以确定是架构不匹配，直接去官网下对应架构的安装包就行。

"卸载安装程序在安装此软件包时遇到了错误，错误码是 2"：这个错误信息在 Windows 安装 MSI 时经常出现，英文原文大概是"Error 2"。第一个排查方向是查看 Windows 事件日志，应用程序日志里会有详细的 MSI 事务记录。常见原因包括：安装目录权限不够、杀毒软件拦截、已经存在残留版本。解决方案通常是把杀毒软件临时关闭，以管理员身份运行命令：

powershell复制msiexec /uninstall 产品代码 /quiet
msiexec /i 安装包.msi /log install.log

日志文件 install.log 会记录失败的具体阶段，比猜原因高效得多。

"软件包似乎无效"：这个提示常见于下载的安装包不完整，或者文件被篡改。你可以先对比官网给出的 SHA256 哈希值：

powershell复制Get-FileHash 文件名 -Algorithm SHA256

如果哈希对不上，重新下载即可。我下载大文件时经常遇到网络波动导致文件损坏的情况，尤其是超过 1GB 的安装包，所以现在养成了下载完必校验哈希的习惯，这能避免大量莫名其妙的中途报错。

"程序不能运行，因为缺少 xxx.dll"：缺少运行库是最常见的 Windows 软件问题。很多桌面软件依赖 Visual C++ 运行库或 .NET Framework，装完软件本体没装依赖运行库就会报这个错。解决办法是去微软官网安装"Visual C++ Redistributable"，这个包是统一的，装上之后大部分"缺 dll"问题就解决了。

5.3 运维脚本化：批量安装卸载的实战模板

如果你需要在一批 Windows 机器上批量操作，winget 可以这么用：

powershell复制# 批量安装常用软件
$apps = @(
    "Git.Git",
    "Python.Python.3.12",
    "Microsoft.VisualStudioCode",
    "7zip.7zip"
)
foreach ($app in $apps) {
    winget install --id $app --accept-source-agreements --accept-package-agreements --silent
}

Linux 侧批量安装一个思路：

bash复制# 从文件读取包名列表逐行安装
while read pkg; do sudo apt install -y "$pkg"; done < packages.txt

脚本化的价值在于可复现。配合配置文件管理，你可以在 10 分钟内把一台全新的裸机配置成开发环境，而且下次换电脑、重装系统时完全不用回忆当时装了什么。这一步正是软件包管理从"会敲命令"到"懂运维"的分水岭。

6. 一些值得升级的习惯和后续方向

经过前面这些实操，你应该能感受到：软件包管理表面上是命令记忆问题，实际上是系统管理哲学问题。Linux 的包管理更严格但更透明，Windows 正在逐步补齐标准化短板，两边都在互相借鉴。

我在实际使用中有一个体会：不管哪个系统，都要把"来源可控"放在第一位。 我都见过太多用户因为图方便下载了来路不明的安装包，把系统搞得乌烟瘴气。官方源、官方商店、知名维护者的仓库，这三个来源就够了，没必要走野路子。

最后分享一个我自己的固定动作：每台电脑初次配置时，我会把 Linux 和 Windows 两边的包管理器初始化好，并把常用软件清单写成一个可执行脚本保存到云盘。重装系统后，先在 Windows 上跑一遍 winget 安装清单，再在 WSL 或 Linux 上跑一遍 apt/dnf 安装清单，半天之内就能回到工作状态。这个过程本身也是一种乐趣，看着一排排软件名快速装好，跟流水线作业一样顺畅。希望你也能根据自己的实际场景，沉淀出属于自己的一套安装卸载手册。