1. 目录管理基础

说白了，目录结构就是一套组织文件的「架子」。你想想看，一个系统里成千上万个文件，如果没有目录把它们分门别类放好，那跟把书全堆在地上有什么区别？

我个人习惯把目录结构比作一棵倒着长的树。根目录是树根，子目录是树枝，文件就是树叶。这个比喻虽然老套，但确实很形象。

举个例子，一个典型的 Linux 系统目录长这样：

/
├── bin/        # 用户命令
├── etc/        # 配置文件
├── home/       # 用户家目录
├── var/        # 可变数据
├── tmp/        # 临时文件
└── usr/        # 用户程序

嗯，这里要注意：目录本身不存数据，它只负责「指路」。就像门牌号不决定房子里住什么人，但它能帮你找到人。

我在项目中遇到过好几次这样的场景：新来的同事把脚本随便扔在 /tmp 下，结果系统一重启，脚本全没了。这就是典型的目录管理混乱带来的问题。

管理目录的核心目的，我总结为三点：

我曾经踩过的坑： 有一次线上服务日志暴涨，我习惯性地去 /var/log 下找，结果找了半天没找到。后来发现运维把日志路径改到了 /opt/app/logs 下，但没更新文档。那次事故让我养成了一个习惯——任何目录变更必须同步更新文档。

你想想看，如果目录管理做得好，一个新人接手系统，光看目录结构就能猜出七八分业务逻辑。这就是管理的价值。

这个问题其实很关键。很多人把目录和文件系统混为一谈，其实它们是两个层面的东西。

概念	作用	类比
目录	组织文件的逻辑结构	书架上的分类标签
文件系统	管理存储空间的机制	书架本身的结构

目录是文件系统暴露给用户的「界面」。同一个文件系统下，你可以创建无数个目录。但反过来，一个目录也可以跨多个文件系统——通过挂载点实现。

我记得有一次做存储扩容，需要把新磁盘挂载到 /data 目录下。如果不懂目录和文件系统的关系，你可能会直接把数据拷过去，然后发现原来的路径全变了。正确的做法是：

# 先把数据挪走
mv /data /data_backup

# 创建空目录作为挂载点
mkdir /data

# 挂载新磁盘
mount /dev/sdb1 /data

# 把数据拷回来
cp -r /data_backup/* /data/

一个小技巧： 用 df -h 看的是文件系统使用情况，用 du -sh 看的是目录占用空间。这两个命令经常配合使用，帮你快速定位磁盘空间问题。

做了这么多年运维，我总结出几条目录管理的铁律：

说白了，目录管理不是什么高深的技术，但它体现了一个工程师的基本素养。我面试人的时候，经常会问：「你平时怎么组织你的项目目录？」从回答里基本能看出这个人做事有没有条理。

最后说一句：目录结构是系统的骨架。骨架歪了，肉长得再好也没用。所以，从一开始就把目录规划好，后面能省很多事。