废弃命令与替代矩阵：迁移路径、仍可使用的旧场景与常见误解

使用方式

先明确“废弃”的层级：上游停止维护、发行版改用新默认、只保留兼容包装、接口被新模型取代，处理方式并不相同。本页把常见旧命令与替代方案放在一张矩阵里，再按主题说明迁移细节。它不声称旧命令已经彻底不可用；很多命令仍能安装或由兼容层提供，只是不再适合作为新脚本和新架构的默认选择。

使用顺序建议是：先在目标系统上确认实际版本和安装包，再查矩阵确定替代方案，最后在测试环境验证语义，而不是直接批量替换。迁移完成前保留旧路径和回滚方案，尤其是网络、防火墙和引导相关组件。

结论先行

• “废弃”通常不等于“已删除”，更不等于“执行会报错”；兼容层可以让旧命令继续工作多年。
• 新脚本、新镜像和新集群应直接使用替代方案，避免把技术债传给下一批维护者。
• 迁移的第一风险不是命令名，而是选项语义、输出字段、规则顺序、插件行为和错误处理。
• 旧命令仍有合理场景：macOS/BSD、救援镜像、无 systemd 的容器、旧内核、认证绑定的离线系统。
• 最稳妥的策略是“新写新用、旧留兼容、分批退出”，并给每一步留下可验证的回滚点。

替代矩阵

逐项说明

网络工具：ifconfig、netstat、route、arp

Linux 上这些命令来自 net-tools，新系统往往默认只装 iproute2。替代关系是 ifconfig 看地址和链路、ip addr/ip link 管理；netstat -tulnp 看监听端口、ss -tulnp 更高效；route -n 看路由、ip route 管理；arp -an 看邻居、ip neigh 管理。选项并非一一对应，输出字段也不同。

ip addr show
ip link set eth0 up
ip route show
ip neigh show
ss -tulnp

macOS 没有 iproute2，仍然使用 ifconfig、netstat、route 和 arp；把 Linux 脚本里的 ifconfig 机械替换成 ip 会让 macOS 直接失败。跨平台脚本应按 uname 分支，或调用各自平台的命令。详见 ifconfig、netstat、route、arp 与 linux-vs-macos。

防火墙：iptables 与 nftables

iptables 并没有从 Linux 消失：现代发行版常提供 iptables-nft，把 iptables 语法翻译到 nftables 后端；也可能同时存在 iptables-legacy，形成两套互不相通的规则。迁移第一步是 iptables -V 确认后端，再用 iptables-translate 翻译规则，最后在测试机验证 NAT、连接跟踪和持久化。

iptables -V
iptables-translate -A INPUT -p tcp --dport 22 -j ACCEPT
nft list ruleset

仍必须用 iptables 的场景包括：旧版容器运行时和 Kubernetes 组件、只会写 iptables 的厂商 agent、依赖特定 iptables 扩展而 nft 尚无等价表达的规则。不要把 iptables-nft 当成“已经原生 nftables”，排查规则冲突时仍要区分后端。详见 iptables-vs-nftables、iptables 与 nft。

容器：docker-compose 与 docker compose

Compose v1 是 Python 实现，已于 2023 年 7 月 EOL；Compose v2 是 Go 实现的 Docker CLI 插件，命令为 docker compose。迁移时先确认 docker compose version，安装 compose 插件，再检查 CI 镜像里是否还在调用旧二进制。两者大多数命令兼容，但顶层 version: 字段已过时，部分参数和项目命名行为需要复核。

仍可能需要 docker-compose 的场景：旧 CI 镜像、离线主机、被固定版本的遗留栈。某些系统上的 docker-compose 其实已经是 v2 的独立二进制，因此不能只看命令名，必须看版本输出。详见 docker-compose 与 docker-cheatsheet。

包管理与系统生命周期：yum、dnf、CentOS 7

CentOS 7 使用 yum 3；RHEL 8 及之后改用 dnf，并通常保留 yum 作为兼容入口，所以“yum 还能用”不代表应该继续写 yum。迁移时关注插件差异（yum-plugin-* 与 dnf-plugins-core）、yum-config-manager 与 dnf config-manager、事务历史和缓存路径。旧 playbook 可以继续跑，但新任务应写 dnf。

CentOS 7 已于 2024-06-30 结束维护，镜像和仓库转入 vault，继续使用不会让系统立刻停机，但不再获得安全更新。迁移方向包括 RHEL（可用 convert2rhel 评估）、Rocky Linux、AlmaLinux，或借机迁到其他发行版；跨大版本通常重装比原地升级更可控。迁移前先盘点应用依赖、认证绑定、内核模块和停机窗口。详见 yum、dnf、version-eol-matrix、platform-lifecycle-matrix 与 migration-readiness-checklist。

服务管理：SysV 与 systemd

service 和 chkconfig 是 SysV 时代的入口，在 systemd 系统上通常由兼容层转发：service 可能调用 systemctl，旧 init 脚本由 systemd-sysv-generator 包装。新脚本应写 systemctl start、systemctl enable --now、journalctl -u。仍然需要旧命令的场景包括无 systemd 的容器、Alpine/BusyBox 类系统、老发行版和尚未重写的 init 脚本。

不要在容器里为了兼容旧脚本而启动完整 systemd；更常见的做法是把应用改为前台进程。迁移 unit 时注意 Type、ExecStart 绝对路径、环境变量、重启策略和日志收集。详见 systemd-vs-sysvinit、systemctl、service 与 chkconfig。

语言运行时：Python 2 与 Python 3

Python 2 已于 2020-01-01 EOL，最后一个版本是 2.7.18。许多发行版不再默认提供 python，或让 python 指向 Python 3；macOS 也在较新版本移除了系统自带的 Python 2。迁移不只是改 shebang：还要处理字符串与字节串、除法和 print 语法、依赖是否支持 Python 3、虚拟环境和打包方式。

仍可能需要 Python 2 的场景：遗留应用、厂商设备、旧插件、RHEL 7 等老系统。正确做法是隔离运行、限制网络暴露、记录技术债并安排退出，而不是假装它还能获得安全更新。详见 python。

其他：apt-key、etcdctl v2、cgroup v1、ifupdown

apt-key 的全局信任模型已被废弃，改用独立 keyring 和 signed-by，旧安装脚本往往需要人工改写并核对密钥指纹。详见 apt-key 与 apt-get。

etcd v2 API 已弃用，现代 etcdctl 默认 v3；快照、成员和租约命令与 v2 不同，恢复工具也逐步转向 etcdutl。老集群仍可能需要兼容参数，但新备份脚本应按 v3 编写。详见 etcdctl、etcdutl 与 etcd。

cgroup v1 进入内核维护模式，并未立即删除；新集群应优先 cgroup v2。老内核、未适配 v2 的运行时和监控 agent 仍可能要求 v1 或混合模式。详见 cgroup-v1-vs-v2 与 migrate-cgroup-v1-to-v2。

ifup/ifdown 在部分发行版逐步让位于 NetworkManager 或 systemd-networkd，但 Debian 精简系统和 Alpine 仍可能使用 ifupdown。迁移前确认网络配置由谁管理，避免两套工具同时改同一个接口。详见 ifup、ifdown、nmcli 与 networkctl。

仍必须用旧命令的场景

• macOS 和 BSD：ip、ss、systemctl 并不存在，ifconfig、netstat、route、arp 仍是原生工具。
• 救援镜像和精简系统：可能只有 BusyBox 或旧 net-tools，缺少 iproute2、nft、systemd。
• 旧内核和旧运行时：cgroup v2、nftables 或新版容器运行时可能不可用。
• 厂商设备和认证绑定环境：升级路径受厂商支持矩阵限制，不能自行替换。
• 离线或气隙系统：无法及时更新仓库和依赖，CentOS 7 仍可能继续运行。
• 旧 CI 镜像与构建缓存：Compose v1、Python 2、旧 yum 可能被硬编码在流水线里。
• 第三方安装脚本：仍在调用 apt-key 或只认旧命令，需要先审计再改。
• 遗留 etcd 集群：备份、恢复和监控脚本可能依赖 v2 API 或旧字段。

这些场景的共同点是“暂时不能换”，而不是“新项目应该继续用”。保留旧命令时至少要做隔离、监控、文档记录和退出计划。

迁移方法

1. 盘点：记录系统版本、命令路径、软件包来源、配置文件、调用点和依赖关系。
2. 验证：在测试环境跑真实流量和故障场景，不只比较帮助输出。
3. 兼容：优先使用官方兼容层（iptables-nft、yum 入口、systemd 生成器），但明确它不是长期方案。
4. 回滚：备份配置和数据，保留旧二进制或快照，定义回滚触发条件。
5. 切换：分批替换，先非关键业务，再核心业务；同步更新文档和 runbook。
6. 清理：观察期结束后移除旧包和旧脚本，避免两套工具同时修改同一状态。

常见误区

• 把“废弃”当“已删除”；很多旧命令仍安装，或由兼容层提供。
• 只替换命令名，不核对语义：ss 与 netstat 的字段、nft 与 iptables 的规则顺序都不同。
• 在 macOS 脚本里把 ifconfig 换成 ip；macOS 没有 iproute2。
• 认为 CentOS 7 到期当天系统会停止运行；它仍能跑，但不再有安全更新。
• 认为 Python 2 代码改个 shebang 就能跑在 Python 3；语法、字节串和依赖都可能不兼容。
• 把 iptables-nft 当成原生 nftables，忽略后端、计数器和扩展差异。
• 在容器里启动 systemd 来兼容旧脚本；通常应改为前台进程。
• 认为 Compose v1 文件可以永远原样运行；version 字段和部分语义已经过时。

参考链接

• Docker Compose v2 迁移
• DNF 文档
• systemd 文档
• Python 2 日落说明
• CentOS Linux EOL
• nftables Wiki
• Debian 第三方仓库与 apt-key
• Kubernetes cgroup v2

读完自测

合上页面，先回答，再展开对照。

1. “命令被废弃”是否等于系统上已经不能执行？请举两个兼容层的例子。
2. 把 ifconfig、netstat 迁移到 ip、ss 时，为什么不能只替换命令名？macOS 上应该怎么办？
3. CentOS 7 已 EOL，现有系统还能运行吗？迁移前应先做哪几件事？

相关条目

• iptables-vs-nftables — 防火墙模型与迁移
• systemd-vs-sysvinit — 服务管理差异
• cgroup-v1-vs-v2 — cgroup 版本差异
• version-eol-matrix — 版本与生命周期总表
• platform-lifecycle-matrix — 操作系统支持窗口
• migration-readiness-checklist — 迁移前的检查清单
• migrate-iptables-to-nftables — iptables 到 nftables 实操
• migrate-cgroup-v1-to-v2 — cgroup v1 到 v2 实操
• migrate-docker-compose-to-k8s — Compose 到 Kubernetes
• ip — iproute2 地址与路由
• ss — socket 统计
• nft — nftables 客户端
• dnf — RHEL 系包管理
• systemctl — systemd 服务管理
• python — Python 解释器
• apt-key — APT 密钥迁移
• etcdctl — etcd 客户端
• etcdutl — etcd 快照工具
• docker-compose — Compose 命令