一次线上事故复盘：IFS 全局修改未还原，误删静态资源
2026 年 5 月，某电商运维团队的批量日志清理脚本在线上触发误删。脚本里全局修改了 IFS，用完后没有还原，带空格的业务目录被当成多个独立参数，最后误删了半台服务器的静态资源，回滚花了近 1 小时。这类坑在 Shell 里很隐蔽，因为不触发的时候「看起来能跑」。
IFS 是什么
IFS（Internal Field Separator）决定 shell 对未加引号的变量展开、命令替换结果做自动分词时的规则。
默认值是空格、制表符、换行。此时连续分隔符合并，首尾分隔符被忽略。
如果把它改成逗号这类非空白字符，行为就不同：
- 连续逗号会保留空字段
- 首尾逗号也会被保留
很多批量处理脚本就是在这里翻车的。
坑 1：全局改 IFS 不备份还原
全局修改 IFS，后续所有命令的分词逻辑都会受影响。现场脚本常写成：
IFS=,
# ... 业务逻辑
# 忘记还原
后面的 for f in $(something)、未加引号的 $var 会全部按新规则切分。
正确写法有两种。
用命令前缀，让 IFS 只对当前命令生效：
IFS=, read a b c <<< "x,y,z"
如果必须全局修改，用完要立刻还原：
oldIFS=$IFS
IFS=,
...
IFS=$oldIFS
坑 2：忽略两类 IFS 字符差异
空白类分隔符会自动合并连续项，且忽略首尾。非空白类分隔符不会合并，连续分隔符意味着空字段。
典型场景是处理 CSV。"a,,b" 用 IFS=, 切分，中间的空字段会被保留，如果没处理空列，后续字段全部错位。
想让连续非空白分隔符合并，需要先做参数扩展替换。Bash 4.0+ 支持：
content=${content//,+/,}
然后再用 IFS 拆分。
坑 3：跨 shell 行为不一致
同一套脚本在 bash、zsh、dash 下跑，结果可能完全不同。
- zsh 默认关闭
SH_WORD_SPLIT，变量展开不按 IFS 分词，直接改 IFS 看不到效果 - dash（Debian/Ubuntu 默认
/bin/sh）不支持 IFS 里使用 null 字符\0 - bash 3.2 及以下版本，IFS 处理多字节字符有 bug，中文分隔符会乱码
跨环境脚本要在开头明确指定 bash：
#!/usr/bin/env bash
到目标环境做一次真实分词验证。
坑 4：read 读最后一行总是读不到
文件最后一行如果没有换行符，read 能读到内容但返回非 0，导致 while 循环提前退出。
典型错误：
while read -r line; do
# last line missing
done < file
正确写法：
while IFS= read -r line || [ -n "$line" ]; do
# process line
done < file
这里顺手把 IFS= 也写上，避免 read 对行首尾空白做修剪。
IFS 临时设空的用法
IFS= 可以让分词完全关闭，变量展开、命令替换的结果整段作为一个字段。处理含特殊字符的内容时很有用。
但全局设空同样会让路径解析、参数传递等依赖分词的操作异常。只能临时修改，用完立刻还原：
oldIFS=$IFS
IFS=
# 整段处理
IFS=$oldIFS
工程化脚本标准
日志清理这类高危操作，上线前至少按以下基准写：
set -euo pipefail
IFS=$'\n\t'
文件名循环不要用：
for f in $(ls)
改用：
find . -print0 | while IFS= read -r -d '' f; do
...
done
上线前过一遍 shellcheck，重点检查全局 IFS 修改、未加引号的 $var、for 循环 ls 这几个高危项。