拦截的目的是打断惯性
危险命令拦截不是为了让工具更聪明，而是为了在「即将造成不可逆影响」的那一刻插入一次停顿。这类命令的特征很清晰：作用对象是可被覆盖或删除的数据、结果是不可逆的、影响的可能范围远大于操作者以为的范围。拦截机制的价值在于把判断重新交回给人——让执行者看到真实的目标范围后再决定是否继续，而不是依赖他记得自己刚改过变量。
基本信息
| 适用对象 | 自研脚本、平台执行入口、运维通道 |
|---|---|
| 典型危险动作 | 递归删除、整盘写入、批量停止服务、覆盖配置、改权限 |
| 拦截要素 | 识别模式、展示影响范围、要求显式确认 |
| 确认方式 | 输入目标名称或随机串，而非简单确认键 |
| 边界 | 拦截只是最后一道，不能替代范围校验与权限收敛 |
值得拦截的模式
- 递归删除：路径中含变量或通配符时，实际作用对象可能远超预期
- 整盘或整卷写入：命令写错设备名时会直接破坏数据，且无法回退
- 批量停止或重启：影响面覆盖正在提供服务的全部实例
- 覆盖配置文件：无备份的覆盖会让回滚只能依赖记忆
- 权限与所有权批量修改：递归改错会让服务后续无法启动或数据无法访问
- 强制参数组合：跳过确认与忽略错误的组合会让放大机制同时成立
确认式封装示例
确认式封装示例
cleanup() {
local dir="$1"
case "$dir" in /data/app*|/var/tmp/app*) ;; *) echo '目标不在允许范围，已拒绝' >&2; return 1;; esac
local n; n=$(find "$dir" -mindepth 1 | wc -l)
echo "将删除 $dir 下的 $n 个项目，确认请输入目录名："
read -r ans; [ "$ans" = "$dir" ] || { echo '已取消' >&2; return 1; }
rm -rf -- "$dir"
}
cleanup "${1:-}" # 未传参时不进入任何路径拦截方式对比
| 方式 | 强度 | 适用场景 |
|---|---|---|
| 超时提醒 | 弱 | 交互式人工操作 |
| 输入目标名称确认 | 中 | 批量清理与覆盖类操作 |
| 强制预演后确认 | 较强 | 变更类脚本 |
| 双人复核 | 强 | 生产重大变更 |
| 执行期禁用 | 最强 | 冻结期内禁止任何变更 |
确认提示要展示真实范围而不是固定文案。把「即将影响 N 台主机、N 个目录」算出来打印出去，比任何警告语都有效——很多误操作在数字显示出来的一瞬间就被操作者自己拦住了。
拦截机制要避免被绕过式使用：如果为了自动跑通而提供了跳过确认的开关，它必然会在某个赶时间的时刻被长期打开。跳过开关应限定在明确的环境范围（如测试环境）内可用，且使用行为需被记录。