企业官网建设流程全解析

最近帮某项目组看一台新装的服务器，一开始拿到登录密码，对方第一句话就是：这些目录总觉得见过又说不清，Linux常用目录有哪些？我当时愣了一下，因为这种“每天都见面，真问起来又讲不明白”的感觉，恰恰是很多人的共同状态。你要是只知道ls能看目录，却不知道/etc下面藏着什么，遇到配置出问题就只能到处瞎翻，效率特别低。这篇就把我这些年使用 Linux 目录体系的实际心得捋一遍，从设计逻辑讲到常用路径，再到线上排查时怎么靠它快速定位问题，希望能给你一套能直接上手的理解框架。

1. 别急着背路径：先搞明白 Linux 目录这棵大树是怎么长的

1.1 从 Windows 思维切过来，最需要改掉的三个习惯

很多刚从 Windows 转过来的人，会默认每个盘符就是一个独立世界，C 盘装系统，D 盘放资料，E 盘留备份。Linux 的世界没有盘符概念，整个系统就是一棵以/为根的大树，所有硬盘分区、U 盘、光驱，甚至内存里的一段虚拟数据，都是通过“挂载”挂到这棵树上的节点。所以第一步不是背路径，而是改变“目录就是文件夹”的直觉。

我见过有的同事用 Linux 第一周，把项目代码往/root里塞，下载的安装包往/home/普通用户目录里放，结果日志找不到、软件装不上、权限乱成一锅粥。原因很简单：他还在拿 C 盘 D 盘的分类逻辑套用。Linux 目录并不是按“我的文件”和“系统文件”这么粗粒度的方式分的，它在设计上就严格区分了系统资源、用户数据、运行状态和临时数据。

第二个要改掉的习惯是把路径写成死记硬背的字符串。事实上，每个目录之所以存在，背后都对应系统运行链条里的一个环节，比如/usr存放共享、只读的系统资源，/var存放会变化的数据，/tmp存放可以被随时清理的临时内容。名字本身就暗示了用途，记不住的时候，先看目录名再查一下，往往就能猜对。

第三个习惯，也是最重要的：别把每个目录单独看待。Linux 目录之间有关联。比如/usr/sbin里缺了某个命令，系统日常可能没感觉，但一旦进入单用户模式，缺的就是启动和恢复所需的工具；/var/log满了之后，可能会连带让整个系统写不进登录信息，甚至拖垮服务。目录是树的一环，不是孤岛。

1.2 一棵“斜杠树”的成长史：根目录与挂载点

理解根目录，必须理解“挂载”这个词。物理硬盘不天然叫/，/只是系统启动时第一个挂载上的文件系统；其他分区再按约定挂到某个子目录上，比如/boot可能是一块独立分区、/home可能是另一块数据盘。这就像一棵树的树干是/，大的树枝是挂载点，树叶才是具体文件。

这种设计的优点极其明显：某个分区问读写会卡顿，你可以把整个分区卸载下来检查；某块数据盘坏掉了，只要业务目录挂载到约定位置，把新硬盘按同样路径挂回去，系统里的路径引用一个都不用改。我在实际项目里不止一次用这个特性完成数据盘迁移：先把/data下的应用停掉，卸载挂载点，换一块新盘重新格式化挂到同一个/data，服务立刻恢复正常，代码里所有路径依然有效。

所以在讨论常用目录之前，一定要把mount的概念印在脑子里。看到/dev/sda1 on / type ext4，就该明白根文件系统来自哪块磁盘；看到/dev/sdb1 on /data，就该知道应用数据被隔离存放。很多人定位问题时只盯着报错，却忽略df -h里挂载点信息，这是很可惜的。

1.3 我建议新手先记住的三条目录规则

与其一次性背二十个路径，不如先记住三件事：

第一，系统启动离不开的目录要“小而稳”，像/bin、/boot、/lib这些，尽量保持精简，别的东西不要乱塞。

第二，业务数据和个人文件要“分得开”，/home管用户，/var管运行数据，/opt管独立安装的可选软件，互相不污染。

第三，虚拟目录不能当普通文件系统对待，比如/proc和/sys里看到的东西，很多并不是真实磁盘上的文件，你往里面写不合适的值，可能会直接改变内核运行状态。

只要这三条逻辑通了，后面看具体目录的时候，基本都能举一反三。

2. 命令、库文件与“卡在中间”的 /usr：系统程序的家谱

2.1 /bin 和 /sbin：开机和救援模式也要能运行的那批命令

/bin这个目录几乎是所有发行版默认带的核心命令所在地，ls、cp、mv、cat都曾经放在这里。它的关键特征在于，里面装的是系统启动、单用户模式下都必需的命令，而不是可以被随意卸载的附加工具。所以/bin不能随便精简，否则你会在救援模式里发现连删除日志文件的指令都用不了。

/sbin则是给管理员用的系统管理命令，比如fdisk、iptables、reboot。字母 s 代表 system，意思是这部分的工具权限更敏感，普通用户几乎不会用到，通常是root或具备特定能力的用户才执行。不过现在很多发行版已经把这些路径做了合并和符号链接处理，你看到/bin指向/usr/bin或者/sbin指向/usr/sbin都正常，不用惊讶。

需要提醒的是，不同发行版的拆分策略并不完全一致。早先 Debian 和 Ubuntu 还在靠目录区分哪些命令属于系统核心，如今的 Fedora 系和较新的 Debian 系则大量使用/usr合并方案，也就是把/bin、/sbin、/lib统一收纳到/usr/bin、/usr/sbin、/usr/lib下面，再通过软链保留旧路径。对使用者来说，效果相差不大，但看系统输出时别被符号链接绕晕，ls -l /bin能直接显示指向关系。

2.2 /usr 为什么是个“大头”：/usr/bin、/usr/local/bin 与 /usr/share

如果你新装一个系统后执行du -sh /usr，很可能发现这个目录占了几个 GB 甚至十几个 GB，因为/usr是系统安装的大部分只读、共享数据的大本营。它不叫 user，绝不是普通用户的文件目录，而是 Unix System Resources 的思路，也就是说系统里很多通用程序、图形资源、开发库、文档都被收纳在这里。

实际操作中，/usr/bin里的命令由系统包管理器统一管理，你安装vim、git、curl时，可执行文件一般落到这里。而/usr/local/bin是给管理员自己编译安装软件用的。两者区分在于：前者升级依赖包管理器，后者由你手动维护，优先级也更高。默认PATH里，/usr/local/bin往往排在/usr/bin之前，正是为了让你自定义安装的版本能覆盖系统自带版本。

还有一个容易被忽略的/usr/share，它存放与架构无关的共享数据，比如菜单项、图标、帮助文档、时区数据。多数人一辈子不直接碰它，但打包软件时，配置示例文件和文档却常被放到这里。如果你在某个软件目录下找不到样例配置文件，不妨去/usr/share/doc/或/usr/share/软件名/翻一翻。

2.3 /lib 和 /lib64：被我忽视的共享库

很多人常年操作 Linux 目录，却对/lib和/lib64印象模糊。实际上，/bin和/sbin里的很多程序都是动态链接的，启动时依赖共享库，这些库就存于/lib和/lib64。如果某天你发现某个系统命令报错“文件找不到”或者ldconfig检查异常，多半和库路径损坏脱不开关系。

同样的，现代系统里/lib也常常是复合路径，真正文件可能放在/usr/lib，然后通过软链映射。我在某次救援一台老式 CentOS 时发现，/lib64如果被误删，几乎系统所有命令都会立刻瘫痪，这种教训非常深刻。所以没事绝对不要去手动清理/lib下的内容，别有“这些 .so 文件没用”的念头。

2.4 近年发行版把 /bin 合并到 /usr/bin 是怎么回事

这件事在两三年前讨论度很高。整套迁移逻辑是：早期 Unix 为节省磁盘空间，把启动必需的少量命令放在根文件系统的/bin，其余庞大的软件放到独立挂载的/usr分区分区。但后来根文件系统本身也以一个完整文件系统的形式存在，区分它在哪个分区区域已经不是必要的事。与其维护两套路径，不如统一到/usr/bin下，再用符号链接保持路径兼容。

对普通管理员的意义在于：当你想给某个脚本批量安装工具，直接看which xxx返回结果更可靠。不用过分担心路径归属。实际操作中，我仍建议把临时性的、自己写的独立程序放在/usr/local/bin，保持“系统管的不动、自己装的分开”这一清晰边界。

3. 你天天折腾的配置和数据多数集中在这三块：/etc、/var、/home

3.1 /etc，一台机器的性格都写在里面

如果一定要我给 Linux 目录体系选一个最值得熟悉的位置，我会毫不犹豫地说/etc。这个目录集中了几乎所有核心服务的配置文件。每个服务装好后，默认配置模板往往都会在/etc下生成，比如网络接口配置、用户管理文件、计划任务文件、SSH 服务配置等。

拿最常见的排查场景举例：Nginx 起不来，第一时间不是搜排错日志，而是到/etc/nginx/下检查配置文件，通常整个目录会拆成nginx.conf、conf.d/、sites-available/等几个层次。如果只看主配置文件找不到某些虚拟主机设置，就得顺着include指令找到实际加载的分目录文件。改完配置一般还要用nginx -t验证语法，然后再重启或重载。

/etc/passwd和/etc/shadow也值得认识。前者保存用户的基本信息，后者保存加密密码串和有效期。我见过有人在/etc/passwd里手改 UID，改完才发现权限全乱了。正确姿势是使用usermod或vipw这类命令，而不是直接用编辑器硬改，否则文件格式和字段顺序容易被弄崩。

3.2 /var，日常运维的大本营

/var的名字来自 variable，也就是“会变的数据”。几乎所有运行过程中写入的新数据都集中在这里：日志文件、缓存、数据库文件、邮件队列、临时排队任务等。

其中/var/log恐怕是运维最常光顾的目录。系统启动日志、内核日志、各个服务的业务日志，整体以文件形态挂在/var/log下。像messages、syslog、secure、cron这些文件，在不同发行版里名字和位置略有不同，但基本都集中在这个大本营。遇到服务不正常时，tail -f /var/log/日志文件几乎是开局动作。

需要警惕的是，/var的写入量可能非常大。日志轮转配置稍有不慎，大量日志文件堆积起来会直接占满磁盘。我处理过最典型的问题是某个业务疯狂打印错误日志，但轮转周期设置太长或根本未启用，一天之内/var从 20G 增长到 60G，最后整台服务器写不进去任何新文件。排查方法不是只盯着磁盘余额，还要用du -sh /var/log/*找到具体哪个大文件在膨胀。

/var/lib同样重要，很多软件包的数据文件存于此，比如 Docker 容器数据、MySQL 的 data 目录、包管理器的数据库等。它不像日志那样频繁滚动，但一旦损坏，问题更加致命。所以在做备份和迁移时，/var/lib往往比/etc更关键，缺了它等于丢了一整段业务数据。

3.3 /home 与 /root 的权限边界

/home是普通用户的个人目录所在地。每个用户一个子目录，默认权限通常设置为只有用户自己和 root 能访问，这也正是多用户系统的基本隔离保障。如果你的程序要用特定低权限账号跑业务，就应当把数据放在该用户的/home/用户名/下，而不是丢到系统目录里。

/root是超级管理员 root 用户的家目录。不少新手以为自己哪天拥有 sudo 权限后，就该把临时文件，项目代码都放到/root下，其实这是个坏习惯。/root目录的空间分配通常和根分区绑在一起，根分区一旦被塞满，系统会马上进入危险状态。我自己有一次就是因为把大体积的数据库备份文件直接丢在/root下，结果根分区空间告急，连系统服务都差点起不来，后来只能紧急迁移到其他挂载点。

权限边界这条，核心原则是：普通用户不该读的配置不要给读权限，服务运行账号尽量不用 root 身份。特别是 Web 服务，一旦运行身份是 root，它就有权限读取服务器上的任意文件，任何代码漏洞都可能演变成灾难。正确方法是给服务单独建一个系统用户，通过chown和chmod配置对应目录权限。

3.4 我的一次“找配置”实战：从 /etc 一路捋到 /var

说一个真实的过程，某次部署一个内部工具时，服务总是启动失败，日志文件却写着“no such file or directory”。我第一反应不是看堆栈，而是先找到服务的配置文件在/etc下的位置，发现某个路径参数指向了/var/lib/服务名/data，这个目录在安装时没有自动创建。于是我手动建立目录并调整 owner，重启服务后问题消失。

这个案例想表达的是：目录体系的核心不是单向记忆，而是联动推理。/etc里配置的路径往往指向/var或/home下的实际数据位置，启动时缺少目录，服务就会报错。你在日志里看到的“文件不存在”，很大概率是目录层级问题，而不是配置文件里写了奇怪的东西。所以排查的第一步永远是跟着配置里的路径走一遍，缺目录就建目录，缺权限就修权限。

4. 虚拟目录不是摆设：/proc、/sys、/dev 里能读到系统心跳

4.1 /proc：以文件形式请求运行中的内核

/proc是 Linux 体系里最有意思的目录之一。你进去会看到一堆数字命名的目录，那其实是每个运行进程的 PID 映射区间。1 号进程、某登录会话的 bash 进程、某个服务进程，所有进程信息都以文件形式暴露出来。

最常用的是/proc/meminfo，通过cat /proc/meminfo可以看到内存总容量、剩余内存、缓冲区大小等数据。很多图形化监控工具其实无非就是把这些信息整理一遍。/proc/cpuinfo则展示 CPU 信息，比如型号、核心数、标志位。还有/proc/loadavg可以查看系统最近一分钟、五分钟、十五分钟的平均负载。

你可能也听说过，往某些/proc/sys下面的文件写入内容，可以临时改变内核行为，但这里绝对不能乱来。/proc/sys/net/ipv4/ip_forward的 0 和 1 两种值会直接影响路由转发功能。这种修改是内存级的，重启后恢复默认值，如果需要持久化，得写到/etc/sysctl.conf等sysctl 配置里。我曾见过有人用 echo 命令直接往/proc/某文件写值，结果屏幕上一切正常，重启后才发现改动全部消失，白忙一场。

4.2 /sys：内核参数和设备的“控制台”

/sys目录的可视化结构来源于内核设备和驱动的抽象，它通过 sysfs 文件系统暴露设备驱动、总线、电源管理等信息。相比/proc更多展示运行状态，/sys更像一个可写可控的设备控制台。

举一个实际例子，若干服务器在硬件层面启用了某个设备状态管理技术，但固件太老，导致系统误判设备状态。通过查看/sys/class/...下面的文件内容，可以快速确认设备是否正确枚举。如果在虚拟化环境里，还可以通过/sys/devices/system/cpu/查看 CPU 核数粒度，来确认虚拟机分配的资源是否真的生效。

值得注意的是，/sys里的很多文件属于只读，只有部分节点支持写入。修改前一定要确认这个节点是否被内核标记为可写，且需要知道修改值的含义。如果只凭猜测，可能会把电源策略、CPU 调频策略改出问题。更稳妥的做法是优先使用各家发行版包装好的工具去调整，比如power-profiles-daemon、tuned等，操作系统会比你先知道哪些参数不应该被乱动。

4.3 /dev：用户可见的设备文件

/dev里装的是设备文件，包括块设备（如硬盘分区/dev/sda、/dev/sdb）和字符设备（如终端/dev/tty、随机数生成器/dev/urandom）。Linux 的设计是“一切皆文件”，所以硬件设备也被抽象成文件，程序通过读写这些文件来完成与硬件的交互。

最常见的操作是查看磁盘信息，lsblk会通过/dev下的设备节点结构展示出磁盘和分区的关系。挂载 U 盘或硬盘时，也需要知道它在/dev下对应哪个节点，比如/dev/sdb1。我要特别提醒的是，不要只看设备名字就建文件系统，尤其在同一台机器插过多个移动盘的情况下，设备名可能发生变化，错格式化一个分区就是事故。稳妥做法是结合lsblk -f或blkid确认 UUID 再操作。

同时/dev/null也是个神奇的存在。丢弃输出的场景，只要把流重定向到它即可：ls -l > /dev/null 2>&1。而/dev/zero用于产生连续的空字节流，在测试或清零时很有用。这些虚拟字符设备不是磁盘文件，不会占存储空间，习惯了之后会发现 Linux 的 IO 逻辑非常通顺。

5. 临时文件与挂载点：/tmp、/run、/mnt、/media 为何单独存在

5.1 /tmp 的“重启即清”设计，很多人知道却用错

/tmp是所有用户都可以写入临时文件的目录，没有特别权限限制，但它的核心特征是可清理、不持久。多数发行版会把/tmp做成独立挂载的临时文件系统，或者定期清理旧文件，重启后内容也会被清空。所以绝对不要把重要数据、唯一副本放进/tmp。

很多人会在这里踩坑：下载了一个安装脚本，图省事放到/tmp下执行，结果因为目录被清理，下次想重新查看脚本却发现文件没了。更隐患的是，如果一台服务器上有多个用户，任何一人都能在/tmp写文件，如果没有启用安全的 sticky bit（权限中那个 t 标志），可能出现互相覆盖的问题。正常情况下/tmp权限应该带有1777，允许所有人创建，但不允许删除别人的文件。

如果你需要用临时目录且要求重启后足够安全，可以考虑/tmp配合systemd-tmpfiles管理规则，或者干脆给每个进程单独建临时目录。在 Java、Python 等开发场景里，框架会默认使用/tmp作为工作目录，当临时文件过大时，要注意对文件和tmpfs占用的内存空间做限制。我见过一次诡异的内存占用飙升，查到最后原因是某调度框架在/tmp里疯狂写临时大文件，把 tmpfs 的可用内存吃光了。

5.2 /run 存放系统运行期数据的由来

/run是一个相对较新的固定目录，用来存放系统启动以来产生的运行时信息。它通常也是 tmpfs，即内存文件系统，意味着内容不持久，重启后自动重建。早期/var/run会承担这个功能，现在很多发行版把/var/run作为/run的软链，让存放运行期状态的位置更受约束。

你可以通过/run下挂载的 socket 文件，看到一些服务进程对外提供的通信入口。比如某些监控代理或数据库客户端会在这里生成 socket 文件，程序通过它和本地服务通信。还有一个常见例子是用户登录会话信息，很多桌面环境或 SSH 服务会在/run/user/用户ID/下创建与当前用户相关的运行时目录。

由于/run是内存文件系统，空间占用受内存限制。如果某个服务被配置成在这里写大文件，内存就会异常紧张。我自己遇到过一次，某服务把 pid 文件和临时锁文件全写在/run下，结果锁文件数量暴增，内存占用率高居不下。最终排查才发现是服务配置里指定的 pid 文件路径不对，导致每次重启都残留一个文件。

5.3 /mnt 和 /media 该用的场景

/mnt最早的设计是给管理员手动挂载临时文件系统的目录，普通用户不该随手往里放文件。现在很多包还是会默认把网络存储或手动挂载的盘指定到/mnt下的某个子目录，比如/mnt/data。手动执行mount /dev/sdb1 /mnt/data，提示符路径就会显示到/mnt/data。

/media则是桌面环境自动挂载移动存储设备的位置，比如插入 U 盘时，系统会自动在/media/用户名/下面建立一个挂载点。这个自动挂载能力是现代化桌面 Linux 的特点，但在纯服务器上可能没有桌面组件，所以/media未必存在或处于空状态。

我的建议是：如果只是临时看一眼盘里的内容，用/mnt或/media都无所谓；如果你需要一个长期稳定的业务数据目录，最好自己在根分区下建一个独立目录，比如/data，再通过挂载配置把数据盘挂上去。这种方式比依赖/mnt更清晰，也不受自动挂载工具的干扰。

6. 实践中容易翻车的目录姿势：排查经验和规划建议

6.1 “根目录能不能清”这类问题的风险

我在网上见过不少人提问说“根分区满了，能不能直接删掉/目录下的大文件？”答案是不行，因为/下每一层的职责几乎都在运转。真正要做的，是用du -sh /* 2>/dev/null逐层查看哪个一级目录占用最大，再继续往下细分。这个过程就像剥洋葱，每一层去掉一些干扰项，最终定位到真正膨胀的目录。

有一次线上告警根分区使用率达到 90%，我顺着/看下去，发现/var下面的 log 和/home下的备份文件各占了一半空间。清除前先确认日志是否需要归档，备份文件能否移动到独立数据盘，而不是随手rm一删了之。因为你可能不需要一个小时后发现删掉的是重要审计日志，追悔莫及。

比较危险的另一类做法是直接动/boot里的旧内核文件。很多人看到/boot占空间就想删，但内核和引导文件一旦误删，系统可能无法启动。正确做法是使用发行版包管理机制清理不再使用但未卸载的内核包，比如某些发行版会保留多个内核版本在/boot，虽然文件不大，但确实容易堆积，不过必须通过命令卸载，而不是手动删除vmlinuz-*。

6.2 磁盘写满的排查链路：/var/log 背大锅

当新项目上线后磁盘突然爆满，我的排查链路基本是固定的：

先df -h查看分区使用率，锁定哪个挂载点满了；接着du -sh /挂载点/*层层进入，定位大目录；再用du -sh /var/log/*或lsof +L1寻找未释放的删除文件。很多服务删掉旧日志文件，但进程还保持文件描述符未释放，实际占用的空间并不会真正减小，只有重启进程或处理文件描述符才会释放。

/var/log经常背锅，是因为很多软件默认不打日志轮转，或轮转配置太保守，日志疯狂增长到几十 GB。我在项目里曾有台机器/var/log下单个日志文件膨胀到 40 多 GB，排查时df显示空闲为 0，但用du查目录时却看不到同样体积的文件，因为部分磁盘占用属于仍被进程占用的已删除文件。这时用lsof | grep deleted找到占用进程，重启或者重新清理才会生效。

为了避免这种事故，建议在部署阶段就检查/etc/logrotate.d/下各个服务的日志轮转配置，设置合理的rotate次数和daily/size阈值；同时给/var/log所在的文件系统加一个空间监控门槛，比如使用率达到 80% 就报警。不要等 100% 再处理，因为写满之后不仅新日志写不进去，很多服务还会因为无法写入状态文件而直接崩溃。

6.3 给项目数据建目录：/opt、/srv、/data 怎么选

项目的软件安装包和业务数据放哪里，向来有几种流派。/opt这个目录历来是放可选软件包的地方，很多闭源软件、独立安装包会自带一个子目录装在/opt/软件名下，卸载时直接删除对应子目录即可。如果你在服务器上下载了某个压缩包解压运行，丢到/opt下很规范。

/srv是系统服务数据目录，专门用于存放由本机提供的服务数据，比如 FTP 服务的文件目录、Web 站点的原始数据。按 FHS 的建议，/srv应当作为服务数据的发行独立位置，但实际生产里使用它的例子并不算多，更多项目直接约定/data或/var/www。

/data并非标准目录，但很多运维团队在自己服务器上会自行创建，把项目痕迹、数据库备份、静态资源统统放进去。好处是语义清晰且挂载方便，当你有一块独立数据盘时，把整个/data挂到那里，迁移时只操作这个目录即可。我需要提醒的是，自建目录也要遵循权限原则，项目之间尽量用独立子目录和独立系统账户隔离，不要所有服务都共用同一个 owner 和同一套权限。

6.4 目录权限和服务账户的原则

目录规划的最后一步永远是权限，权限错了，路径再对也会带来后续隐患。

对于新创建的目录，umask默认值会影响文件和目录的初始权限，尤其是 Web 目录和上传目录，给得太宽就会成为后门。我见过一台测试机把/data直接设置成 777，然后项目里所有的日志、脚本、配置文件都能被任意账号修改，一旦被入侵，攻击者可以直接替换应用文件，导致长期不排查都发现不了。合理的做法是：服务进程运行在独立账号下，目录属主属于该账号组，普通用户对目录只有执行和读取的权限。

有些特殊场景需要运行账号能写某些目录，比如/var/run下的 socket 目录，或者/tmp下的临时工作目录。这时应该通过 systemd 服务的RuntimeDirectory=指令或独立临时目录来实现，而不是粗暴地把整个/tmp或/var/run改成附属权限。这样每次服务启动都会自动重建目录，停止后自动清理，也不影响其他进程。

目录权限这件事，我的经验是：宁可收得紧，发现问题再加，也不要一开始给太宽，否则到最后根本不知道哪个服务在用哪些文件。用ls -l查看属主属组，用namei -l /路径/到/文件查看每一层目录权限，可以快速理清访问链条到底卡在哪一层。很多权限类的疑难杂症，本质上并不是某个文件权限错了，而是路径中间某一层目录缺执行权限。

结束前的一点实在想法

我个人的体会是，目录这块知识没有太多玄学成分。你要做的不是背下每一个标准路径，而是真正在排查和部署中去用。你跑过一次 Nginx 配置出错，自然就记住/etc/nginx和/var/log/nginx的关系；你清过一次/var/log飚涨的问题，自然就明白日志轮转的重要性。把常用的命令和目录行为变成肌肉记忆之后，服务器在你眼里就不再是一堆模糊路径，而是一整条可以顺藤摸瓜的链路。下次再有人问 Linux 常用目录有哪些，希望你能用“这台机器上哪些路径在承担什么角色”的方式，讲出你自己的版本。