首先说明一个核心结论：Ubuntu 官方并未提供所谓的“软件更新白名单”功能。严格限制“仅允许特定软件包更新”并非 apt 或 apt-get 的原始设计理念。如果强行模拟这一效果，很可能引发依赖关系断裂、系统运行不稳定，甚至导致内核、libc、systemd 等关键组件崩溃。
真正可靠的做法只有两种：冻结无关包，严格控制更新源，或者使用 apt-mark 手动锁定软件包。网络上流传的所谓“白名单脚本”，大多只是通过 grep 和 awk 过滤输出结果，并未真正干预安装行为——本质上只是“虚假的白名单”。
为什么无法直接配置 apt 白名单
apt 本身不提供 allow-only 或 update-whitelist 这类配置项。其设计原则是“信任所有源”，依赖关系解析器（apt-cache、dpkg）会自动拉取所需的所有依赖。即使只执行 sudo apt install nginx，系统也可能一同升级 libpcre3、openssl 等底层库。试图仅放行少数包而阻止其余所有更新，相当于在依赖图上随意剪枝——成功率极低。
实际可行的两种方案
方案一：使用 apt-mark hold 锁定不需要更新的软件包（推荐）
- 这是 Ubuntu 官方支持的方法，本质上是“黑名单思路”：先默认允许全部更新，再将不允许变动的包明确标记出来。
- 执行
sudo apt-mark hold package1 package2后，这些包在apt upgrade时会直接被跳过，连带依赖也不会升级（除非显式指定）。 - 查看当前被锁定的包：
apt-mark showhold - 解除锁定：
sudo apt-mark unhold package1 - 注意：
apt full-upgrade仍有可能绕过 hold（尤其是当某包被标记为“必须升级以满足依赖”时），因此日常建议仅使用apt upgrade。
方案二：限制更新源，配合手动 pinning（适合高级用户）
- 编辑
/etc/apt/sources.list，仅保留信任的仓库（例如只保留archive.ubuntu.com的main和restricted，删除universe、multiverse）。 - 配合
/etc/apt/preferences.d/目录下的 pinning 文件，为特定包设置较高优先级。例如，仅允许从某个源更新nginx：
Package: nginx Pin: release o=Ubuntu,a=focal-security Pin-Priority: 990
- 但 pinning 并不能阻止其他包更新，它仅影响来源选择。它无法实现“只更新 nginx，其余包一概不动”的效果。
- 错误配置
Pin-Priority可能导致整个系统无法升级，调试成本较高。
常见错误操作及其后果
有人尝试使用 apt list --upgradable | grep -E "^(package1|package2)" | cut -d' ' -f1 | xargs sudo apt install 来模拟白名单——这种操作非常危险：
- 忽略依赖：单独通过
apt install安装某个包的特定版本时，会强制拉取当前所需的所有依赖，可能导致降级或与已有组件发生冲突。 - 跳过安全更新：
--upgradable仅显示“可升级”，不区分是否修复了 CVE 漏洞，容易遗漏关键安全补丁。 - 破坏事务原子性：apt 的 upgrade 属于事务操作，拆分为多次 install 容易卡在半路，留下 dpkg 锁或未完成配置。
真正需要“白名单式更新”的场景（例如生产服务器只允许更新监控 agent），建议采用更可控的方案：
- 将目标软件打包成独立 deb，存放在私有仓库中，通过
apt install package=version显式指定版本。 - 或使用
aptitude的交互模式，人工确认每条升级建议。 - 或直接放弃 apt，改用 snap、flatpak、容器（如 Docker 固化版本）。
依赖管理并非开关游戏，强行添加白名单边界，最终最容易崩溃的，往往是你自己维护的那条线。
