你重构了一个模块，改了一批文件里的引用路径，用的是 sed -i 一条命令扫过整个目录。命令跑完，回显干净，没有任何报错。你以为改完了，直到运行时某个模块「找不到」，才发现有些文件压根没改到。
现象
sed -i 's/旧路径/新路径/g' *.py显示跑完了，退出码 0；- 但抽查几个文件，发现有的改了、有的没改，没有任何报错；
- 直到运行时（运行时才加载到那些没改的文件），才报「找不到模块」之类的错；
- 漏改是没有规律的，不是「某个目录全漏」或「某种文件全漏」，是零散地漏。
最麻烦的是它是静默的——你没法从命令的输出判断出「有几个文件没改到」。
根因
在 Windows / Git Bash 环境下，sed -i 的批量替换受几个因素影响，会静默地跳过或漏改部分文件：
-
引号处理差异。 Git Bash 的 MSYS 层对参数里的引号和路径有自己的解释规则（参见「MSYS 路径转换」）。传给
sed的模式串、文件列表在经过这层时，可能和你的预期不一致，某些文件被当成别的参数处理了。 -
行尾差异。 你的模式里假设的是某种换行（LF 或 CRLF），但文件里实际是另一种。
sed按行处理，行尾不同可能导致匹配不上——而且不报错，因为它「成功处理了这一行，只是没匹配到」。 -
-i的行为差异。sed -i是就地修改，可以在 GNU sed 和 BSD sed 之间语义不同（-i后面到底要不要跟参数）。在某些环境下，它可能创建备份文件而不是真改，或行为不完全一致。 -
批量列出文件的边界。
*.py展开成文件列表时，文件名里带空格或特殊字符的文件，可能被拆成多个参数，替换对象错位。
这些因素叠加的效果就是：一部分文件被正确处理，另一部分被以某种方式绕过了，而 sed 不认为这是错误。
解决
放弃盲批量替换，改用精确的字符串替换，逐个文件修改。
用脚本语言（Python 是最稳的）来读—改—写，你自己完全控制过程：
from pathlib import Path
OLD = 'old.module.path'
NEW = 'new.module.path'
for p in Path('src').rglob('*.py'):
text = p.read_text(encoding='utf-8')
if OLD not in text:
continue
new_text = text.replace(OLD, NEW)
p.write_text(new_text, encoding='utf-8')
print(f'[CHANGED] {p}')
这段代码的好处：
- 明确列出「哪些文件被改了」（打印出来，可核对）；
- 用 Python 自己的字符串替换，不受 shell 引号、行尾差异影响；
OLD not in text的跳过逻辑清晰，改了哪些一目了然。
改完之后，必须做一次全局残留检查： 搜索旧路径，确认只剩零命中。
grep -rn 'old.module.path' src/ || echo 'OK: 无残留'
如果这条还搜出东西，说明有文件没改到——这正是 sed 静默漏改时你不会知道、但用一个显式的 grep 就能抓出来的。
延伸与预防
一句话原则：
批量替换要配一次「改完再全局搜一遍」的验证。
任何批量修改，验证都是操作的一部分，不是可选的收尾。因为批量操作的本质特征是「影响面大、单点不可见」——你没法靠肉眼确认每个文件都对。
一个可靠的批改流程：
- 改之前：明确要改什么、影响哪些文件（先
grep -rl列出清单，看看是不是你预期的那些）； - 改：用可控的方式（脚本）改，并记录改了哪些；
- 改之后：再做一次全局搜索，确认旧值零命中、新值出现在该出现的地方。
这和「一个空输出不能当结论」是同一类思维——别把「命令没报错」当成「事情做对了」。 一个没有输出、没有报错的批量命令，恰恰是最需要你主动去验证的那种：它可能成功了，也可能什么都没做。
尤其当工具本身的行为依赖平台（sed 在 macOS、Linux、Git Bash 上行为都有细微差别），把关键的动作交给平台无关的实现（比如 Python），比赌某个工具的跨平台一致性要可靠得多。