1. 从"文件放哪"说起：为什么Linux的目录结构这么讲究
刚接触Linux的时候，我其实特别不适应。以前在Windows上装软件，一路点"下一步"，默认装到C:\Program Files，配置文件散落在注册表里，用户数据扔在C:\Users\用户名下，其实很少有人关心文件到底放哪了。但到了Linux，你会发现一切都不一样——安装软件、改配置、看日志，全都在跟目录打交道。如果你不知道/home、/etc、/opt这些目录是干什么的，那遇到"装了个软件找不到配置"、"用户目录里文件不见了"、"程序起不来报权限错误"这类问题，基本就是两眼一抹黑。
这篇文章我就围绕Linux里三个最常被问到、也最常被搞混的目录来聊：/home、/etc、/opt。它们分别管着用户数据、系统配置和第三方软件，三者的分工非常明确，但也正因为分工太明确了，新手甚至一些干了两三年的运维，都容易踩进各种坑里去。比如把配置文件丢到/opt下结果升级软件时被覆盖，或者/home单独分区空间不够导致用户无法登录，还有人在/etc里乱改权限最后把整个系统搞到起不来——这些我都亲眼见过。
这篇文章适合谁看？刚入门Linux想理清目录结构的新人，正在准备运维面试的求职者，或者已经用了一段时间但还是对"某个文件到底该放哪"没有把握的开发者和运维。我会把每个目录的定位、适用场景、典型布局讲透，同时结合我自己的实操经历，把那些文档里不会写、但实际工作中一定会遇到的坑也一并翻出来。读完你应该能做到：看到一个路径，马上能判断它的用途；遇到目录相关的问题，知道该往哪个方向排查。
2. 三个目录的定位：管用户的、管系统的、管软件的
2.1/home：每个用户的私人地盘
先说说最容易理解的/home。从名字就能猜出来，它是用来放"家"的——当然不是系统管理员的家，而是每个普通用户的个人目录。在Linux系统里，只要你执行useradd创建一个用户，系统默认就会在/home下面建一个和用户名同名的目录，比如用户zhangsan的家目录就是/home/zhangsan。
这个目录里放什么？简单说就是用户自己的私人文件、个人配置、下载的东西、文档、项目代码，等等。用户在这个目录下拥有完整的读写权限，可以做任何他想做的事，但出了这个目录，比如想去改/etc里的系统配置，那就得拿出sudo提权才行。这种设计的核心思路是一个朴素的隔离思想：用户的数据归用户，系统的数据归系统，谁也不干扰谁。
有几个细节值得注意。第一，root用户的家目录不在/home下，而是在/root，这是个特例。第二，当不同的用户有多份工作目录时，cd ~能快速回到自己的家目录，cd ~zhangsan则可以直接跳到指定用户的家目录（前提是你有这个权限）。这个~符号在Shell里展开后就是/home/当前用户名，非常常用。第三，如果/home没有单独分区，而是直接在根分区里，那用户数据会跟系统数据挤在一块——一旦根分区满了，整个系统都可能出问题，后面我会单独讲这块。
很多人容易忽略的是：家目录里还藏着一大堆"点开头"的隐藏文件，比如.bashrc、.profile、.ssh、.local。这些是用户级别的配置文件，也是用户日常最常客制化的区域。比如你想给自己配个别名（alias），改的就是~/.bashrc；想设置git的用户名邮箱，配置文件也在这个目录下。所谓"每个用户有自己的环境"，本质上靠的就是这些家目录下的隐藏配置。
2.2/etc：系统配置的大本营
/etc应该是Linux里最"敏感"的目录之一了。它是整个系统配置的集中地，几乎所有关键服务的配置文件都放在这里。名字来源有说法是"et cetera"（等等其他）的缩写，也有说法是早期Unix里"editable text configuration"的意味，但不管来源如何，现在的含义很明确——各种程序的配置，都优先往这里放。
打开/etc看一下，你会看到一大片文件：passwd（用户账户信息）、shadow（用户密码哈希）、group（用户组）、hostname（主机名）、hosts（主机名映射表）、fstab（开机自动挂载文件系统配置）、resolv.conf（DNS配置）、crontab（定时任务配置），还有像/etc/ssh/sshd_config（SSH服务配置）、/etc/nginx/nginx.conf（Nginx配置）、/etc/mysql/my.cnf（MySQL配置）这样的子目录和文件。
这里的核心特点是什么？所有需要被系统级读取、影响全局运行的配置，基本都在/etc里。当你安装一个软件包时，安装器会自动把默认配置模板释放到/etc下对应的位置；当你改这些配置时，实际上是在覆盖默认值，告诉软件"按我的规则来跑"。改配置文件通常需要root权限，因为普通用户不应该能改动影响全系统的设置。
我对新手有一个忠告：在/etc里做任何修改之前，先备份，再动手，改完最好验证一遍。我见过太多"顺手改了fstab然后重启进不了系统"的案例。这个目录不是不能改，而是要带着敬畏去改，每改一个文件都要清楚自己改的是什么、影响什么服务、怎么回滚。
2.3/opt：第三方软件的安置区
/opt可能是三个目录里最容易被误解的一个。很多初学者以为它是放"可选（optional）"东西的地方，这理解没错，但它更准确的定义是：用于存放不通过系统包管理器管理的、独立的第三方软件。
什么软件适合装到/opt？比如你下载了某个商业软件的二进制包（像一些数据库、IDE、专用工具），它自带完整的目录结构（bin、lib、share等），又不适合被打包进系统的软件源里，那就可以整体解压或安装到/opt下，常见结构是/opt/软件名/或/opt/厂商名/软件名/。这样做的好处是：这个软件的所有文件都集中在一个目录里，互不干扰，想卸载的时候直接删掉整个目录就行，不会像系统包那样留下各种依赖和配置文件残留。
需要特别强调一点：/opt和/etc、/home的分工是不同的。/opt里装的是"要执行的文件"（程序本体），/etc里放的是"控制程序怎么跑"的配置，/home里放的是"用户自己产生的数据"。如果你把某个软件的配置包放在/opt下的软件目录里，这不是不行，但如果你既装了一个官方包到/opt，又用系统包管理器装了同一个软件的发行版版本，那就可能因为配置路径不同而互相干扰——这在实际工作中真实发生过，后面我详细讲。
3. 把它们放进同一张图里：目录到底怎么分工，才不至于打架
光知道三个目录各自的"定位"还不够，更重要的是理解它们之间的协作方式。我经常用一个类比来说明：把Linux系统想象成一家公司。
/etc是公司的制度手册和档案室。各种规则（配置）都记录在这里，员工（进程、服务）上岗之前都要先翻手册，知道该怎么干活。这家公司的制度一旦定下来，是全员生效的——没人能例外。所以改/etc，就是在改全公司的运行规则，风险自然大。
/home是每个员工的工位和个人储物柜。制度是公司定的，但工位是私人的。员工可以在工位上放自己的东西（个人文件），按照自己的习惯布置（个人配置）。你换了一个新员工（新用户），就给一个新工位（/home/新用户名）；员工离职了，工位清理掉，公司别的部门不受影响。
/opt是从外面引入的独立设备。就像公司买了两台专用的打印一体机或者一套特殊的财务软件，它们是独立的、自带的说明书的，不跟公司的制度手册搅在一起。想让它们干活，按它们的说明书（自带配置）来就行，不需要把公司制度改一遍。
这三者之间的关系，其实是Linux文件系统层次标准（FHS，Filesystem Hierarchy Standard）的具体体现。FHS规定了很多目录的标准用途，但普通用户不需要背标准，只需要抓住一个核心判断方法："这个文件是全局配置、个人数据，还是独立程序？"全局配置放/etc，个人数据放/home，独立程序放/opt。一旦你能熟练做出这个分类，大部分目录问题就已经解决了一半。
还有一个容易困扰新手的点是：既然/opt存的是程序，那跟/usr下的程序有什么区别？/usr里装的是跟随系统包管理器走的标准软件，它们融入系统整体，各种库文件、配置、文档会被安装到/usr/bin、/usr/lib、/usr/share等若干不同位置；而/opt下的软件是一个"自包含"的整体，相当于整个世界装在一个文件夹里。这也意味着，如果你想让软件"干净地独立存在"，优先选择/opt方式安装；如果你想让软件跟系统融为一体、随时被包管理器管理，那应该走/usr体系。
4. 实操中你必须掌握的：常用命令、权限逻辑与目录管理
4.1 围绕这三个目录的高频命令
不管是在服务器上排查问题，还是在自己电脑上折腾配置，下面这几个命令组合是绕不开的。我直接列出来，附上实际使用场景。
查看目录结构，最常用的是ls和tree：
ls -lah /home tree -L 2 /optls -lah能列出目录下所有文件（包括隐藏文件），带权限、属主、大小和修改时间；tree则更适合看嵌套目录结构，-L 2表示只看两层深度。
切换目录时，cd大家都熟，但有几个快捷方式值得记：
cd ~ # 进入当前用户的家目录 cd /home/zhangsan # 进入指定用户的家目录 cd - # 回到上一次所在的目录查看当前目录用pwd，查看磁盘空间用df -h，查看目录占了多少空间用du -sh /home /etc /opt。这几个命令在排查"目录满了"的问题时是必用组合。
查找文件时，find是主力：
find /etc -name "*.conf" # 找/etc下所有以.conf结尾的配置文件 find /opt -type f -size +100M # 找/opt下大于100MB的文件如果只想快速定位某个配置文件的位置，还有更快的locate命令（需要先安装mlocate或plocate并执行updatedb更新索引），但find永远是最可靠的兜底手段。
4.2 权限体系：为什么你总遇到"Permission denied"
三个目录虽然定位不同，但都遵守同一套Linux权限体系。我这边给新手一个最简版本的理解框架：每个文件和目录都有一组"三元权限"，分别是读（r）、写（w）、执行（x），它们又分别对三类角色生效：属主（u）、属组（g）、其他用户（o）。
拿/etc下面的文件举例：很多配置文件的权限是644，翻译过来就是属主可读可写，其他人都只读。这意味着普通用户想看配置没问题，但要改，就得切换到root或者加上sudo。而/home下每个用户的家目录通常是755或700。如果是700，那就只有该用户本人能进入，其他用户（包括同组的）都进不去，隐私保护效果最好。
命令行查看权限最直接的方式就是ls -l：
drwxr-xr-x 2 root root 4096 ... /etc/nginx第一个字符d表示这是目录，后面三组rwx分别对应属主、属组、其他人的权限。修改权限用chmod，修改属主用chown，比如：
chown -R zhangsan:zhangsan /home/zhangsan/data chmod 755 /home/zhangsan/data这里要提醒一句：对/etc和/home、/opt进行批量权限修改时，一定要慎之又慎。我见过有人图省事，执行chmod -R 777 /home，结果所有用户的家目录对全世界开放，这等于把隐私数据裸奔在系统里。而如果对/etc执行了错误的chown -R，轻则服务无法启动，重则系统直接无法登录。改权限之前，务必明确"我要改变量是什么、范围多大、影响哪些服务"。
4.3 分区与挂载：当/home空间不够了怎么办
在实际生产环境中，很多Linux安装方案会把/home单独分成一个分区，或者单独挂载一块磁盘。这种做法的好处在于：即使根分区（/）满了，/home还能正常写入；反过来，如果/home被打满，系统其他部分也不至于立刻瘫痪——这也是我推荐在安装系统时就把/home独立分区的原因之一。
但独立分区也有自己的烦恼，最典型的就是**/home空间不足**。这时有几种处理思路。
第一种是清理垃圾。先看看是什么占满了：
du -sh /home/* | sort -rh找出最大的目录后，跟用户沟通是否可以清理旧日志、缓存、无用的下载文件。很多用户的家目录里都藏着几百GB的Docker镜像、conda包缓存、npm缓存，这些往往是可以安全清掉的。
第二种是扩容分区。如果使用的是LVM（逻辑卷管理），扩容相对容易——把空闲的物理卷空间划给/home所在的逻辑卷，然后扩展文件系统。大致步骤如下（以ext4为例）：
lvextend -L +20G /dev/mapper/vg-home resize2fs /dev/mapper/vg-home但如果是传统的非LVM分区，扩容就比较麻烦了，通常需要借助growpart配合resize2fs（云服务器一般支持）或者在线调整分区工具。切记：任何对分区表的操作都有风险，操作前必须备份关键数据，最好先在测试机演练一遍。
第三种是"曲线救国"——把某些大目录迁移到别的磁盘，用软链接指过来。比如你把一个大数据集放到了/data盘，但它实际被某个用户的脚本引用在/home/zhangsan/data路径下，那可以：
mv /home/zhangsan/data /data/zhangsan_data ln -s /data/zhangsan_data /home/zhangsan/data这样对用户来说路径不变，但空间压力转移到了别的磁盘。这种方式很实用，但如果迁移的是系统关键路径，软链接一旦失效就是事故，所以迁移后要立刻验证。
4.4 找回被"隐藏"的文件：目录权限与挂载异常
热搜词里有一条非常典型："银河麒麟home无法显示文件"。这是一个很有价值的真实案例。用户在桌面图形环境里打开家目录，发现里面空空如也，但明明没有删过文件。这种问题通常有两种原因。
第一种是目录权限被改动。如果/home/用户名的权限被改成对其他用户不可读，或者目录的属主变成了root，图形界面的文件管理器可能会因为权限判断异常而不显示内容。解决办法很简单——用root切到该目录下，检查权限：
ls -ld /home/用户名 chown -R 用户名:用户名 /home/用户名 chmod 755 /home/用户名第二种是磁盘挂载异常，这在国产操作系统上也会出现。比如系统开机时/home分区没有被正确挂载，或者挂载失败后被“兜底”在根分区里创建了一个空的/home目录，导致用户看起来"文件全没了"。遇到这种情况，先执行df -h /home看挂载信息，如果发现/home的设备不是你预期的那块磁盘，再执行mount -a尝试按/etc/fstab重新挂载，必要时手动mount。在国产系统上，偶尔还有因为硬盘休眠或者文件系统错误导致目录只读挂载的情况，此时dmesg和journalctl里的报错会给出关键线索。
我处理过不少这类"文件消失"的工单，绝大多数都不是真的丢了，而是挂载或权限问题。遇到"文件没了"先别慌，df -h、ls -ld、mount三连下去，八成能找到原因。
5. 实战案例拆解：这三个目录中常见的"坑"与排查思路
5.1 案例一：配置文件改了没生效——/etc被覆盖了怎么办
有一个非常经典的场景：你手动改了nginx的nginx.conf或者MySQL的my.cnf，重启服务后居然发现配置被重置了，甚至服务直接启动失败。回头一看，发现有些程序在启动时会重新生成配置文件，或者你改的并不是真正被读取的那个文件。
先说第一种情况：某些软件（比如一些容器编排工具、云初始化脚本）在启动时会对配置文件做"校验和对比"，一旦发现配置文件不在它预期的状态，就可能用默认配置覆盖回去。这类软件默认就不希望你手改/etc下的配置，正确做法是找到它预留的"用户自定义配置目录"（比如/etc/xxx/conf.d/），在那里写入自己的调整项。
第二种情况是路径优先级的坑。比如MySQL的配置读取顺序往往是/etc/my.cnf、/etc/mysql/my.cnf、~/.my.cnf等，而且多个文件的内容会叠加。如果你改了/opt/mysql/my.cnf，但系统实际读取的是/etc/my.cnf，那改半天自然不起作用。排查办法是先确认程序真正读取的配置路径，一般可以通过命令参数指定（如nginx -t -c /etc/nginx/nginx.conf）或者用strace追踪打开的文件：
strace -f -e openat nginx 2>&1 | grep my.cnf这个命令能显示进程启动时实际打开过的配置文件路径列表，非常直接。
所以我的建议是：在动/etc里的配置之前，先确认程序到底读的是哪个文件，并且在改动前先备份原文件，记录改动内容，最好在配置文件里用注释写明改动时间和原因。管理多台服务器时，最好把配置版本化，用Ansible之类的工具统一管理/etc下的文件，避免"人肉改配置"导致的环境漂移。
5.2 案例二：装到/opt的软件起不来——动态链接库缺失
热搜里有条信息非常典型：/opt/todesk/bin/todesk: error while loading shared libraries: libxcb-keysyms.so.1。这种"装到/opt的软件起不来，报缺少共享库"的问题，我碰到过不少次。
为什么会缺库？因为/opt下的软件是自包含的，但它不可能把所有系统库都打包进去，通常只带了自己特有的库；而类似libxcb-keysyms这样比较底层的X11图形库，往往依赖系统环境提供。当这个库不存在时，动态链接器就找不到符号，程序自然起不来。
排查步骤通常是这样：
ldd /opt/todesk/bin/todesk | grep "not found"ldd会列出程序依赖的所有动态库，并标出哪些找不到。如果确实缺libxcb-keysyms.so.1，一般是装图形库相关的系统包。在Debian/Ubuntu上可能是libxcb-keysyms1，在CentOS/RHEL上可能是libxcb-keysyms1或xcb-util-keysyms。
如果装完还是找不到，可能是库文件存在但路径不在动态链接器的搜索路径里，可以用LD_LIBRARY_PATH临时指定：
export LD_LIBRARY_PATH=/opt/todesk/lib:$LD_LIBRARY_PATH /opt/todesk/bin/todesk但这种方式只对当前Shell有效，更稳妥的做法是把库路径写入/etc/ld.so.conf.d/下的一个配置文件，然后执行ldconfig刷新缓存。
/opt软件还有一个常见坑是权限问题。有的软件安装到/opt后，子目录权限不够，普通用户没法写日志或缓存目录。这种情况要么给对应目录加上合适的写权限，要么以root运行（不推荐，除非软件就是设计为root运行的）。总之，/opt下的问题，第一反应应该是看ldd和文件和属主权限，而不是急着重装。
5.3 案例三：MySQL的pid文件报错——指向/opt的路径问题
热搜里还有一条很典型的：Starting MySQL... ERROR! The server quit without updating PID file (/opt/mysql/mysql.pid)。
这个问题几乎每个用MySQL的人都会遇到。它说的是：MySQL启动时，应该把自己的进程号（PID）写入/opt/mysql/mysql.pid这个文件，但这个写入动作失败了，所以启动流程直接中止。为什么写不进去？常见原因有三类。
一是目录权限和属主不对。/opt/mysql这个目录可能是root所有，而MySQL服务以mysql用户运行，mysql用户没有在该目录下创建文件的权限。解决方法是把目录属主改成mysql：
chown -R mysql:mysql /opt/mysql二是PID文件已经存在且内容指向一个不存在的进程。比如MySQL之前没有正常关闭，留下了陈旧的PID文件。这种情况删掉旧PID文件再启动即可：
rm -f /opt/mysql/mysql.pid systemctl start mysqld三是磁盘空间满了。PID文件写入本质上就是一个很小的文件创建操作，如果所在分区满了，一样会失败。用df -h /opt看一眼便知。
这个案例其实很能说明问题：当你手动把软件放在/opt下时，就要自己管理好目录权限和依赖，这跟系统包管理器自动帮你处理一切是完全不同的体验。/opt给你的自由度，是用更多的手动维护换来的。
5.4 案例四：野生的漫游用户目录——误删与误改的补救思路
还有一个我几乎每年都会遇到的事情：有人把/home目录当临时文件夹，随便放了一堆大文件，某天磁盘满了，又不敢乱删，最后找我帮忙。或者更糟，直接执行了rm -rf /home/用户名，然后发现里面有一个还没交的论文或者还没备份的数据库。
针对误删，第一原则是：立刻停止对这块分区的一切写操作。因为Linux下删除文件不算难，恢复才难。如果分区还是原来的状态，可以尝试用extundelete、testdisk等工具扫描恢复（前提是文件系统类型是ext3/ext4，且没有被覆盖）。如果是XFS，恢复工具相对少一些。如果是SSD且开启了TRIM，恢复基本没戏——所以永远把备份当作最后兜底，而不是指望恢复工具。
针对磁盘被塞满，我的建议是建立一套"目录巡检"习惯。每周看一眼：
du -xh /home 2>/dev/null | sort -rh | head -20-x参数让du不跨文件系统统计，避免把挂在/home下的其他磁盘也算进来。哪个目录异常膨胀，一眼就能看出来。同时配合日志轮转（logrotate）和缓存清理策略，让磁盘空间问题“防患于未然”。
6. 排查问题时的"位置直觉"：从目录出发快速定位故障源
很多运维老手之所以排查速度快，并不是因为记了几百个命令，而是有一种"位置直觉"。拿到一个问题，先判断它属于哪个目录的职责范围，再对症下手。
比如，一个用户反映"我登录不了图形界面了"。你的第一反应应该是：先看/home/用户名目录是否存在、权限是否正常、磁盘是否满了。因为登录过程需要写/home/用户名下的.Xauthority、.cache等文件，如果目录权限异常或空间不足，登录就会失败。热搜词里那条/usr/bin/xauth: error in locking authority file /home/sunrise/.xauthority，就是典型的家目录权限异常导致X认证文件无法锁定的故障。
再比如，系统启动时报DNS解析异常。第一反应应该是看/etc/resolv.conf——这里面配置着DNS服务器地址。如果在公司内网环境，还可能是/etc/nsswitch.conf里hosts那行的查找顺序问题。所谓"配置在/etc，问题在运行"，排查时优先检查配置是否被改动过，比如比较最近是否有软件安装或系统更新覆盖了配置。
再比如，某个程序"装了一直没找到它在哪"。你在/usr/bin下没找到，whereis输出也模糊，那就去/opt、/usr/local这些第三方软件目录翻一翻。很多人喜欢把自定义编译的软件装在/usr/local，而/opt则更多是官方二进制包和应用商店类工具的地盘；这两个目录可以说是"非标准安装"的大本营。
拿到一个故障，先判断"这属于用户数据、系统配置还是独立软件"的问题，自然就能缩小排查范围。这种"位置直觉"说白了就是对目录职责的肌肉记忆，练出来了，排查效率会提升一大截。
7. 一些文档里不会细说的经验
最后分享几条我这些年实际操作中总结出来的经验，未必成体系，但每条都是踩坑踩出来的。
第一，/etc和/home下都有太多点开头的隐藏文件，不要用"人肉翻"的方式找配置。用grep -r直接搜内容往往更快。比如你想知道某个服务把日志写到哪了，直接：
grep -r "log" /etc/服务名/或者干脆用find /etc -name "*.conf" | xargs grep "关键字"。好习惯是：改配置之前先grep一下，确认当前配置里有没有你要改的项，避免重复添加导致配置冲突。
第二，不要把/opt下的软件目录当备份盘。很多软件的配置文件在/opt/软件名/etc或/opt/软件名/config下，如果你重装这个软件，整个目录被清理掉，配置也没了。所以重要配置一定要拷到/etc或单独的备份目录里管理，并用符号链接指过去。比如：
mv /opt/myapp/config /etc/myapp_config ln -s /etc/myapp_config /opt/myapp/config这样升级软件时配置不会跟着被清掉。
第三，对/home的软链接要格外小心。有些用户图方便，把/home/用户名/Download软链接到一个大盘目录，这本身没问题。但如果你用rm -rf /home/用户名清理账户，注意别在没搞清楚链接指向的情况下直接误删了目标目录里的数据。rm -rf碰到软链接时，行为可能跟你预期不一样——它删的是链接本身，不会递归删目标目录里的内容，但加了/后缀等情况会有例外，所以清理目录前先ls -l确认有没有软链接，再用find -type l扫一遍。
第四，定期检查/etc下的文件有没有被程序自动改写。云平台的初始化脚本、容器编排工具、甚至某些杀毒软件都可能修改/etc下的配置。像resolv.conf这种，被NetworkManager或systemd-resolved重写是常有的事。如果你手动改了又不想被覆盖，要么用chattr +i给文件加不可变属性：
chattr +i /etc/resolv.conf要么把自定义配置写入系统提供"自定义片段"目录中（如果有）。chattr +i虽然好用，但改完记得让它保持可控，不然之后你想改回来还要先chattr -i，容易在紧急情况下又多一步操作。
第五，不要轻易用chmod -R 777来"解决"权限问题。这是个看起来很聪明其实很危险的习惯。777意味着任何用户都能读写和执行，整个系统的安全边界就形同虚设了。遇到权限问题，正确的做法是精确地找到"哪个用户需要什么权限"，然后最小化授权。比如用户需要写某个目录，那就把目录属主改成该用户，或者把用户加入目录所属的组，而不是直接把权限放开到全世界。
8. 绕不开的"根目录整盘规划"话题
聊到/home、/etc、/opt，就不能不提分区规划，因为这直接决定了未来几年你操不操心"盘满了"的问题。
我比较推荐的Linux桌面或服务器分区方案是：根目录/给足够空间，/home单独分区，/opt、/var、/tmp视情况单独挂载或使用独立磁盘。好处是：
<span dir="ltr">/home独立：用户数据跟系统隔离，重装系统时保留/home即可保住用户文件。/opt独立：第三方软件占用的空间不会挤占根分区。/var独立：日志、缓存这类会不停增长的东西不会直接把根分区塞爆。/tmp独立：临时文件不会造成根分区压力。
这个方案的代价是要提前规划磁盘空间大小，尤其是/opt如果装大型软件会膨胀得比较快，需要在早期留出余量。如果不愿意搞得太细，那至少做到"/home单独分区"，这是性价比最高的一个隔离。
如果服务器用的是LVM，那空间规划就灵活很多，随时可以扩。不过要注意，LVM的快照和扩容操作，一定要在业务低峰期进行，并且先确认文件系统是resize2fs（ext系列）还是xfs_growfs（XFS）能在线扩展，不同文件系统支持在线扩容的能力不同，搞错了可能直接导致数据损坏。
9. 给新手的"目录速查"工具感
如果你刚开始用Linux，想很快建立起对这三个目录的熟悉感，我建议你做个很简单的练习。
打开终端，逐条执行下面这些命令，把输出和文件结构对照着看：
ls -lah /home # 看看有哪些用户目录，各自大小如何 ls -lah /etc/passwd /etc/shadow # 看看系统用户配置 tree -L 1 /opt # 看看装了哪些第三方软件 df -h / /home /opt /etc # 看看这几个路径挂在哪个分区、还剩多少空间多执行几遍，你会慢慢形成一种"噢，原来我的每个操作都在跟某个具体的目录打交道"的感觉。这种感觉，比背十遍目录结构说明都管用。
我建议你在自己机器上建一个测试用户，试着：
- 用
useradd新建一个用户，看/home下发生了什么； - 切到该用户，修改
.bashrc，重启Shell，看配置是否生效； - 把一个软件包手动解压到
/opt，写一个启动脚本，理解"自包含软件"的含义。
这三个小操作做完，你就已经从"知识"层面跨入"经验"层面了。后面再碰到目录相关的问题，至少不会再是"完全没有抓手"的状态。
我个人在实际操作中的体会是：Linux的目录规范之所以能几十年不变，核心在于它把"谁的数据、谁的配置、谁的程序"分得清清楚楚。你不需要把每个目录都背下来，但你要能用这套"职责分离"的思维去理解新的目录、新的软件、新的系统。真正值钱的经验不是记住命令，而是遇到问题的时候，能根据"它属于哪类文件"快速找到该去哪个目录下手排查。
