1. 项目概述：搞懂 apt-get install 的默认安装路径，不是查文档，是看系统怎么“落子”
你执行sudo apt-get install openssh-server，敲完回车，服务就跑起来了；你又试了sudo apt-get install fcitx fcitx-googlepinyin，中文输入法也立刻可用。但有没有一瞬间想过：这些二进制文件、配置目录、数据模板，到底被塞到硬盘哪个角落去了？不是/usr/local/bin，也不是/opt，更不是你家目录下某个隐藏文件夹——它们有自己的一套“户籍管理制度”，这套制度叫Filesystem Hierarchy Standard（FHS），而apt-get就是严格按这个标准“派发户口本”的办事员。
很多人卡在第一步：想改配置却找不到sshd_config在哪，想查日志却不知道journalctl背后调用的是哪个路径下的 socket，想卸载干净却漏掉/etc/default/下的启动参数文件。这不是操作不熟，是根本没建立对 Debian/Ubuntu 系统软件布局的底层认知。apt-get install从不“随意扔东西”，它背后是dpkg这个包管理器在驱动，而dpkg的每一份安装记录，都精确到字节级地写在/var/lib/dpkg/info/下的.list文件里。你用dpkg -L openssh-server查到的，不是猜测，是安装时当场写死的清单；你看到/usr/bin/sshd和/etc/ssh/sshd_config并列出现，不是巧合，是 FHS 规定“可执行程序归/usr/bin，主机专属配置归/etc”的刚性分工。
这个问题的实操价值远超“查路径”本身。当你遇到waiting for cache lock: could not get lock /var/lib/dpkg/lock-frontend这类报错，本质是另一个进程正在往/var/lib/dpkg/目录写状态；当你调试fcitx输入法失效，第一反应不该是重装，而是ls -l /usr/lib/fcitx/看插件是否真被解压到位；甚至sudo apt-get install nvidia-driver-535后显卡没生效，检查/lib/modules/$(uname -r)/kernel/drivers/video/下有没有nvidia.ko，比反复重启更直接。所以这不只是一个路径查询问题，它是理解整个 Debian 系统软件生命周期的入口——安装、运行、配置、升级、卸载，所有环节都锚定在这些默认位置上。无论你是刚接触 Ubuntu 的新手，还是天天和 ROS Noetic、CUDA 驱动打交道的嵌入式开发者，只要用apt，你就绕不开这套路径逻辑。
2. 核心设计逻辑：为什么是这些路径？FHS 不是约定，是强制契约
2.1 FHS 是什么？它不是建议，是 Debian 生态的宪法
Filesystem Hierarchy Standard（FHS）不是某家公司写的白皮书，而是 Linux 基金会联合各大发行版（Debian、Red Hat、SUSE）共同签署的“基础设施宪章”。它的核心目标只有一个：让任何符合 FHS 的软件包，在任意符合 FHS 的系统上，都能以完全一致的方式被定位、加载和管理。这意味着openssh-server包在 Ubuntu 20.04、Debian 12、甚至 Raspbian 上，其二进制文件必然在/usr/bin/sshd，配置模板必然在/usr/share/doc/openssh-server/examples/sshd_config，而运行时配置必然在/etc/ssh/sshd_config。这种一致性，是apt能实现跨版本平滑升级、dpkg能精准追踪文件归属、apt autoremove能安全清理依赖的根本前提。
FHS 把整个文件系统划分为若干“功能区”，每个区域有明确的语义和权限模型：
/bin和/sbin：存放系统启动和紧急修复必需的命令（如ls,mount,ifconfig），普通用户可执行，root 可写；/usr：用户空间程序的主仓库，其中/usr/bin存放绝大多数用户命令（apt-get,python3,gcc），/usr/lib存放共享库和插件，/usr/share存放架构无关的只读数据（文档、图标、字体）；/etc：主机专属配置的唯一法定地址，所有服务的配置文件（/etc/ssh/,/etc/fcitx/,/etc/apt/sources.list）必须在此，且该目录下内容绝不允许被软件包覆盖，apt安装时若发现同名文件已存在，会提示“conflicting files”并暂停；/var：可变数据的动态存储池，/var/log存日志，/var/lib存运行时状态（dpkg数据库就在/var/lib/dpkg），/var/cache存下载缓存（apt的.deb包就躺在/var/cache/apt/archives/）；/home：用户主目录，与apt安装行为无关，但apt安装的 GUI 程序（如fcitx）会在~/.config/下生成用户级配置，这是 FHS 允许的例外。
提示：FHS 对
/usr和/var的划分有深刻工程考量。/usr设计为只读挂载（很多嵌入式系统确实这么做），确保系统核心程序不被意外修改；而/var必须可写，因为日志滚动、数据库增长、dpkg 状态更新都发生在这里。当你看到could not get lock /var/lib/dpkg/lock-frontend报错，本质就是另一个apt进程正在/var/lib/dpkg/目录下做原子写操作，系统用文件锁强制串行化，避免数据库损坏。
2.2 dpkg 是如何执行 FHS 的？安装过程的四步拆解
apt-get install是前端工具，真正干活的是dpkg。理解dpkg的工作流，才能明白路径为何如此固化。以sudo apt-get install openssh-server为例，完整流程如下：
第一步：解析控制文件（control file）apt从远程仓库下载openssh-server_1%3a9.2p1-2ubuntu0.4_amd64.deb包后，dpkg首先解压其DEBIAN/control文件。这里定义了包名、版本、依赖、维护者，最关键的是Installed-Size: 1234字段——它告诉dpkg这个包解压后会占用多少磁盘空间，dpkg会据此检查/分区剩余空间是否足够。
第二步：校验并解压文件（unpack）dpkg检查包签名（如果启用 APT trust），然后将.deb内部的data.tar.xz解压到内存中的临时树。此时所有文件路径都是“虚拟路径”，比如./usr/bin/sshd、./etc/ssh/sshd_config。dpkg不会直接写入磁盘，而是先构建一个完整的文件映射关系。
第三步：执行预安装脚本（preinst）
在真实写入前，dpkg运行包内DEBIAN/preinst脚本。对于openssh-server，这个脚本会检查系统是否已有sshd进程在运行，如果有，它会先systemctl stop ssh，避免新旧配置冲突。注意：preinst脚本没有权限修改/etc/ssh/sshd_config，它只能停止服务或创建必要目录（如/run/sshd），因为 FHS 规定配置文件的修改权属于管理员，而非包安装程序。
第四步：原子化写入与注册（configure）dpkg将内存中构建的文件树，按 FHS 规则逐字节写入对应路径：./usr/bin/sshd→/usr/bin/sshd，./etc/ssh/sshd_config→/etc/ssh/sshd_config（若该文件不存在）或/etc/ssh/sshd_config.dpkg-new（若已存在）。写入完成后，dpkg将所有文件路径、校验和、包元数据写入/var/lib/dpkg/info/openssh-server.list和/var/lib/dpkg/status。最后运行DEBIAN/postinst脚本（启动sshd服务、生成 host key），整个安装才宣告完成。
注意：
dpkg的原子性体现在/var/lib/dpkg/目录操作。它先写status文件的临时副本status.tmp，写完再mv status.tmp status，利用 Linux 文件系统mv的原子性保证状态库不损坏。这也是为什么killall apt可能导致dpkg数据库半途而废，必须用sudo dpkg --configure -a修复。
2.3 为什么不能自定义安装路径？硬编码 vs 可配置的边界
有人会问：“能不能让apt-get install把东西装到/opt/myapp/？”答案是技术上可行，但生态上自杀。原因有三：
其一，路径硬编码在二进制中。/usr/bin/sshd这个可执行文件，在编译时就通过-rpath参数写死了它要加载的共享库路径（如/usr/lib/x86_64-linux-gnu/libcrypto.so.1.1）。如果你强行把sshd复制到/opt/，它启动时会因找不到libcrypto而报error while loading shared libraries。dpkg不是解压工具，它是“系统集成器”，必须确保所有路径在安装时刻就正确无误。
其二，服务管理器依赖固定路径。systemd的 unit 文件（如/lib/systemd/system/ssh.service）明确写了ExecStart=/usr/bin/sshd -D。如果sshd不在/usr/bin/，systemctl start ssh会直接失败。同样，fcitx的 dbus service 文件/usr/share/dbus-1/services/org.fcitx.Fcitx.service中Exec=行指向/usr/bin/fcitx，路径错则服务不可用。
其三，依赖解析器（APT resolver）只认标准路径。当apt计算openssh-server依赖libssl1.1时，它查的是libssl1.1包的Provides:字段和Depends:字段，这些字段关联的是/usr/lib/x86_64-linux-gnu/libssl.so.1.1这个路径。如果你手动把libssl装到/opt/，apt完全感知不到，它仍会尝试安装官方libssl1.1包，导致双份库共存，引发 ABI 冲突。
实操心得：我曾为调试 ROS Noetic 的
roscore启动慢问题，试图把roslaunch脚本软链接到/opt/ros/noetic/bin/。结果rosdep install因找不到/usr/lib/ros/下的依赖描述文件而失败。最终解决方案是：接受 FHS，用rosdep的--reinstall选项强制刷新依赖，而不是对抗路径规范。记住：在 Debian 生态里，“适配路径”比“修改路径”成本低三个数量级。
3. 默认安装位置全景图：从根目录到具体文件，一张表看清所有关键路径
3.1 主干路径总览：按 FHS 分区归类的核心目录
| FHS 分区 | 典型路径 | 存放内容 | 是否可写 | 关键命令示例 | 实际案例 |
|---|---|---|---|---|---|
| /bin & /sbin | /bin/bash,/sbin/ifconfig | 系统基础命令（shell、网络、磁盘工具） | root only | ls -l /bin/ls | apt-get install本身不在/bin，但其依赖的wget、gpgv在/usr/bin/ |
| /usr/bin & /usr/sbin | /usr/bin/apt-get,/usr/sbin/sshd | 用户级应用程序主程序 | root only | which apt-get→/usr/bin/apt-get | openssh-server的sshd在/usr/sbin/sshd（因属系统服务） |
| /usr/lib & /usr/libexec | /usr/lib/x86_64-linux-gnu/libssl.so.1.1,/usr/lib/openssh/sftp-server | 共享库、服务辅助程序、插件 | root only | ldd /usr/sbin/sshd | grep libssl | fcitx-googlepinyin的输入法引擎在/usr/lib/fcitx/ |
| /usr/share | /usr/share/doc/openssh-server/,/usr/share/icons/hicolor/ | 文档、图标、字体、本地化数据 | root only | ls /usr/share/doc/openssh-server/ | nvidia-driver-535的 Xorg 模块在/usr/share/X11/xorg.conf.d/ |
| /etc | /etc/ssh/sshd_config,/etc/apt/sources.list | 主机专属配置文件 | root only | sudo nano /etc/ssh/sshd_config | fcitx的全局配置在/etc/fcitx/，用户配置在~/.config/fcitx/ |
| /var/lib | /var/lib/dpkg/,/var/lib/apt/lists/ | 包管理数据库、APT 缓存索引 | root only | ls /var/lib/dpkg/info/\*.list | dpkg -L openssh-server读取的就是/var/lib/dpkg/info/openssh-server.list |
| /var/cache | /var/cache/apt/archives/ | 下载的.deb包缓存 | root only | ls /var/cache/apt/archives/\*.deb | apt-get clean清空此目录，释放磁盘空间 |
| /var/log | /var/log/apt/history.log,/var/log/syslog | 安装历史、系统日志 | root only | tail -n 10 /var/log/apt/history.log | apt-get install的每一条命令都会记入此文件 |
这张表不是静态快照，而是动态契约。当你执行sudo apt-get install openssh-server，dpkg会严格按照此表规则，将包内文件分发到对应位置。例如，openssh-server包的DEBIAN/control文件中，Section: net字段决定了它被归类到网络服务，因此其守护进程sshd被放入/usr/sbin/（而非/usr/bin/），因为它需要 root 权限且不供普通用户直接调用。
3.2 深度解析：dpkg -L命令背后的真相与使用陷阱
dpkg -L <package-name>是查询包文件路径的黄金命令，但它常被误用。我们以dpkg -L openssh-server输出的前 10 行为例：
/. /etc /etc/init.d /etc/init.d/ssh /etc/default /etc/default/ssh /etc/ssh /etc/ssh/moduli /etc/ssh/sshd_config /etc/ssh/sshd_config.d表面看是目录列表，实则揭示了dpkg的文件注册哲学：
.行代表包的根目录：即该包所有文件的“虚拟根”，dpkg将其映射到真实文件系统的/。/etc行是目录声明：dpkg记录此包“拥有”/etc目录，但/etc本身由base-files包提供，openssh-server只负责在其下创建子目录。/etc/ssh/sshd_config是文件实体：这是真正被安装的配置文件，dpkg会校验其 MD5 值并写入数据库。
常见陷阱：
dpkg -L只显示当前已安装的文件，不显示postinst脚本生成的文件（如ssh的 host key/etc/ssh/ssh_host_rsa_key）。这些文件由脚本在安装后动态创建，dpkg不追踪它们。因此，dpkg -L openssh-server不会列出ssh_host_*_key，但ls /etc/ssh/能看到。这是设计使然：dpkg只管理“包交付物”，不管理“运行时产物”。
另一个陷阱是dpkg -L对符号链接的处理。执行dpkg -L coreutils会看到/bin/ls -> /usr/bin/ls，但dpkg实际注册的是/usr/bin/ls这个真实文件，/bin/ls只是一个指向它的链接。这意味着apt remove coreutils会删除/usr/bin/ls，而/bin/ls链接会变成“悬空链接”，ls命令失效。这就是为什么coreutils包的postinst脚本会重建/bin/下的链接——dpkg管理文件，postinst管理链接拓扑。
3.3 特殊场景路径解析：GUI 应用、驱动、开发库的差异化落地
不同类型的软件包，其文件分布遵循 FHS 细则，但有领域特异性：
GUI 应用（如fcitx-googlepinyin）
- 可执行文件：
/usr/bin/fcitx（主程序）、/usr/bin/fcitx-configtool（配置工具） - 输入法引擎：
/usr/lib/fcitx/（C++ 插件）、/usr/lib/fcitx-pinyin/（拼音模块） - 配置模板：
/usr/share/fcitx/pinyin/（词库、音码表） - D-Bus 服务：
/usr/share/dbus-1/services/org.fcitx.Fcitx.service（声明服务接口） - 图标资源：
/usr/share/icons/hicolor/（按尺寸分层存放）
注意：
fcitx-googlepinyin的googlepinyin.so引擎文件在/usr/lib/fcitx/，但fcitx主程序通过dlopen()动态加载它，路径在代码中硬编码为LIBDIR "/fcitx/"，而LIBDIR在编译时被设为/usr/lib。这就是为什么你不能简单mv /usr/lib/fcitx/ /opt/fcitx/——fcitx启动时会去/usr/lib/fcitx/找引擎，找不到就报Failed to load module googlepinyin。
NVIDIA 驱动（nvidia-driver-535）
- 内核模块：
/lib/modules/$(uname -r)/kernel/drivers/video/nvidia/（.ko文件） - Xorg 模块：
/usr/lib/xorg/modules/drivers/nvidia_drv.so（X server 驱动） - GL 库：
/usr/lib/x86_64-linux-gnu/libGL.so.1（OpenGL 接口） - 配置工具：
/usr/bin/nvidia-settings（GUI 设置面板） - 配置文件：
/etc/X11/xorg.conf.d/10-nvidia.conf（Xorg 加载配置）
关键点：驱动包故意不覆盖
/usr/lib/x86_64-linux-gnu/libGL.so.1，而是通过alternatives系统管理多个 OpenGL 实现（mesavsnvidia）。update-alternatives --config gl_conf切换时，实际修改的是/usr/lib/x86_64-linux-gnu/libGL.so.1的符号链接目标。这是 Debian 处理多实现冲突的标准方案。
开发库（libssl-dev）
- 头文件：
/usr/include/openssl/（#include <openssl/ssl.h>的搜索路径） - 静态库：
/usr/lib/x86_64-linux-gnu/libssl.a（gcc -lssl链接时使用） - 共享库：
/usr/lib/x86_64-linux-gnu/libssl.so（运行时加载） - pkg-config 文件：
/usr/lib/x86_64-linux-gnu/pkgconfig/libssl.pc（pkg-config --cflags openssl的依据）
为什么头文件在
/usr/include/而非/usr/local/include/？因为apt安装的库是“系统级依赖”，/usr/local/是make install的领地。混用会导致gcc找到错误的头文件版本，编译出 ABI 不兼容的二进制。
4. 实操指南：五种场景下的路径定位与问题排查
4.1 场景一：快速定位任意已安装包的全部文件（dpkg -L+grep组合技）
当你不确定openssh-server的配置文件在哪，最高效的方法不是 Google，而是直接问系统：
# 列出 openssh-server 包的所有文件，并过滤出 .conf 结尾的配置文件 dpkg -L openssh-server | grep '\.conf$' # 输出：/etc/ssh/sshd_config # 查找所有包含 'pinyin' 的路径（用于 fcitx-googlepinyin） dpkg -L fcitx-googlepinyin | grep pinyin # 输出：/usr/lib/fcitx/googlepinyin.so /usr/share/fcitx/pinyin/ # 定位 nvidia 驱动的内核模块（需先确认包名） dpkg -l | grep nvidia-driver | awk '{print $2}' | head -n1 # 假设输出 nvidia-driver-535，则： dpkg -L nvidia-driver-535 | grep '\.ko$' # 输出：/lib/modules/5.15.0-101-generic/kernel/drivers/video/nvidia/nvidia.ko实操心得：
dpkg -L输出是按字母序排列的，grep能快速聚焦。但要注意，dpkg -L只对已安装包有效。如果dpkg -l | grep openssh显示rc（remove config）状态，说明包已被卸载但配置保留，此时dpkg -L openssh-server会报错package is not installed。这时要用apt list --installed | grep openssh确认状态。
4.2 场景二：解决waiting for cache lock错误——直击/var/lib/dpkg/锁机制
这个错误几乎每个 Ubuntu 用户都见过，但多数人只是sudo killall apt了事，这可能导致dpkg数据库损坏。正确做法是理解锁的本质：
# 查看哪个进程持有锁 sudo lsof /var/lib/dpkg/lock-frontend # 输出类似：COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME # apt 12345 root 3uW REG 0,123 0 123456 /var/lib/dpkg/lock-frontend # 如果是 apt 进程卡住，安全终止它 sudo kill -TERM 12345 # 如果没有进程持有锁，但文件存在，手动清除（谨慎！） sudo rm /var/lib/dpkg/lock-frontend sudo rm /var/lib/dpkg/lock # 修复可能损坏的 dpkg 状态 sudo dpkg --configure -a # 重新更新包索引 sudo apt update关键原理：
/var/lib/dpkg/lock-frontend是apt进程间通信的互斥锁，/var/lib/dpkg/lock是dpkg自身的锁。apt在执行update、install、upgrade时，会先获取lock-frontend，再调用dpkg获取lock。killall apt只杀前端，dpkg进程可能还在写数据库，直接删锁文件风险极高。dpkg --configure -a会扫描/var/lib/dpkg/status中标记为half-installed的包，并重新运行其postinst脚本，这是官方推荐的修复方式。
4.3 场景三：验证安装完整性——用md5sum校验关键文件
dpkg数据库记录了每个文件的 MD5 值，可用于验证文件是否被意外修改：
# 获取 openssh-server 包中 /etc/ssh/sshd_config 的预期 MD5 grep '/etc/ssh/sshd_config' /var/lib/dpkg/info/openssh-server.md5sums # 输出：a1b2c3d4e5f678901234567890123456 /etc/ssh/sshd_config # 计算当前文件的实际 MD5 md5sum /etc/ssh/sshd_config # 输出：a1b2c3d4e5f678901234567890123456 /etc/ssh/sshd_config （匹配则正常） # 如果不匹配，说明配置被手动编辑过，dpkg 会标记为 'conffile' 并在升级时提示 # 此时 dpkg 会保留你的修改，同时把新版本配置保存为 /etc/ssh/sshd_config.dpkg-dist注意：
/var/lib/dpkg/info/<package>.md5sums文件只在包安装时生成，且仅包含data.tar.xz中的文件。postinst脚本生成的文件（如 SSH host key）不在其中，因此md5sum校验对它们无效。这是dpkg的设计取舍：只保证“交付物”完整，不保证“运行时产物”一致。
4.4 场景四：安全卸载与彻底清理——apt purge与手动清理的边界
apt remove只删二进制，apt purge才清配置。但有些残留需手动处理：
# 彻底卸载 openssh-server 及其配置 sudo apt purge openssh-server # 检查 /etc/ssh/ 是否还有残留（purge 应该已清空，但有时失败） ls -la /etc/ssh/ # 如果看到 ssh_host_*_key，说明 purge 未完成，手动删除 sudo rm -f /etc/ssh/ssh_host_* # 清理 /var/log/ 下的 SSH 日志（apt 不管日志） sudo rm -f /var/log/auth.log* # 清理 systemd 服务状态（如果服务单元文件被修改过） sudo systemctl reset-failed ssh sudo systemctl daemon-reload实操心得：
apt purge的安全性在于它调用dpkg --purge，后者会运行包的prerm和postrm脚本。openssh-server.postrm会rm -rf /etc/ssh/，但如果/etc/ssh/下有你创建的自定义文件（如my-custom.conf），postrm不会删它，因为dpkg只管理自己安装的文件。因此，purge后手动ls /etc/ssh/确认是必要步骤。我曾因漏删/etc/ssh/sshd_config.d/99-custom.conf，导致重装openssh-server后配置冲突，花了半小时排查。
4.5 场景五：调试fcitx输入法失效——路径链路全检查
fcitx失效常因路径环节断裂。按顺序检查：
# 1. 确认包已安装 dpkg -l | grep fcitx # 2. 检查主程序是否存在且可执行 ls -l /usr/bin/fcitx # 应输出：-rwxr-xr-x 1 root root ... /usr/bin/fcitx # 3. 检查输入法引擎是否在正确路径 ls -l /usr/lib/fcitx/googlepinyin.so # 如果不存在，可能是 fcitx-googlepinyin 包未装，或架构不匹配（amd64 vs arm64） # 4. 检查 D-Bus 服务文件是否注册 ls -l /usr/share/dbus-1/services/org.fcitx.Fcitx.service # 内容应包含 Exec=/usr/bin/fcitx # 5. 检查环境变量（fcitx 启动依赖） echo $GTK_IM_MODULE $QT_IM_MODULE $XMODIFIERS # 应输出：fcitx fcitx @im=fcitx # 6. 手动启动并查看错误 fcitx -d # -d 参数后台启动并输出日志到终端 # 如果报 "Failed to load module googlepinyin"，说明 /usr/lib/fcitx/ 下无 .so 文件关键细节：
fcitx的模块加载路径在源码中定义为FCITX_MODULES_DIR，编译时设为/usr/lib/fcitx/。但fcitx运行时会读取~/.config/fcitx/config中的ModuleDir项，如果该配置被手动修改为/opt/fcitx/modules/，而该目录不存在，就会静默失败。因此，cat ~/.config/fcitx/config | grep ModuleDir是调试必查项。
5. 常见问题速查与独家避坑指南
5.1 问题速查表：高频报错与根因定位
| 报错信息 | 根本原因 | 定位命令 | 解决方案 |
|---|---|---|---|
E: Could not get lock /var/lib/dpkg/lock-frontend | 其他 apt 进程正在运行或异常终止 | sudo lsof /var/lib/dpkg/lock-frontend | sudo kill -TERM <PID>或sudo dpkg --configure -a |
dpkg: error processing package xxx (--configure) | 包的postinst脚本执行失败（如权限不足、依赖缺失） | sudo tail -n 20 /var/log/apt/term.log | sudo apt install -f修复依赖，或sudo dpkg --configure <package>重试 |
command not found: fcitx | /usr/bin/fcitx不存在或 PATH 未包含/usr/bin | ls /usr/bin/fcitx; echo $PATH | sudo apt install fcitx，或export PATH="/usr/bin:$PATH" |
Failed to load module googlepinyin | /usr/lib/fcitx/googlepinyin.so缺失或权限错误 | ls -l /usr/lib/fcitx/googlepinyin.so | sudo apt install fcitx-googlepinyin，或sudo chmod 755 /usr/lib/fcitx/*.so |
No protocol specified(GUI 程序无法启动) | X11 socket 权限问题，非 apt 路径问题 | ls -l /tmp/.X11-unix/ | xhost +local:临时授权，或检查~/.profile中export DISPLAY是否正确 |
5.2 独家避坑技巧：十年踩坑总结的三条铁律
铁律一：永远不要手动rm -rf /var/lib/dpkg/
这是最致命的操作。/var/lib/dpkg/是dpkg的大脑，包含status（包状态）、info/（文件清单）、available（可用包列表）。删了它，apt就变成无头苍蝇，连apt list --installed都会报错。我曾因误操作删了info/，结果dpkg -L全部失效，最终靠apt install --reinstall $(dpkg -l \| awk '{print $2}' \| tr '\n' ' ')强制重装所有包才恢复。正确做法是：sudo mv /var/lib/dpkg /var/lib/dpkg.bak备份，再操作。
铁律二：/etc/下的文件修改后，务必用sudo apt-mark hold <package>锁定
当你编辑/etc/ssh/sshd_config后，下次apt upgrade openssh-server会检测到文件变更，并提示：
Configuration file '/etc/ssh/sshd_config' ==> Modified (by you or by a script) since installation. ==> Package distributor has shipped an updated version. What would you like to do about it ? Your options are: Y or I : install the package maintainer's version N or O : keep your currently-installed version D : show the differences between the versions Z : start a shell to examine the situation选N保留你的配置，但下次升级仍会提示。用sudo apt-mark hold openssh-server可永久阻止该包升级，避免配置被覆盖。解除锁定用sudo apt-mark unhold openssh-server。
铁律三：apt download下载的.deb包，其内部路径结构可直接ar x查看apt download openssh-server下载的包是标准 ar 归档，可直接解压窥探：
apt download openssh-server ar x openssh-server_*.deb tar -xf data.tar.xz # 解压出真实文件树 ls -R ./usr/ ./etc/ # 查看包内路径规划这比查文档更快，尤其当你需要确认某个特定文件（如nvidia.ko）是否在包内时。我调试nvidia-driver-535时，就是用此法确认nvidia-modeset.ko是否包含在包中，避免了盲目安装。
