刚接手一台别人的服务器第一件事我通常不是看服务跑没跑而是敲一个ls -l /和df -h先看目录树长什么样、哪个分区快满了。原因很直接Linux 里所有东西——配置、日志、用户数据、程序本体、甚至内核暴露出来的运行状态——最终都以文件的形式挂在同一棵以/为根的目录树上。你如果不知道哪个目录该放什么就一定会出现日志写到系统目录里系统一升级全被覆盖数据盘挂在/root下面别人一看就懵备份脚本只能整盘备份费时费钱还漏东西这类问题。这篇内容就是围绕 Linux 目录结构从头到尾讲清楚FHS 标准到底规定了什么、每个一级目录真实用途是什么、一个 Java Web 项目在 Linux 上应该怎么落位、磁盘满了该从哪查、以及我在实际运维里踩过的那些坑。无论你是刚开始学 Linux 命令的新手还是带了几年业务系统的运维和开发看完都能直接拿去用。1. 先弄明白 Linux 目录结构的设计逻辑很多人背目录表背得很熟/etc放配置、/var放日志、/home放用户数据一问为什么就答不上来。但这套东西之所以值得花时间理解恰恰是因为它背后有一套非常一致的设计取舍理解了取舍你自然就记住了规则而不是靠死记硬背。1.1 单根目录树为什么 Linux 没有 C 盘和 D 盘Windows 用户换到 Linux 最不习惯的一点就是找不到盘。Windows 里每块硬盘分一个盘符C:、D:、E:各自独立Linux 只有一棵树根是/所有磁盘、分区、U 盘、网络存储都被挂到这棵树的某个目录下面这个动作叫挂载mount。这个设计带来的最大好处是路径唯一且可预测。无论你插了几块盘、换了什么硬盘型号某个服务的配置文件永远是/etc/服务名/xxx.conf日志永远是/var/log/xxx.log。写脚本、写部署工具、写监控采集的人不需要知道底层硬件的差异只要约定好路径就行。反过来如果每台机器的盘符结构都要靠人记住自动化基本没法做。另一个好处是权限模型统一。既然是同一棵树那么每个文件、每个目录都可以用同一套属主 属组 其他的权限位来描述不需要按盘符单独设计一套权限体系。你后面会看到目录权限和用户组配合是 Linux 里隔离不同业务、不同团队最常用的手段比虚拟机、容器都轻。物理磁盘和目录树是两回事这点一定要分清。/是一个逻辑位置它背后可能是整块盘的一个分区也可能只是某个 LVM 逻辑卷。你用df -h看到的是挂载点 使用的文件系统用lsblk看到的是块设备 挂载点这两条命令才是排查磁盘问题时真正该看的而不是盯着目录名猜。1.2 FHS 标准一份目录该放什么的公约FHS全称 Filesystem Hierarchy Standard中文一般叫文件系统层次结构标准。它不是内核强制的规则而是一份大家共同遵守的约定主流发行版基本都按它来组织目录。它把目录大致分成几类分类含义典型目录静态、可共享装完就不怎么变多机可以共用同一份/usr、/opt静态、不可共享与本机强绑定不能跨机器共用/etc、/boot动态、可共享运行时变化但可以跨机器共享/srv、部分/var子目录动态、不可共享运行时变化且与本机强相关/var/log、/var/run、/tmp这张表看着抽象实际用途很明确它告诉你哪些目录适合做备份、哪些适合做镜像、哪些绝对不能共享。比如你把/etc目录直接拷贝到另一台机器上机器名、网卡名、密钥全对不上服务起不来而你把/usr整个目录 rsync 到另一台同版本的机器上一般没毛病。FHS 还规定了一件事根目录/应该尽量小不要塞业务数据。原因在于根分区一旦满系统会出各种诡异问题——日志写不进去、/var/run建不了进程文件、新用户登录都失败。很多发行版在安装时会把/、/boot、/var、/home分到不同分区就是这个道理。1.3 现代发行版对 FHS 的改良你得心里有数严格按 FHS 走的是理想状态实际发行版多少都有变化不知道这些差异很容易踩坑。最典型的是/bin、/sbin、/lib向/usr的合并业内叫 usrmerge。早期设计里/bin是系统启动时就需要的最小命令集必须和/usr分开因为/usr可能挂在独立分区上、启动早期还没挂载。现在这个理由基本消失了于是 Fedora、Ubuntu、Arch 等陆续把/bin做成指向/usr/bin的软链接。你在这些系统上敲ls -l /bin会看到它是- usr/bin。RHEL 系列较新的版本也跟上了。另一类是发行版自己加的目录。Debian、Ubuntu 上有/snap专门放 snap 包有的系统有/run替代老的/var/run因为/var可能挂载较晚而/run是 tmpfs启动早期就可用。容器镜像里的目录结构更精简很多时候只有/bin、/lib、/etc和业务目录别拿物理机的经验硬套。我个人的建议是写自动化脚本时尽量用命令而非硬编码路径。比如不要写死/bin/systemctl直接写systemctl让 shell 去 PATH 里找需要判断系统类型时看/etc/os-release这个文件在主流发行版上都存在比猜/etc/redhat-release是否在靠谱得多。2. 一级目录逐个拆解每个目录到底该放什么这一章我把常见的一级目录分成几组来讲每组讲清楚用途、里面通常有什么、以及容易混淆的地方。看完之后你ls /一眼过去心里应该能立刻有个判断这个目录该不该动、该不该备份、满了会出什么事。2.1/bin、/sbin、/lib、/usr命令到底藏在哪先说结论普通用户敲的命令绝大多数在/usr/bin和/bin里管理员命令在/usr/sbin和/sbin里命令依赖的动态库在/usr/lib和/lib里。在已经 usrmerge 的系统上这几对其实是同一个目录/bin就是/usr/bin的软链。/usr是整个系统里体积最大的一块它的名字是 Unix System Resources 的缩写不是 user 的意思这点很多人误解。它里面通常有/usr/bin普通可执行程序ls、grep、python3、java都在这/usr/sbin管理员程序useradd、fdisk、sshd之类/usr/lib程序依赖的共享库和内部模块/usr/local管理员自己编译安装的软件默认前缀就是这里编译时的./configure --prefix/usr/local/xxx装完就在这/usr/share与架构无关的共享数据比如/usr/share/fonts字体、/usr/share/doc文档、/usr/share/man手册页/usr/includeC 头文件编译时要找这里有个实际选择经常让人纠结自己装的第三方软件到底放/usr/local还是/opt我的判断标准是——源码编译、遵循 Linux 目录习惯、需要和其他命令一起在 PATH 里的放/usr/local厂商打包好的整包商业软件、自带一堆文件、彼此独立的比如某些输入法、浏览器、JDK 发行版放/opt。/opt的设计意图就是可选软件包每个软件在下面占一个独立子目录删的时候整个删掉不会污染系统目录。关于/lib和内核模块有一点值得知道内核模块放在/lib/modules/$(uname -r)/下面$(uname -r)是当前内核版本号。所以每次升级内核都会多出一个版本目录老目录不会自动删时间长了/boot和/lib/modules能吃掉几个 G。清理的时候只保留当前和上一两个版本就行别全删否则回滚都没得回。2.2/etc配置文件的大本营也是最容易搞乱的地方/etc是整套目录结构里最需要小心对待的地方因为它是不可共享的静态配置。这里放的都是纯文本配置理论上不应该出现二进制程序也不应该出现大体积数据。几个你必须认识的配置文件/etc/passwd、/etc/shadow、/etc/group用户和组useradd、passwd改的就是它们/etc/fstab开机自动挂载的配置写错会导致系统进不去紧急模式/etc/hosts本地域名解析优先级高于 DNS/etc/resolv.confDNS 服务器地址这个文件经常被 NetworkManager 或 cloud-init 覆盖手动改完重启就没了/etc/ssh/sshd_configSSH 服务配置/etc/systemd/system/自己写的 systemd 服务单元放这里关于/etc/resolv.conf被覆盖这个坑我踩过不止一次。现象是手动加了一行nameserver重启或者网络重连之后消失了。原因是它由上层网络管理工具生成。正确的做法是改生成它的源头NetworkManager 管理的系统用nmcli配置cloud-init 管理的实例改/etc/cloud/cloud.cfg或者把文件设成不可变属性。盲目chattr i能顶一阵但网络配置一变就会互相打架不是长久方案。另外要区分/etc/sysconfig和/etc/default。前者是 RHEL 系的习惯后者是 Debian 系的习惯同一个软件在两套系统上的配置路径经常不一样。写跨发行版的部署脚本时别假设路径一样先判断发行版再决定读哪个文件。还有一个常被忽略的原则不要把业务配置放在/etc的软件目录里手改因为包管理器升级软件时可能提示是否覆盖配置。规范做法是把自己改的那份放在/etc下独立的、包管理器不认识的目录里或者用软件支持的conf.d形式追加。2.3/var会一直长胖的目录磁盘报警第一名如果说/usr是体积最大那/var就是增长速度最快。它的名字是 variable 的缩写放的就是运行时变化的那些数据。磁盘使用率突然飙升的排查十次有八次最后定位到/var。拆开来看/var/log系统和服务日志messages、syslog、secure、各种服务的日志都在这里是增长的绝对主力/var/lib程序运行需要的持久化状态数据比如数据库的数据目录MySQL 默认在/var/lib/mysql、容器运行时数据/var/cache缓存包管理器下载的安装包、应用缓存理论上可以清清了会重新生成/var/spool排队等待处理的数据打印队列、邮件队列、定时任务/var/run现在通常是/run的软链接放 PID 文件和 socket重启即清空这里有个非常实用的经验日志目录最好单独规划。原因有两个一是日志增长不可控二是日志写满分区会连带把同一分区上的其他数据搞挂。如果/var和/在同一个分区/var/log一满整个系统都会异常新进程起不来SSH 都可能连不上。所以生产机上我一般至少保证/var独立或者把应用日志统一指到一个独立的/data/log分区上。/var/cache的清理要谨慎。清apt或yum的缓存包很安全但有些程序的缓存清掉之后重建成本很高比如某些索引型应用的缓存目录。动手之前先看一眼里面是什么du -sh /var/cache/*按大小排一下再决定。2.4/home、/root、/tmp、/srv、/mnt、/media用户数据与临时空间这一组目录各自的分工非常清楚混用会带来实际麻烦。/home是普通用户的家目录/home/用户名。用户自己的配置、下载、代码都在这。多用户服务器上/home通常独立分区因为用户数据增长不确定而且重装系统时可以保留。/root是 root 用户的家目录注意它是根目录下的一级目录不是/home/root。这点新手经常搞错。/root权限一般是 700只有 root 能进。我个人的习惯是/root里只放运维脚本和临时排查文件不放业务数据避免误操作和数据丢失。/tmp是全局临时目录所有用户都能写所以它的权限位是 1777也就是rwxrwxrwt最后那个t是粘滞位sticky bit。粘滞位的作用是目录里任何人可以创建文件但只有文件属主、目录属主和 root 能删除。没有它的话任何用户都能删掉别人放在/tmp的文件多用户环境直接崩。很多系统还会挂 tmpfs 到/tmp重启就清空好处是快、不落盘坏处是重启后文件没了——如果某个程序把重要中间文件放这里重启就丢数据。/opt前面讲过放第三方整包软件。/srv按 FHS 是放本机对外提供的服务数据比如网站内容、FTP 数据。实际用的人不多。/mnt和/media都是挂载点区别是习惯用法/mnt一般给管理员临时手动挂载用/media给系统自动挂载可移动设备用比如插个 U 盘会自动挂到/media/用户名/卷标。这个习惯并不是强制的但遵守它能避免到底哪个目录里是我的数据盘这种混乱。2.5/proc、/sys、/dev看着像目录其实是内核窗口这三个目录有个共同特点它们不占磁盘空间内容是内存里的东西用来和内核对话。很多人第一次看到/proc里一堆数字命名的目录会懵其实那些数字就是进程 PID。/proc里几个常用文件值得记住/proc/cpuinfoCPU 信息/proc/meminfo内存详情比free给的更全/proc/loadavg系统负载/proc/mounts当前所有挂载点比mount命令输出更原始/proc/PID/某个进程的详细信息比如fd目录能看到它打开了哪些文件cwd是它的工作目录软链排查这个进程到底在读哪个配置特别好用/sys主要暴露设备和内核子系统信息比如/sys/class/net/下面是所有网卡调网络参数、看硬件状态会用到。/dev是设备文件/dev/sda是硬盘/dev/null是黑洞/dev/zero是零流。这三个目录的实操要点是别删、别备份、别往里写数据。备份脚本一定要注意排除它们否则tar一路上会碰到设备文件和无限数据流卡死或者报一堆错。tar参数里加上--exclude/proc、--exclude/sys、--exclude/dev是最基本的。为了便于速查把上面几节的结论整理成一张表目录放什么能不能清能不能跨机共享建议独立分区/usr程序、库、共享数据不能随意清同版本可以可独立/etc配置文件不能不可以否/var/log日志按策略轮转不共享本机日志强烈建议/var/lib程序状态数据不能不可以视情况/tmp临时文件可以不可以可 tmpfs/home用户数据不能不可以建议/opt第三方软件不能可以视情况/proc/sys/dev内核接口不要动不可以不适用3. 实操把一个 Java Web 项目规范地落到目录里道理讲完了来看一个真实场景。假设我们要在一台 Linux 服务器上部署一个 Java Web 项目用 systemd 管理日志要能被轮转数据要和程序分开。这套目录规划思路其实适用于绝大多数后端服务不限于 Java。3.1 目录规划程序、配置、数据、日志四分法我的基本原则是四分离程序本体、配置文件、数据、日志各占一处谁都不和谁混。类型路径理由程序/opt/myapp/app整包软件升级时整个替换配置/etc/myapp符合系统约定便于统一管理数据/data/myapp单独分区便于扩容和备份日志/data/log/myapp和系统日志分离防止互相拖累为什么程序放/opt/myapp/app而不是直接/opt/myapp因为/opt/myapp下面还要放app、releases、backup等子目录把可执行部分单独放一层升级时用软链接切换版本回滚只需改软链指向秒级完成。这是我在实际项目里最常用的一套发布方式。为什么配置要放/etc/myapp而不是程序目录里因为程序目录在升级时经常整体替换配置如果在里面每次升级都得单独保留很容易被覆盖。放到/etc之后升级程序不动配置干净利落。3.2 建用户、建目录、配权限的完整操作服务不应该用 root 跑这是底线。先建一个专用系统用户# -r 表示系统用户不创建家目录也不让登录 sudo useradd -r -s /sbin/nologin -M myapp # 建一个专门的组方便后续按组授权 sudo groupadd myappgrp sudo usermod -aG myappgrp myapp-s /sbin/nologin很关键它让这个账号只能被服务进程使用无法交互登录减少了被滥用的可能。-M是不创建家目录因为服务账号不需要。接着建目录并设置权限sudo mkdir -p /opt/myapp/{app,releases,backup} sudo mkdir -p /etc/myapp /data/myapp /data/log/myapp # 程序目录属主是部署账号服务账号只读 sudo chown -R deploy:myappgrp /opt/myapp sudo chmod -R 750 /opt/myapp # 配置目录服务账号能读部署账号能写 sudo chown -R deploy:myappgrp /etc/myapp sudo chmod 750 /etc/myapp sudo chmod 640 /etc/myapp/*.conf 2/dev/null # 数据目录服务账号读写 sudo chown -R myapp:myappgrp /data/myapp sudo chmod 750 /data/myapp # 日志目录服务账号写组内可读 sudo chown -R myapp:myappgrp /data/log/myapp sudo chmod 750 /data/log/myapp这里解释一下权限数字的选择不然容易照抄出错。目录权限750等于属主rwx、属组r-x、其他无权限。为什么目录要有x因为目录的x位代表能否进入和穿越没有x就算有r也进不去只能看到文件名。所以目录权限设计时x一定要想清楚给谁。为什么不是755因为755意味着其他所有用户都能读目录内容配置和数据目录没必要开放给所有人750已经把组内协作覆盖了。文件权限640是属主读写、属组只读、其他无权限。配置文件里经常有数据库密码644会让其他用户也能读属于典型的低级失误。只要文件里有凭据一律600或640这个习惯要养成。3.3 分区与挂载让/data真正独立目录建好了但如果/data和/在同一个分区那独立只是名义上的。查一下df -h /data /var /home lsblk -f如果发现/data只是根分区上的一个普通目录就得挂一块盘上去。假设新盘是/dev/sdb操作大致如下# 分区 sudo parted /dev/sdb mklabel gpt sudo parted /dev/sdb mkpart primary xfs 0% 100% # 格式化 sudo mkfs.xfs /dev/sdb1 # 查看 UUID比设备名稳定 sudo blkid /dev/sdb1 # 写入 fstab实现开机自动挂载 echo UUID你的UUID /data xfs defaults,noatime 0 0 | sudo tee -a /etc/fstab # 先验证再挂载避免写错导致开机失败 sudo mount -a df -h /datafstab这一行有几个要点必须说清楚。第一用 UUID 不用设备名因为设备名会变加块盘之后/dev/sdb可能变成/dev/sdc用设备名挂载会导致开机挂错甚至进不去系统。第二mount -a是验证命令写完 fstab 一定要先跑它报错就赶紧改否则重启后系统进紧急模式只能去控制台救。第三noatime是个小优化表示不记录文件访问时间能减少大量写操作对读写频繁的数据盘有实际收益。注意修改/etc/fstab前先备份一份cp /etc/fstab /etc/fstab.bak。这个文件写错的代价很高而备份的成本几乎为零。3.4 日志写入与轮转别让日志把盘撑爆目录规划的最后一步是日志。程序这边通常配置日志输出到/data/log/myapp/app.log具体方式取决于框架常见的是在配置文件里指定路径。然后是轮转用系统自带的 logrotate 就够了。在/etc/logrotate.d/下建一个文件比如/etc/logrotate.d/myapp/data/log/myapp/*.log { daily rotate 14 missingok notifempty compress delaycompress copytruncate create 640 myapp myappgrp }逐条解释一下这些参数直接影响线上表现。daily是每天轮转一次日志量大的服务可以改size 100M按大小触发。rotate 14是保留 14 份历史加上当前共 15 天按需调整。missingok表示日志文件不存在不报错避免服务没起来时 logrotate 天天发告警。notifempty是空文件不轮转。compress压缩历史日志能省大量空间。delaycompress让最近一份不压缩因为有的程序还在往里写。copytruncate这个参数值得单独说。默认情况下 logrotate 是重命名旧文件、然后通知程序重新打开日志文件。但很多 Java 应用不响应这个信号重命名后它还在往老文件描述符写结果新文件一直是空的日志消失了。copytruncate的做法是先复制一份再清空原文件程序描述符不变简单粗暴但有效。代价是复制瞬间可能丢极少量日志。实际项目中这个参数救过我好几次。配好之后一定要测试不要等到第二天才发现没生效# -d 是 dry run只打印不执行先看一遍它会做什么 sudo logrotate -d /etc/logrotate.d/myapp # 确认无误后强制跑一次 sudo logrotate -f /etc/logrotate.d/myapp ls -lh /data/log/myapp/4. 常见问题与排查技巧实录目录结构的问题最终都会以磁盘满了找不到文件权限不够这几种形式爆发。这一章整理几个高频场景的排查动作都是可以直接照着敲的。4.1 磁盘满了df和du的标准组合拳报警说磁盘使用率 95%第一步永远是df -hdf -h df -i注意df -i是看 inode 使用率。有一种情况是空间没满但 inode 满了现象同样是写不进文件报 No space left on device但df -h显示还有空间。这通常是小文件太多造成的比如某个 session 目录下堆积了几十万个碎文件。这种情况只能找到目录删文件加空间没用。确认是哪个挂载点满了之后从该挂载点往下逐层找# 看根目录下每个一级目录占多大按大小排序 sudo du -sh /* 2/dev/null | sort -rh | head -10 # 锁定到具体目录后继续往下钻 sudo du -sh /var/* 2/dev/null | sort -rh | head -10 sudo du -sh /var/log/* 2/dev/null | sort -rh | head -10sort -rh的-h是让人类可读的大小比如 1.2G、300M也能正确排序这个参数很关键不加的话会按字符串排结果完全不对。还有一个必查项被删除但没释放的文件。程序删了日志文件但进程还持有文件描述符空间就不会释放du也看不到。判断方法是sudo lsof | grep deleted | head -20 # 或者看某个分区 sudo lsof L1如果确认有这种情况重启对应进程即可释放。这也是为什么日志轮转要配copytruncate或者让程序正确响应信号。4.2 根分区不够用几种务实的解法根分区偏小是很多云主机镜像的通病二十几 G 的盘跑一阵就见底。我的处理顺序是这样的先清理确定安全的东西包管理器缓存yum clean all或apt clean、旧内核保留当前和上一版、/var/log里的历史归档日志、/tmp里的大文件。这几项通常能救回几个 G。然后看有没有可以搬走的大目录。比如数据库数据在/var/lib/mysql如果数据盘还有空间可以把它迁到/data/mysql然后在原位置建软链接。这种方式对上层程序透明不用改配置但要注意权限和 SELinux 上下文如果有开的话需要restorecon。最后才是扩盘。云主机一般支持在线扩容云盘扩完还得扩文件系统xfs_growfs或resize2fs只扩云盘不扩文件系统是白忙一场这个坑新手特别容易踩。提示清理/var/log时不要直接rm -f正在被写的日志文件用truncate -s 0 文件名或者: 文件名更稳妥前者清空内容但保留 inode 和权限程序继续正常写。4.3 文件名和路径里的那些坑整理东西的过程中还有几类文件层面的问题经常出现跟目录结构强相关。解压之后文件名全是乱码。这是压缩文件里用了非 UTF-8 编码保存文件名导致的。unzip默认按当前 locale 解读遇到中文名就花。处理方式有两种一是解压时指定编码二是换用能自动识别的工具。前提是先确认系统 locale 支持中文用locale看一下如果LANG是C或POSIX很多中文相关的行为都会异常先把它设成合适的值比如zh_CN.UTF-8或至少en_US.UTF-8会顺带解决一批显示问题。路径里有空格或特殊字符脚本里不加引号就会出错。一条铁律变量引用路径永远加双引号写$DIR而不是$DIR。文件名里带-开头的前面加./或者用--分隔参数。大小写敏感。Linux 区分大小写Config.json和config.json是两个文件。从其他系统迁过来的项目最容易在这里翻车本地能跑服务器上就说找不到文件。养成统一命名习惯配置一律小写下划线或小写连字符能省很多事。4.4 常见问题速查表现象可能原因快速定位命令写入报 No space分区满df -h写入报 No space 但空间够inode 满df -i、find /path -type f | wc -l删了文件空间没释放进程持有描述符lsof | grep deleted磁盘占用对不上挂载点被覆盖df -h对比du -sh结果找不到刚放的文件路径大小写、软链、命名空间ls -l、readlink -f手动改的配置重启失效被上层工具覆盖查/etc/resolv.conf是否软链、看生成工具服务起不来报权限拒绝目录缺少x位namei -l /path/to/file日志没滚动程序不响应信号检查 logrotate 是否配copytruncatenamei -l这条命令特别值得记住它会逐级列出路径上每个目录的权限一眼就能看出是哪一层缺了x或r。比一层层ls -ld快得多排查权限问题我基本都先用它。5. 几年下来我踩过的坑和形成的习惯写到这里该讲的标准、目录、实操都讲了最后聊几个具体经验都是花了代价换来的。5.1 系统目录一定不要手工往里放东西/usr、/bin、/lib、/etc这些目录归包管理器管。往里手工丢文件有两个后果一是升级时可能被清理掉服务哪天突然找不到依赖二是包管理器校验文件完整性时对不上排查起来一头雾水。正确做法是新东西一律往三个地方放/usr/local、/opt、/data。前者是自己编译的中间是整包第三方软件后者是数据。这三个位置包管理器不管你想怎么折腾都行。还有一个相关的坑不要随便改系统自带脚本比如/etc/init.d里的东西或者/usr/lib/systemd/system下的单元文件。要覆盖服务配置用自己的片段文件或者在/etc/systemd/system下放同名单元覆盖。这样原文件保持干净升级不冲突。5.2 目录规范最好在项目第一天就定下来这点我体会太深了。项目初期随手建目录程序放/root数据放/home日志写/tmp能跑起来就行。等业务长了半年要扩容、要备份、要迁移、要交接每个动作都要重新梳理一遍东西到底在哪成本比一开始花半小时规划高几十倍。我的做法是每个项目落地前写一份很短的目录说明就几行程序在哪、配置在哪、数据在哪、日志在哪、备份在哪、用哪个用户跑。贴在项目文档最前面。不管后面换谁接手看一眼就知道全貌。这个成本极低收益极高。另外强烈建议程序目录用版本目录 软链的方式。/opt/myapp/releases/20240601放这一版的可执行文件/opt/myapp/app是个软链指过去。发新版就建新目录、测通、改软链回滚就改回来。全程秒级不需要重新解压包也不会有删除正在运行的程序这种尴尬Linux 上删了文件只要进程没退文件还在但新起的进程就找不到文件了这个特性用错很麻烦。5.3 几个顺手的小技巧平时操作里有几个习惯帮我省了不少时间。cd的时候多用cd -回到上一个目录比敲完整路径快。查看目录结构用tree -L 2比一层层ls直观没装的话用find . -maxdepth 2 -type d也能凑合。找大文件用find /data -type f -size 500M -exec ls -lh {} \;比满目录翻快。写脚本处理目录时第一行永远加set -euo pipefail这样出错就停、未定义变量报错、管道中任一环节失败都能被发现能挡住大量脚本跑完一半出错了但还继续执行的事故。还有一个容易被忽视的点软链接的路径问题。用ln -s建链接时目标和链接的实际解析方式容易搞混尤其是跨目录的时候。有个简单的办法建完用readlink -f 链接名看它最终指向哪里确认无误再去用。生产环境里因为软链指错目录导致日志写丢、配置读错的情况我见过不止一次。最后分享一个我自己一直在用的判断标准接到一台新机器花两分钟敲df -h、lsblk、ls -l /、cat /etc/os-release这四条命令基本就能知道这台机器能不能直接上业务。磁盘怎么分的、是什么发行版、目录有没有被前人改乱一眼就清楚了。这四条比我见过的任何检查清单都实用。