必须人工干预的操作包括：首次安装时的磁盘分区、uefi/bios 启动模式选择、/boot 或 /efi 分区格式（fat32 或 ext4）、关键挂载点（/、/home、/var）空间分配、uefi 下手动创建 vfat 格式的 /boot/efi（≥200mb）、legacy bios 中 swap 文件的 dd+mkswap+swapon、luks 加密密钥短语输入。
哪些操作必须人工干预，不能交给脚本或工具
Linux 系统里真正需要人盯住、手动敲命令的环节，其实比想象中少，但一旦漏掉，后续全盘崩——比如首次安装时的磁盘分区、UEFI/BIOS 启动模式选择、/boot 或 /efi 分区格式（FAT32 还是 ext4）、以及关键挂载点（/、/home、/var）的空间分配。这些不是“能自动化”，而是“不该自动化”：自动分区工具（如 Anaconda 的默认策略）会把 / 分得太小（常为 20GB），结果装完 Docker + 日志就爆满；它也可能忽略你实际用途——比如你搭的是邮件服务器，/var 需要大空间，但自动分区根本不管这个。
常见错误现象：df -h 显示 / 已用 95%，journalctl --disk-usage 却只占几百 MB，说明根分区从一开始就没留够余量。
- UEFI 模式下必须手动建
/boot/efi挂载点，且类型必须是vfat，大小 ≥200MB；Legacy BIOS 则不需要 - 交换分区（swap）若用文件替代分区，得等系统装完再
dd+mkswap+swapon，安装器不帮你做 - 加密 LUKS 分区必须人工输入密钥短语并确认，任何自动化都会导致无法开机
哪些重复操作已经可以安全交给自动化
装完系统后的初始化配置，90% 都可固化为脚本执行，只要避开硬件强依赖项。比如用户创建、SSH 密钥注入、/etc/sudoers 权限收紧、fail2ban 规则部署、甚至 systemd 服务单元的启用顺序——这些全是纯文本和状态管理，没歧义、无交互、可验证。
使用场景：批量部署测试机、CI/CD 构建节点、云上临时实例。
-
useradd -m -s /bin/bash -G wheel deploy可替代手动adduser流程 -
sshd_config中设PasswordAuthentication no和PubkeyAuthentication yes，配合ssh-copy-id就能跳过密码输错风险 - 用
systemctl enable --now docker替代先start再enable的两步手误
自动化失败时，最该先查的三个地方
脚本跑一半卡住或报错，别急着重跑，先看这三处——它们覆盖了 80% 的“看似自动化、实则半人工”陷阱。
常见错误现象：Ansible 报 Failed to connect to the host via ssh，但手动 ssh 能通；或 apt update 在脚本里失败，终端里却成功。
- 环境变量缺失：
PATH在非交互式 shell（如 cron 或 ansible）里极简，sudo apt可能找不到，应显式写成/usr/bin/apt - TTY 依赖：某些命令（如
passwd、cryptsetup）默认要求真实终端，脚本里需加--stdin或改用chpasswd替代 - SELinux/AppArmor 上下文未同步：脚本复制了配置文件到
/etc/nginx，但没运行restorecon -Rv /etc/nginx，导致服务起不来
人工判断不可替代的临界点
当操作涉及“权衡”而非“执行”，自动化就该停手。比如决定是否启用 zram 替代 swap：它省 SSD 寿命但吃 CPU；或者选 ext4 还是 xfs——前者适合小文件多的 /home，后者在大文件吞吐（如视频转码目录）更稳。这类决策没有标准答案，取决于你的硬件、负载模型、运维习惯。
容易被忽略的地方是日志轮转策略：自动脚本可以配 logrotate，但 /var/log/journal 的最大尺寸（SystemMaxUse=）和保留天数（MaxRetentionSec=）必须结合磁盘总容量和审计要求来定，设错会导致日志静默丢弃，出事时翻不出线索。
