随着技术的发展，一些经典的 Linux 命令由于架构落后，安全问题，能力难以支撑新场景，使用复杂等各种原因，正在在逐步退出历史，整个 Linux 生态这些年悄悄完成了一次技术演进。从查 DNS、传文件、定时任务到分区磁盘，网络排查等一整套命令体系都在悄悄迭代。这篇文章就把能查到的、有官方依据的命令变化和替代方案，系统梳理下，并附上具体场景和示例，以便查阅。

第一组：网络工具全家桶，ip 一个顶过去五个

先说网络这块，因为它是这次技术演进里改得最彻底的一块。ifconfig、netstat、arp、route、iwconfig 这几个曾经的常用命令，几乎全部来自同一个工具包：net-tools。这个包已经很多年没有实质性更新了，上一次重要发布还是在 2001 年，它的设计基于 ioctl 系统调用跟内核对话，简单粗暴，天花板很低。

ifconfig → ip addr / ip link

ifconfig 虽然能够显示 IPv6 地址，但对网络命名空间、策略路由、复杂接口管理等现代网络能力支持不足，而这些恰恰是容器技术的地基。你在物理机上用它查网卡还凑合，一旦上了 Docker、Kubernetes，它就有点跟不上趟了。而且语法东一榔头西一棒——查接口用 ifconfig，查路由又得换成 route，学起来没有章法。

替代它的 ip 命令来自 iproute2 工具包。这套工具更强大、更适合写脚本，输出也更一致，一条命令线就能覆盖接口、地址、路由、隧道等一整套配置。底层机制也换了：ip 走的是 netlink 套接字，支持内核主动向用户态推送变更消息（比如某张网卡掉线了立刻通知），而不是像 ioctl 那样只能靠轮询去问。这在管理成百上千张虚拟网卡的云环境里，差距是数量级的。

# 老命令：查看网卡信息
ifconfig eth0

# 新命令：效果等价，且支持更多现代特性
ip addr show eth0
# 简写
ip a

# 给网卡配 IP（老写法）
ifconfig eth0 192.168.1.100 netmask 255.255.255.0

# 新写法，用 CIDR 表示法，更简洁
ip addr add 192.168.1.100/24 dev eth0

Debian 系发行版从 2016 年底开始，默认安装已经不再包含 ifconfig 命令，除非你手动装 net-tools。Ubuntu 18.04 之后更是彻底不预装它了。

netstat → ss

排查端口占用、看连接状态，netstat 曾经是运维的口头禅——“敲个 netstat -an 看看”。但它有个先天短板：netstat 靠解析 /proc/net/ 下的文本文件来拿数据，连接数一多，速度就肉眼可见地慢下来。

ss（socket statistics）走的是不同的路子：netstat 主要通过读取 procfs 网络信息获取数据，而 ss 通过 Netlink 与内核通信，在打开了大量套接字的系统上效率更高。有人做过对比，在一台有一万多个连接的服务器上，两者的差距比较明显——这是架构层面的差异，而不是玄学。

命令几乎是平移过去的，学习成本极低：

netstat -tlnp   →   ss -tlnp   # 查监听端口及进程
netstat -at     →   ss -t      # 所有 TCP 连接
netstat -au     →   ss -u      # 所有 UDP 连接
netstat -l      →   ss -l      # 只看监听中的端口

有意思的是，ss 还能查到 netstat 压根拿不到的信息，比如某条 TCP 连接的拥塞窗口、往返时延这些内部状态，排查网络抖动特别好用。不过 netstat 也不是一无是处——它在 Windows 和 macOS 上原生可用，跨平台脚本还得靠它。

arp → ip neigh，route → ip route，iwconfig → iw

这三个是同一批使用场景减少的命令，逻辑跟 ifconfig 完全一致，这里合并说，免得重复啰嗦。

arp 命令用来管理系统的 ARP 缓存，被 ip neighbor（简写 ip n）取代；route 命令管理路由表，被 ip route 取代；iw 命令则接管了 iwconfig，用来查看和配置无线网卡，走的是 Netlink 公共接口，支持最新加入内核的驱动。

arp -a              →   ip neigh show
route -n            →   ip route show
iwconfig wlan0      →   iw dev wlan0 info

这几个工具有个共同的现实处境：即便官方已经不再积极维护，很多系统装上后依然能正常运行，只是不再是默认预装选项。如果你维护的是遗留系统，不用因为使用场景变少就立刻推翻重来；但新脚本、新自动化流程，直接用 ip 系列没有理由绕远路。

iptables → nftables：Linux 防火墙架构正在升级

如果说前面几个是"体力活"升级，iptables 到 nftables 的迁移，是一次思路上的重构。

iptables 里预置了 filter、nat 这些固定的表和 INPUT、FORWARD 这些固定的链，而且每条规则只能对应一个目标动作（比如 -j ACCEPT），规则一多，管理起来就是一锅意大利面。更麻烦的是，IPv4、IPv6、ARP、网桥过滤各有一套独立工具（iptables、ip6tables、arptables、ebtables），维护成本翻了四倍。

nftables 把这几套工具统一成了一个 nft 命令，用单一框架同时处理这几类流量过滤。而且它不预置任何表和链，你需要什么就自己建什么——听起来麻烦，实际是把"看不见的默认规则"变成了"所见即所得"，排查问题时不会再被藏起来的隐性规则坑。

现实情况是，你现在敲的 iptables 命令，背地里可能早就在用 nftables 干活了：

# 查看当前 iptables 到底用的是哪个后端
iptables --version
# 输出 iptables v1.8.7 (nf_tables)  → 已经是 nftables 在背后执行
# 输出 iptables v1.8.7 (legacy)     → 还是老引擎

Ubuntu 从 22.04 版本开始，执行 iptables 命令会自动通过 nftables 后端来路由，除非管理员手动切回 legacy 模式。Ubuntu 22.04+、Debian 11+、RHEL 9+ 都已经把 nftables 定为默认的包过滤框架。

写一条新规则，两种语法长这样：

# iptables 写法：放行 22 端口
iptables -A INPUT -p tcp --dport 22 -j ACCEPT

# nftables 写法：先建表建链，再加规则
nft add table inet filter
nft add chain inet filter input { type filter hook input priority 0 \; }
nft add rule inet filter input tcp dport 22 accept

看着 nftables 写法更长，但换来的是可以把 IPv4/IPv6 规则合并在一张表里管理，不用两套配置对着抄两遍。firewalld、ufw 这类前端工具底层也已经切到了 nftables，日常配置反倒感觉不出差别。

第二组：查域名，nslookup 曾考虑弃用

排查 DNS 问题，很多人的第一反应还是 nslookup。它的身世其实挺有戏剧性。

在 BIND 9 的开发过程中，Internet Systems Consortium 一度计划让 nslookup 彻底让位给 host 和 dig，理由也很实在：nslookup 不使用操作系统本地的 DNS 解析库来发起查询，行为跟系统实际解析逻辑可能不一致，容易造成排查时的误判，而且不同厂商发行的版本还可能混入 hosts 文件、NIS 等其它信息源，进一步增加了不确定性。

但这个弃用计划后来被撤销了——2004 年发布 BIND 9.3 时，这个决定被推翻，nslookup 之后一直得到完整支持。所以严格来说，nslookup 现在活得好好的，但业内主流建议依然是：新的排查工作、写进文档的示例命令，优先用 dig。

# nslookup 查 A 记录
nslookup example.com

# dig 查 A 记录，输出更详细，且走系统本地解析库
dig example.com

# 只要结果，不要一堆头信息
dig +short example.com

# 反查某个 IP 对应的域名
dig -x 8.8.8.8

# 查邮件记录、TXT 记录等，把类型换掉即可
dig example.com MX
dig example.com TXT

dig 的优势在于信息更完整、可脚本化程度更高，尤其是排查 DNSSEC、TTL 异常这类深层问题时，nslookup 的交互式界面反而是累赘。日常查一下域名解析用哪个都行，但写自动化脚本，建议直接上 dig。

第三组：远程传文件，scp 被曝出安全老账，官方建议改道

这一条对经常往服务器传文件、部署代码的人尤其重要——scp 不是"过时"，而是被曝出了实打实的安全问题。

SCP 协议脱胎于上世纪 80 年代设计的 RCP 协议，那个年代设计协议压根没考虑安全性，即便后来加了层 SSH 做传输加密，协议本身对输入的校验依然不够严谨。近几年不断有新的 CVE 漏洞被曝出（比如 CVE-2020-15778），而且这些问题很难被彻底修复，因为修复往往会破坏几十年来大家依赖的一些边缘用法。

于是 OpenSSH 团队做了个大动作：从 OpenSSH 9.0 版本开始，scp 客户端默认改用 SFTP 协议来传输文件，而不再是老的 SCP/RCP 协议。RHEL 9 更进一步，直接在系统层面把 SCP 协议标记为废弃，OpenSSH 套件默认不再使用它，scp 命令背地里跑的其实是 SFTP。

也就是说，你现在敲的 scp 命令，字面没变，底层协议可能早就完成了技术演进——这跟前面 iptables 变成 iptables-nft 是同一个套路。想知道自己用的是哪个协议，可以显式指定：

# 现代 OpenSSH 默认走 SFTP 协议，命令用法不变
scp file.txt user@remote:/path/

# 想强制用老的 SCP 协议（不建议，除非有兼容性需求）
scp -O file.txt user@remote:/path/

官方给出的两个正式替代方向：一个是 SFTP（sftp 命令，或者通过 libssh 库调用），协议定义清晰、有完善的输入校验，权限控制也更精细；另一个是 rsync 配合 SSH 做传输层加密，命令行体验更接近 cp。

# rsync：语法比 sftp 更贴近日常 cp 的习惯，还支持断点续传、增量同步
rsync -avz backup.tar.gz user@remote:/backups/

# sftp：交互式会话，适合需要浏览远程目录结构的场景
sftp user@remote
sftp> put localfile.txt
sftp> get remotefile.txt

日常小文件、一次性传输，scp 现在其实还是 SFTP 在背后干活，继续用没问题；但大批量同步、需要断点续传的场景，rsync 明显更趁手。

第四组：定时任务，cron 不是被废弃，而是有了更强的平替

这一条需要澄清一下：cron 并没有被官方标记废弃，几十年来它依然稳定可靠。但在 systemd 已经成为绝大多数发行版标配的今天，systemd timer 提供了一整套 cron 天生缺失的能力，越来越多团队把新的定时任务迁移了过去。

cron 最大的短板在于"黑箱"——它对系统状态一无所知，如果你把数据库备份任务定在凌晨两点，而数据库服务当时恰好挂了，cron 依然会照常执行脚本，然后默默失败。日志也是老大难：cron 默认把输出发邮件，或者依赖你自己手动重定向到文件，出了问题基本靠猜。

systemd timer 把这些短板逐个补上了。它的日志自动进入 journald，不用你操心重定向和轮转；支持配置依赖关系，比如等网络就绪、等数据库服务上线了再执行；还能设置随机延迟，避免大量定时任务在同一时刻集中触发把系统打垮；错过的任务也能在下次开机后自动补跑。

代价是配置稍微繁琐一点，systemd timer 需要两个文件配合：

# /etc/systemd/system/backup.service
[Unit]
Description=Daily Backup Script

[Service]
Type=oneshot
ExecStart=/usr/local/bin/backup.sh

# /etc/systemd/system/backup.timer
[Unit]
Description=Run backup daily at 2:30 AM

[Timer]
OnCalendar=*-*-* 02:30:00
Persistent=true

[Install]
WantedBy=timers.target

# 启用并立即生效
systemctl enable --now backup.timer

# 查看下次触发时间和历史执行记录
systemctl list-timers

# 查看这个任务的完整日志，不用再猜输出去哪了
journalctl -u backup.service

什么时候还是用 cron 更合适？如果只是在没有 systemd 的极简系统、容器镜像里跑一个简单脚本，cron 依然是更轻量的选择；但凡涉及"任务之间有先后依赖"“需要清晰的执行日志”"希望错过的任务能自动补跑"这类需求，systemd timer 基本是更优解。

第五组：磁盘分区，不是命令逐渐退出主流，是分区表标准在演进

这条跟前面几个略有不同：fdisk 命令本身没有被废弃，现在依然是使用最广泛的分区工具之一。使用场景真正在减少的，是它最初设计服务的那套分区表标准——MBR。

MBR（主引导记录）最多只支持 4 个主分区，单个分区大小也被死死限制在 2TB 以内。这个限制来自 32 位寻址的硬性天花板，不是哪个版本更新一下就能突破的。放在今天，一块普通的企业级机械硬盘轻松超过这个数字，MBR 从设计上就不够用了。

GPT（GUID 分区表）是配合 UEFI 一起成长起来的现代标准。它支持多达 128 个分区（无需再玩"扩展分区套逻辑分区"那套嵌套把戏），理论支持的磁盘容量上限高达 9.4 ZB，还在磁盘末尾保留了一份备份分区表，抗损坏能力也更强。

早期 fdisk 主要面向 MBR 分区表，因此受 2TB 限制影响。现代 Linux fdisk 已支持 GPT，大容量磁盘通常也可以直接使用；不过很多人习惯上依然会在大容量、多分区场景下选择功能更专注于 GPT 操作的 parted：

# fdisk 对付 MBR 分区，交互体验大家都熟，小容量磁盘依然常用
sudo fdisk /dev/sdb

# 大容量磁盘、需要 GPT 分区表时，parted 的操作逻辑更直接
sudo parted /dev/sdb
(parted) mklabel gpt
(parted) mkpart primary ext4 0% 100%

简单说：给虚拟机挂个几十 GB 的小盘、用惯了交互式操作，fdisk 继续用没问题；一旦涉及大容量存储、RAID 阵列、或者新装的 UEFI 系统，用 GPT 分区表配合 parted 会更省心。

一张表看懂：谁在变，怎么变

梳理一圈下来，能看出这几组命令的"变化方式"其实并不相同——有的是工具架构整体升级，有的只是曾经考虑过调整方向，有的是命令名没变、底层协议已经完成技术演进。整理成一张表，方便对照查阅：