Linux 为什么没有 C 盘?从目录结构讲清 Linux 的设计逻辑

后续我会将公众号文章按照 Linux 知识体系进行分类整理，从基础入门到运维实战，逐步构建一套完整的学习路线。每篇文章都会归档到对应专题合集，方便大家系统学习和随时查阅。

无论你是刚入门的新手，还是已经有一定经验的运维工程师，都可以沿着这份知识地图不断深入，建立属于自己的 Linux 知识体系。

摘要

Linux 没有 C 盘、D 盘，不是因为它少了磁盘概念，而是因为它把磁盘、分区和网络存储统一挂进一棵从 / 开始的目录树里。理解 /etc、/var、/usr、/home 的分工，其实是在理解 Linux 如何把配置、程序、运行数据和用户数据分开管理。

很多 Windows 用户刚接触 Linux，第一反应通常不是“这个系统好高级”，而是“我的 C 盘去哪了？”

在 Windows 里，我们习惯从盘符开始理解文件。系统盘是 C，数据盘可能是 D，U 盘可能是 E。一个软件装在哪里，往往也会和某个盘符绑定。

到了 Linux，世界突然变了。

你看到的是 /etc、/var、/usr、/home、/run。教程让你改 SSH 配置，路径是 /etc/ssh/sshd_config。服务报错，让你去 /var/log 看日志。用户文件在 /home/用户名。程序可能在 /usr/bin，也可能在 /usr/local/bin。

新手很容易觉得：这也太乱了。

但 Linux 目录结构不是乱放。它的核心不是“这个文件在哪个盘”，而是“这个文件承担什么职责”。

先从一个排障场景说起

你刚接手一台服务器，Nginx 启动失败。

如果你带着 Windows 思维，第一反应可能是：Nginx 安装目录在哪里？配置、日志、程序是不是都在同一个文件夹？

但在 Linux 上，答案往往不是这样。

配置可能在：

/etc/nginx/

日志可能在：

/var/log/nginx/

程序可能在：

/usr/sbin/nginx

网页文件可能在：

/var/www/

也可能在业务自己指定的目录，比如 /data/www。

这不是故意折磨人。Linux 在做一件很朴素的事：按用途拆分。

配置文件归配置文件。

日志归日志。

程序归程序。

用户数据归用户数据。

运行时状态归运行时状态。

这种拆分看起来没有 Windows 那么直观，但在服务器上很有用。因为运维排障时，你不是在找“某个软件的文件夹”，而是在判断问题属于哪一类：配置错了、日志暴涨、程序缺失、权限不对，还是数据盘挂载异常。

历史背景：这套思路不是 Linux 凭空发明的

Linux 继承了 Unix 世界很多习惯。

Unix 很早就运行在多用户、多任务环境里。一台机器可能被很多人同时使用，也可能跑很多服务。这样的系统不能只按“个人电脑文件夹”来组织。

它必须回答几个问题：

系统启动需要哪些最小文件？

哪些文件是本机配置，不能和别的机器混用？

哪些文件会不断变化，可能把磁盘写满？

哪些文件属于普通用户？

哪些程序由发行版管理，哪些程序由管理员自己安装？

这些问题比“放 C 盘还是 D 盘”更重要。

后来 Linux 生态变大，不同发行版如果随便放文件，软件包、脚本、文档、运维习惯都会混乱。于是有了 Filesystem Hierarchy Standard，也就是 FHS。它定义了类 Unix 系统里常见目录的用途，让发行版、软件作者和管理员有一个共同参考。

注意，FHS 不是说所有 Linux 必须长得一模一样。它更像交通规则。大部分时候大家按它来，但不同发行版、容器系统、嵌入式系统、不可变系统仍然会有差异。

所以学 Linux 目录，不能死背。要先理解它为什么这样分。

技术原理：Linux 用一棵树统一所有文件系统

Linux 没有 C 盘、D 盘这种入口。它把所有可访问的文件组织成一棵树，根是 /。

磁盘分区、U 盘、网络存储、临时文件系统，都可以挂载到这棵树上的某个目录。

比如：

/home /data /mnt/backup

这些路径看起来只是普通目录，但背后可能对应不同磁盘、不同分区，甚至远程存储。

这就是挂载点。

挂载不是复制文件，而是把一个文件系统接到目录树的某个位置。你访问这个目录，就等于进入了那个文件系统。

这带来一个很大的好处：应用程序不需要关心底层是第几块盘。它只要访问路径。

数据库可以把数据放在 /var/lib/mysql，但底层你可以把这个目录单独挂到一块高性能磁盘上。

网站可以把业务数据放在 /data/www，底层你可以挂载云盘、NAS 或本地 RAID。

日志可以在 /var/log，你也可以给 /var 单独分区，防止日志把根分区撑爆。

路径稳定，底层存储可以调整。这是 Linux 文件系统设计里很实用的一点。

设计逻辑：按职责分开，降低系统维护成本

Linux 目录结构有一条主线：把不同生命周期、不同风险、不同管理者的文件分开。

有些文件很稳定，比如系统程序和共享资源。它们升级时才变化。

有些文件经常变化，比如日志、缓存、数据库状态、队列文件。

有些文件是本机特有配置，复制到另一台机器可能就不适用。

有些文件属于用户，不该和系统文件混在一起。

这些东西如果都放在一个目录里，短期看省事，长期会很痛苦。

系统升级时，程序和配置混在一起，容易覆盖。

日志增长时，可能拖垮系统盘。

备份时，不知道哪些要备份，哪些可以丢。

排障时，不知道问题属于配置、程序、数据还是运行状态。

Linux 把它们拆开，本质上是在给系统维护做分层。

这也是为什么服务器环境更喜欢这种结构。服务器不是装完软件就结束了，它要长期运行、升级、备份、迁移、排障。目录结构清楚，后面的工作才有抓手。

/：根目录，不是 root 用户目录

/ 是整棵目录树的起点。

新手容易把 / 和 /root 混在一起。它们不是一回事。

/ 是根目录。

/root 是 root 用户的家目录。

系统里的绝对路径通常都从 / 开始，比如：

/etc/passwd /var/log /usr/bin/ls /home/alice

根目录下面不应该随便堆业务文件。真实工作里，有些人喜欢把安装包、临时脚本、业务数据直接扔到 / 下。短期能用，长期很难维护。

根目录应该保持清爽。它是系统结构的入口，不是杂物间。

/etc：本机配置的集中地

/etc 主要放本机系统配置。

比如 SSH 服务配置常见于：

/etc/ssh/sshd_config

系统级用户、组、主机名、网络、服务配置，也经常能在 /etc 下面找到线索。

FHS 对 /etc 的定位很明确：主机特定的系统配置。它不应该放二进制程序。

这句话很关键。

/etc 里的东西通常回答的是：“这台机器要怎么运行？”

不是“程序在哪里”。

这能解决一个实际问题：配置和程序分离。

程序升级时，不应该轻易覆盖你的本机配置。配置备份时，也不需要把整个程序目录打包。自动化运维里，我们经常用 Ansible、SaltStack 或脚本管理 /etc 下的配置，本质上也是利用了这层分工。

但也要注意，不同软件的配置路径会有发行版差异。比如 Nginx 在 Debian/Ubuntu 上常见 sites-available 和 sites-enabled 这种布局，RHEL 系不一定按这个方式组织。写教程时，不能把某个发行版的路径说成所有 Linux 都一样。

/var：最容易把服务器撑爆的地方

/var 放 variable data，也就是运行过程中会变化的数据。

常见目录包括：

/var/log /var/lib /var/cache /var/spool /var/tmp

这里是运维排障的高频区域。

日志在增长。

缓存会堆积。

数据库、容器、包管理器、服务状态都可能在这里留下大量数据。

很多磁盘满的事故，最后都能追到 /var。比如日志轮转没配置好，/var/log 写满。Docker 默认数据目录占满 /var/lib/docker。数据库数据放在 /var/lib 下，结果根分区空间不足。

生产环境里，经常会把 /var、/var/log 或具体业务数据目录单独规划。这样做不是为了好看，而是为了隔离风险。

日志写满，不至于立刻拖死整个根分区。

数据库数据增长，可以单独扩容。

缓存可以清理，但配置和程序不能乱删。

这里也有区别。不是所有日志都一定在 /var/log。使用 systemd 的系统可能大量依赖 journald。容器环境里，日志可能被容器运行时接管。云厂商也可能采集到远端日志服务。

所以正确说法不是“日志都在 /var/log”，而是“传统和常见场景下，系统和服务日志经常能在 /var/log 或日志系统中找到”。

/usr：系统提供的软件资源

/usr 是新手最容易误解的目录之一。

看到 usr，很多人以为它是 user，于是觉得这里应该放用户文件。今天这样理解会误导你。

现代 Linux 中，/usr 通常放系统提供的软件、库、文档和共享资源。

常见路径：

/usr/bin /usr/sbin /usr/lib /usr/share /usr/local

你平时执行的很多命令，实际在 /usr/bin。很多系统库在 /usr/lib。帮助文档、图标、语言文件、共享数据常在 /usr/share。

这背后的设计逻辑是：把系统提供的相对静态资源放在一起。

这样做有几个好处。

第一，便于由包管理器统一管理。

第二，便于做只读挂载或镜像分发。

第三，便于把本机配置和运行数据从程序资源里分离出来。

现代发行版里还有一个变化，叫 /usr merge。简单说，/bin、/sbin、/lib 可能变成指向 /usr/bin、/usr/sbin、/usr/lib 的符号链接。这样做可以减少路径分裂，让系统更一致。

所以你在一台机器上看到 /bin/ls，在另一台机器上看到 /usr/bin/ls，不要急着判断谁错。先看系统实际布局。

/bin、/sbin：传统分工和现代变化

传统上，/bin 放所有用户都可能用到的基础命令，/sbin 放系统管理相关命令。

以前这么分，是因为系统启动、修复时需要一批最小工具。根文件系统要能在较早阶段提供这些命令。

但随着 initramfs、包管理、系统启动方式和 /usr merge 的发展，这个边界在很多发行版上已经变弱。今天更重要的是理解“传统分工”和“现实系统布局”可能不同。

运维实践里，不要凭记忆猜命令路径。用系统自己告诉你：

command -v systemctl command -v nginx

这类命令只是查询，不会修改系统。

/home：用户数据和个人配置

普通用户的家目录通常在 /home 下。

比如：

/home/deploy /home/alice

用户自己的文件、Shell 配置、个人软件配置，很多都在这里。

但这里也有坑。

第一，/home 不是天然安全区。它是否单独分区、是否备份、是否加密，取决于系统设计。

第二，服务账号的家目录不一定都在 /home。有些系统用户可能没有可登录 Shell，也可能使用 /var/lib/某服务 作为状态目录。

第三，root 用户的家目录通常是 /root，不是 /home/root。

桌面 Linux 还会涉及 XDG Base Directory Specification。它把用户级配置、缓存、数据进一步拆开，比如常见的 ~/.config、~/.cache、~/.local/share。这和系统级 /etc、/var 的思路是一致的：配置、缓存、数据分开，不要全塞在一个地方。

/run：重启后就该消失的运行时状态

很多新手会忽略 /run。

/run 放运行时数据，比如 PID 文件、Socket、锁、当前启动周期里的状态信息。它通常是临时文件系统，重启后内容会消失。

这解决了早期系统里的一个麻烦：启动过程很早就需要保存运行时状态，但 /var 不一定已经准备好。后来 /run 被用来集中放这些“本次启动期间有效”的数据。

所以看到 /run 下面的文件，不要把它当成长期配置。服务重启或系统重启后，它可能就没了。

生产排障中，Socket 文件、PID 文件、服务运行状态，有时会在 /run 下找到线索。但你不应该把重要业务数据放这里。

/opt、/srv、/data：软件、服务数据和公司的习惯

/opt 通常用于附加应用软件包。很多商业软件、第三方软件会选择装到 /opt/软件名。

/srv 按 FHS 的设计，用于这台机器对外提供的服务数据，比如 Web、FTP、版本库等。不过现实中，/srv 的使用并没有在所有发行版和公司里统一起来。

/data 不是 FHS 的标准必选目录，但在生产环境非常常见。很多公司会把业务数据盘挂到 /data，再按项目分目录。

这就引出一个现实问题：标准和公司规范不是一回事。

FHS 给通用规则。

发行版有自己的实现。

公司还会有自己的目录约定。

你接手生产环境时，不能只背 FHS。还要看公司的部署规范、备份策略、监控规则和自动化脚本。

不同方案怎么选：放 /var、/opt、/srv 还是 /data

这个问题在真实工作中很常见。

软件由发行版包管理器安装，通常让它按发行版规则走。配置在 /etc，程序在 /usr，状态数据在 /var/lib，日志在 /var/log，不要手动乱搬。

第三方商业软件，如果官方推荐 /opt/软件名，可以按它来。这样和系统包管理器的目录分开，后续升级、卸载、排查都清楚。

Web 服务对外提供的数据，可以考虑 /srv，但要看团队是否采用这个约定。

业务数据盘、上传文件、模型文件、备份目录，很多公司会放 /data。优点是直观，容易挂载独立磁盘。缺点是它不是标准统一语义，必须靠公司规范约束。

容器环境又不同。容器里看到的 / 是容器自己的根文件系统，不等于宿主机的 /。你在容器里写 /data，实际可能来自宿主机挂载进来的卷。排障时要分清：你看到的是容器视角，还是宿主机视角。

生产环境怎么用这套知识

接手一台机器，先不要改。

先观察。

看当前目录：

pwd

看根目录结构：

ls /

看挂载关系：

findmnt

看磁盘空间：

df -h

看大目录占用时，可以谨慎使用：

du -h --max-depth=1 /var

这个命令只统计，不删除。但在大目录上可能比较慢，生产高峰期要注意影响。

真正排障时，可以按问题分类找路径。

服务起不来，先看配置、服务状态和日志。

磁盘满了，先看挂载点，再看 /var、业务数据目录和日志目录。

软件找不到，先看包管理器、PATH 和 command -v。

用户权限问题，先看用户、组、家目录、文件权限和挂载选项。

数据库异常，不要只看程序目录，要看数据目录、日志目录、磁盘空间和文件系统状态。

这套路径认知会直接影响排障速度。

新手最容易踩的坑

第一个坑：把所有东西都放 /root。

很多新人用 root 登录服务器，顺手把脚本、安装包、备份文件都放在 /root。短期方便，长期没人敢动。换人维护时，谁也不知道哪些能删，哪些不能删。

第二个坑：直接在 /usr/bin 手动丢程序。

/usr/bin 通常由发行版包管理器管理。你手动塞文件进去，可能和软件包冲突，升级时也难追踪。自己编译或本机安装的软件，更适合考虑 /usr/local 或团队规定目录。

第三个坑：日志不管，直到 /var 写满。

服务日志、应用日志、容器日志都可能增长。生产环境必须有日志轮转、保留周期和告警。等磁盘满了再处理，通常已经影响服务。

第四个坑：以为目录名等于分区。

/home 可以是单独分区，也可以不是。/data 可以挂了大盘，也可能只是根分区里的一个目录。判断存储边界要看 findmnt 或 df，不要只看名字。

第五个坑：把容器内路径当宿主机路径。

容器内的 /etc、/var、/app 是容器视角。宿主机上真实数据在哪里，要看卷挂载、容器运行参数或编排配置。

相关知识延伸：目录结构背后的运维能力

学 Linux 目录，表面是在学路径，实际是在学系统边界。

你会开始理解：

哪些文件应该进配置管理。

哪些目录需要备份。

哪些目录适合单独挂盘。

哪些数据可以清理，哪些不能碰。

哪些路径是发行版管理，哪些路径是业务团队管理。

这就是从“会敲命令”到“会维护系统”的差别。

命令只是入口。真正决定你排障水平的，是你能不能判断一个文件为什么在那里，它由谁创建，生命周期多长，坏了会影响什么。

总结

Linux 没有 C 盘，不是因为它没有磁盘，而是因为它选择了另一种组织方式。

它用 / 作为统一入口，用挂载点接入不同文件系统。

它把配置放到 /etc，把变化中的运行数据放到 /var，把用户文件放到 /home，把系统提供的软件资源放到 /usr，把临时运行状态放到 /run。

这套结构解决的不是“好不好看”的问题，而是长期维护问题：升级、备份、排障、隔离风险、支持多用户和多服务。

所以不要死背目录。

先问：这个文件是什么类型？谁管理它？它会不会变化？要不要备份？系统重启后还该不该存在？

这个问题问顺了，Linux 目录结构就从一堆陌生路径，变成了一张能指导你工作的地图。

互动提问

你第一次接触 Linux 目录时，最困惑的是没有 C 盘，还是分不清 /etc、/var、/usr、/home 各自该放什么？