幸运小姐之前我接手过一批几十台的缓存节点，统一要改Nginx里的一个限流参数，有人提议写个Python脚本批量下发，有人建议用Ansible。那边临时环境连外网拉包都不方便，最后我在命令行里敲下一条长度不到100字符的sed命令，几秒钟内把所有节点配置全部改完，原地验证无误。那个场景给我留下的印象太深了：Linux系统里预装的命令，sed绝对是被低估的一个。
这篇文章正想系统讲讲sed命令。它不是一本命令手册的翻译，而是我从日常使用里提炼出来的实践笔记，重点覆盖“增删查改”四条主干，以及那些文档里很少写但实际开发运维中极易遇到的行为陷阱。无论你是刚学Linux常用命令的新手，还是需要经常处理服务器配置文件的运维，这篇文章应该能让你少走很多弯路。
1. 为什么处理文本流时，我最先挑中的是sed
1.1 sed不是又一个编辑器，而是编辑器里最像流水线的一层
很多人一听到sed，就把它归类成“另一个命令”，然后背了些参数就扔在一边，真遇到任务还是打开vim老老实实写宏。这种用法并不是错的，只是没有把sed最擅长的场景用起来。
sed的全名是stream editor，直译过来就是流编辑器。关键点落在“流”上：它处理的对象不是文件本身，而是从文件或管道中源源不断流入的文本行。这对Linux这种“一切皆文件、一切皆数据流”的系统来说，位置非常特殊。vim工作时需要你盯着屏幕、交互输入；sed则是你说一句，它从头到尾跑一句。只要输入不是交互式终端，把vim塞进管道里会很别扭，但sed天生就是为这种批量处理设计的。
所以我的使用习惯是：凡是在脚本里要批量处理文本，优先考虑sed，而不是vim。 它不依赖终端交互、不需要打开整个文件，占用内存极小，非常适合在自动化任务中处理日志、配置文件、数据文件。
1.2 sed和vim、awk、perl的分工，很多人一开始就没搞清
初学Linux命令时最难熬的就是工具太多，不知道选谁。有个比较通俗但很有效的划分方式，我分享下个人的经验。
- vim：交互式修改文件，适合人坐在终端前，一边看一边调整，你的眼睛和手是决策者。
- sed：针对行的编辑操作，场景是“批量的、结构化的、不需要人逐步确认的”改动，比如把配置里所有8080端口改成9090、删除第20到30行、在当前匹配行之后插入一段配置。
- awk：更强的字段分析工具，适合把文本当表格处理，做统计、格式化输出、按列提取数据。比如拿到一份访问日志，要统计每个IP出现次数，我用awk比用sed顺手得多。
- perl/python：需要复杂逻辑处理文本时再上重型工具，它们能搞定任何文本问题，但为了改一行配置就启动它们，成本偏高了。
简单说，我平时写shell脚本时，sed占了文本修改的七成以上，其余才让awk或python上场。它不是那种“炫技型”命令，而是一个稳定可靠的基础工具，这也是为什么它在服务器Linux环境里基本是标配。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 先把执行模型盘顺：sed为什么能边读边改
2.1 读一行、改一行、输出一行，sed的循环到底怎么转
想要真正掌握sed，第一件事不是背命令，而是理解它在后台反复执行的那个循环。这个原理几乎决定了后头所有命令表现，理解了它，你调试起来也会快得多。
sed处理输入时，大致遵循这样一个流程：
- 从输入（文件或管道）中读取一行文本，把末尾换行符去掉，放入模式空间（pattern space）。
- 对模式空间里的内容，按顺序执行脚本中给定的所有sed命令。
- 如果命令没有显式禁止输出（比如使用了-n选项），则把当前模式空间的内容打印到标准输出。
- 清空模式空间，继续读取下一行，重复以上过程。
所以对sed来说，每次处理的粒度是一行，但它的读取逻辑保证了文件不会一次性载入内存。不管一个文件是1MB还是10GB，sed在任意时刻都只保留当前正在处理的一行的内容，这种流式处理特点在Linux环境里非常宝贵。同样处理一个大日志文件，如果你写个脚本用readline逐行去读，性能通常远不如sed一条管道到底。
模式空间这个概念听起来玄乎，实际上它就是sed用来“临时放手头这一行文本”的一块工作区。绝大多数sed命令的操作对象都是模式空间的内容，你要把这一行里的foo替换成bar，本质就是在模式空间里做替换。
2.2 地址寻址：你真正需要掌握的六种写法
sed命令的通常结构是这样：
bash复制sed '地址命令'
地址用来圈定命令作用于哪些行。如果省略地址，命令会对每一行都生效。下面这六种地址写法，几乎覆盖了我日常95%的需求，建议大家优先掌握。
- 空地址：作用于所有行。比如
sed 's/foo/bar/'，对所有行执行替换。 - 单行号：只作用于该行。
sed '3d'表示删除第3行。 - 行号区间：作用于某一段连续范围。
sed '2,5d'删除第2到第5行。 - 结束行号$：代表最后一行。
sed '$a\# end'表示在文件末尾追加一行。 - 正则地址：格式是
/正则表达式/，作用于所有匹配该正则的行。sed -n '/error/p'只打印包含error的行。 - 步进地址：格式是
first~step。sed -n '1~2p'表示从第1行开始，每隔2行打印一次，也就是打印奇数行。
地址还有一个重要修饰符 !，要删掉不匹配的行时很好用。sed '/^#/!d' 的含义是删除所有不以#开头的行，相当于只保留注释行。
地址还可以叠加，比如 /start/,/end/d 表示从匹配start的行开始删除，一直到匹配end的行结束。这种区间匹配在处理日志中的某段时间范围或配置文件中的server块时非常实用。
2.3 模式空间与保持空间：sed也是有状态的
不少对sed有一定了解的人，一碰到保持空间（hold space）就发怵，觉得它晦涩。其实可以把它理解为sed专门开辟的一块“草稿纸”。
模式空间每次处理新行时会被清空并重新填入当前行，而保持空间中的内容不会随行的切换而消失。你可以用 h 命令把当前行复制到保持空间，用 H 把内容追加到保持空间末尾，用 g 把保持空间内容回填到模式空间来覆盖当前行，用 G 把保持空间内容追加到模式空间当前行之后，x 则交换两块空间的内容。
举一个最直观的例子：如果要把文件的最后一行放到第一行之前，可以这样做：
bash复制sed '1{h;$!d};${G}' file.txt
第1行先被保存到保持空间，接下来非最后一行都删除，处理到最后一行的末尾时再把保持空间中的内容追加回来。如果没有保持空间，这类跨行处理就会变得非常麻烦。
保持空间在日常简单替换里用得不多，但当你开始写稍微复杂一点的sed脚本时，它就是突破“一行一世界”限制的那扇门。
3. 增：a命令和i命令隐藏的几处细节
3.1 a/i 到底“插在哪”
往文本里新增内容，sed提供了两条命令：
a（append）：在当前匹配行的后面追加内容。i（insert）：在当前匹配行的前面插入内容。
一条最简单的用法是：
bash复制sed '3a\This is inserted after line 3' demo.txt
如果你用单行命令方式，a 后面的反斜杠不是必须的，GNU sed 允许写成 sed '3a This is a new line' demo.txt，但更经典、兼容性更好的写法是保留它。命令执行后，新文本会按需放到第3行后面，原始文件不会被改动，这只是把处理后的整条结果发送到标准输出。
假设demo.txt内容如下：
code复制line1
line2
line3
line4
执行 sed '3a\new-line' demo.txt，输出为：
code复制line1
line2
line3
new-line
line4
这里的要点在于：新增操作并不修改原文件，它是在数据流里给当前处理行“额外多打印一行”。这一特性让它很适合在输出文本时临时加注释或标记。
3.2 多行文本的追加写法
追加一行很简单，但现实场景里经常要追加一段配置或一大块文本。多行追加有几种常见写法，看你用GNU sed还是BSD sed，选择会有所不同。
GNU sed下，最简单的是在文本内部用字符串里的换行符，或者直接在命令中用反斜杠续行：
bash复制sed '/^\[server\]/a\
host=127.0.0.1\
port=8080\
timeout=30' app.conf
这样会在匹配到 [server] 这个段落标题后，追加三行配置内容。如果使用Shell里的 $'...' 语法，也可以写得更紧凑：
bash复制sed '/^\[server\]/a\'$'host=127.0.0.1\nport=8080\ntimeout=30' app.conf
不过从可读性看，我建议在多行内容不多时，仍然用反斜杠续行，一眼能看清追加了什么。真正要插入的文本特别长的话，更好的办法是把追加片段写在单独文件中，用 r 命令读取插入：
bash复制sed '/^# BEGIN ROUTE/r route.conf' app.conf
r 命令的作用是，当sed匹配到某一行时，把指定文件的内容原样插入到匹配行之后。这在批量往多个配置文件里注入统一文本片段时极为方便，内容维护成本也低。
3.3 真实场景的“增”：配置片段自动注入
假设我有几百台服务器，每台的Nginx配置都需要加一段限制请求速率的规则，统一插到server块内部。如果手写正则去定位server块，有时会因为server嵌套而误伤，我采用的策略是借助注释标记定位：
在模板配置里预先埋好一行标记：
code复制# RATE_LIMIT_ANCHOR
然后批量执行：
bash复制sed -i '/# RATE_LIMIT_ANCHOR/a\
limit_req_zone $binary_remote_addr zone=mylimit:10m rate=5r/s;\
limit_req zone=mylimit burst=10;' server.conf
这种用清晰锚点配合a命令的做法，比单纯依赖行号要稳定得多，因为配置文件在不同环境里可能行号不一致，而标记文本不会变。把“锚点 + 追加”的组合记牢，解决大批量插入场景时，思路会清晰很多。
4. 删：d命令没那么简单，关键在于圈选范围
4.1 d命令在“组合拳”里通常是扫尾角色
删除行的命令是 d。sed '5d' file 会删除第5行，这没什么好说的。真正考验人的，是你会不会精确圈定“要删除的行”。
比如删除某一段连续行：
bash复制sed '10,30d' app.log
删除不包含关键词的行：
bash复制sed '/keep/d' app.log
删除从匹配start到匹配end之间的行，在处理日志时间段时能省很多事：
bash复制sed '/2025-01-01 10:00:00/,/2025-01-01 10:05:00/d' api.log
以上命令执行完毕后，结果都输出到终端，原文件不变。实际修改文件可以再加 -i，但我会在后面的章节里专门展开说明 -i 的各种坑。
4.2 删除前先验证范围，避免一次误删
如果你要用sed删除大量数据，我强烈建议先不要急着加 -i。更稳的路径是先打印出即将被删除的行，确认范围后，再真正执行删除。比如我打算删除配置中所有包含 debug mode 的行，命令前半段可以先这样验证：
bash复制sed -n '/debug mode/p' server.conf
确认打印出来的行确实都是要删的，再执行真正的删除：
bash复制sed -i '/debug mode/d' server.conf
这里的 -n 开关是用来关掉“每一行都自动打印”，只让p命令显式打印匹配行。这个组合 (-n + p) 是排查删除、替换范围是否准确最有效的手段。
还有一个相当高频的需求：删除与保留反过来理解，也就是“删除所有不是xxx开头的行”，可以这样写：
bash复制sed -i '/^#/!d' config.conf
这条命令的意思是：如果某行不以#开头，则不执行 d，等价于“执行删除的非匹配”。反过来看，! 有时比挖空心思写复杂正则要好用多了。
4.3 d命令导致当前行处理结束的“坑”
这一节要说的坑，是我看很多同事写sed时踩过无数次的。d 命令一旦执行，sed会立即停止处理当前行，跳到下一行输入继续。 后面针对同一行的其他命令不会执行。
比如有这样一个命令：
bash复制sed -i '/^#/{d; s/debug=false/debug=true/}' server.conf
本意是想删除注释行，再把注释行中的debug参数做真。但由于 d 一旦命中，就直接跳到下一行了，后面的 s 替换命令根本没机会执行。如果你的替换逻辑本来就是为了处理被删除的那一行，那么这种写法永远达不到目的。
正确的做法应该是反着来，先把非注释行里的内容替换掉，再统一删除注释行，或者用 !d 保留目标行后再替换：
bash复制sed -i '/^#/!s/debug=false/debug=true/' server.conf
这条命令对不是#开头的行做替换，注释行原样保留不动。如果你确实需要先改再删，请把 d 放到最后。这种“命令执行顺序决定结果”的细节，恰恰是Linux面试题里特别喜欢考察的底层能力。
5. 查：不用grep时，sed -n 'p' 比你想的更好用
5.1 p命令不加-n时出现的“双份输出”
p 命令用于打印当前模式空间中的内容。初学sed的人常犯一个小错误：直接 sed '/error/p' app.log，却看到匹配行的内容在终端里出现了两遍，不匹配的行反而正常出现。这背后的原因就是第2章讲的sed默认行为：每处理完一行，没有用 -n 关闭自动输出时，当前模式空间内容会被自动打印一次；而命中 p 命令的那一行又被p显式打印了一次，重复自然就出现了。
因此，只要用p命令，几乎都搭配 -n 使用：
bash复制sed -n '/error/p' app.log
这条命令的效果和 grep error app.log 非常接近，所以别再拿“为什么sed没有像grep那样安静输出”来困扰自己了。搞清楚这个默认打印机制，你会突然觉得sed的输出行为变得非常有逻辑。
5.2 用sed查指定行号和区间内容
单纯按关键词查询，grep完全够用，但sed的查询还有一种grep很难替代的能力，就是按行号输出特定范围。
比如我只想看文件的第10行到第20行：
bash复制sed -n '10,20p' api.log
只查看最后5行：
bash复制sed -n '$,$p' api.log
不过这里有个更好用的等价写法：如果只是想看文件尾部，tail -n 5 更简单。但sed的优势在于可以从一个大文件中部定位任意连续区间，配合管道时尤其顺手。
例如查看文件里第1000行到1010行：
bash复制sed -n '1000,1010p' huge.log
这种操作如果靠 head -n 1010 | tail -n 11 也能完成，但用sed只用一条命令，逻辑也更直观。在Linux运维里排查大日志时，我经常用这种分行号定位的方法快速定位某段上下文。
要同时打印行号，可以用 = 命令：
bash复制sed -n '/timeout/=' config.conf
这会输出所有包含timeout的行的行号，虽然没有输出行内容，但配合定位再按行号用p打印上下文，是很高效的排查路径。
5.3 查询与管道结合，在无限增长的流上也适用
因为sed是基于流的，它还可以处理非文件类的数据源。比如实时追踪日志并过滤出含error的行再输出，可以这样：
bash复制tail -f app.log | sed -n '/error/p'
这条命令会源源不断处理tail喂给它的新日志行，永远不会因为文件巨大而导致内存溢出。这种“实时管道”场景，vim完全做不到，而sed在这里的响应速度几乎是零延迟。也正因此，我建议把sed当成管道流水线上一个标准零件去用，而不是只把它当文件修改工具。
6. 改：s替换命令，最值钱的其实是分组引用
6.1 替换写法与分隔符
s命令可以说是sed里出现频率最高的一条命令，作用是把匹配到的文本替换成新的内容。
最基本的写法：
bash复制sed 's/old/new/' file
默认情况下s命令只替换每一行中第一个匹配到的old，不是全部替换。 如果一行里有多个old，只有第一个会改变。要处理全部匹配，就必须在命令结尾加 g：
bash复制sed 's/old/new/g' file
g 表示global，全局替换。不加g时s命令的行内单次替换行为，几乎是新手最常踩的坑。如果忘了g，结果就是文件里每个匹配行只改了一部分，看起来像坏掉一样。
当要替换的内容本身包含斜杠时，比如替换文件路径，很多人会被转移字符折磨。其实sed的分隔符不只能是 /，你可以用任意字符作为分隔符。比如替换路径 /usr/local 为 /opt，写成：
bash复制sed 's#/usr/local#/opt#g' file
这样读起来清爽多了。你也可以用 | 或 @，原则是挑一个不会出现在你要查找和替换文本中的字符。这个细节能替你节省大量转义精力。
6.2 & 和 \1：替换时引用匹配内容
有时候我们不光是想把旧文本简单替换成固定新文本，还想“套着原来的内容修改”。sed对此提供了两个有力的引用机制。
第一个是 &，代表整个正则表达式匹配到的内容。比如要把文本中出现的一串数字前后加方括号：
bash复制sed 's/[0-9]\+/[&]/g' data.txt
如果有一行 id: 9527, price: 19，这句命令会把它变成 id: [9527], price: [19]。& 省去了先把原内容捕获再重新拼接的麻烦。
第二个更强大的是正则分组引用，用 \1、\2 来引用第1个、第2个被括号括起来的匹配片段。假设我们想交换日期格式，把 2025-01-15 改成 15/01/2025：
bash复制echo '2025-01-15' | sed 's/\([0-9]\{4\}\)-\([0-9]\{2\}\)-\([0-9]\{2\}\)/\3\/\2\/\1/'
执行结果就是：
code复制15/01/2025
我估计很多人看到这里会被满屏反斜杠吓到，这里必须解释一下背后的规则：sed默认使用基础正则表达式（BRE），基础正则里括号和花括号本身只是普通字符，需要加反斜杠才具备分组和次数约束的功能。 所以 \( 和 \) 表示分组，\{4\} 表示前面的字符恰好重复4次。如果你觉得反斜杠太不友好，可以用 -E 参数切换到扩展正则表达式（ERE），这样写法会简单直观很多：
bash复制echo '2025-01-15' | sed -E 's/([0-9]{4})-([0-9]{2})-([0-9]{2})/\3\/\2\/\1/'
我强烈建议日常工作使用 -E，它和Grep命令的 -E 思路一致，可读性大幅提升。Shell脚本里的sed有 -E 参与后，写复杂替换时，错漏率通常会下降不少。
6.3 分组引用在实际运维里的价值
分组引用不是只能在练习里玩，它在真实场景中特别能解渴。
比如我需要把配置里形如 bind 0.0.0.0:6379 的Redis监听地址，批量规范成 bind 127.0.0.1:6379：
bash复制sed -E 's/bind ([0-9.]+):(6379)/bind 127.0.0.1:\2/' redis.conf
通过分组引用，不需要把整行删掉重新写，只需要捕获到端口部分并复用。
另一个高频需求是从日志里提取URL里的某个参数。假设日志行格式如下：
code复制2025-01-15 10:00:00 GET /api/user?id=1024&name=tom status=200
我只想取id=1024这部分，并改写成大写输出：
bash复制sed -n -E 's/.*\bid=([0-9]+).*/\1/p' access.log
这里把整行替换成捕获到的id字段，然后用p打印出来，效果类似用awk做了字段提取，但写法上其实是sed擅长的一次流式变换。
分组引用的核心思路是：先通过括号把你需要保留或移动的信息“捞”出来，再在替换文本中通过编号引用它。一旦你习惯了这种写法，很多原本需要好几步处理的文本操作，用一条sed就完成了。
7. 增删查改组合实战：Nginx配置和日志数据一起盘一盘
7.1 批量调整Nginx配置片段
还记得文章开头说的批量改Nginx限流和端口场景吗？这里展开讲一下组合用法。假设需要把多个网站的listen端口从8080改成9090，并把server块里所有包含deny 127.0.0.1的注释性策略行直接删除，这两件事如果分两次执行当然可以，但更优雅的是把多个命令写在一个sed里：
bash复制sed -i -E -e 's/listen 8080/listen 9090/g' -e '/deny 127\.0\.0\.1/d' server.conf
-e 是用来串联多个独立的sed命令的。执行顺序是从左到右，先做端口替换，再做行删除。这里有几个值得注意的点：
- 正则里的点号
127\.0\.0\.1使用了转义，因为点号在正则里表示任意字符，不转义可能会误伤其他IP。 - 替换端口前如果确认8080只可能出现在listen行，就不用额外加行地址限制；如果你的服务器配置里其他地方也可能出现8080，建议加上地址限定，比如
/listen/s/listen 8080/listen 9090/g，只对包含listen的行操作。
这种组合用法让sed形成了编辑流水线，一条命令相当于vim里打开文件、执行两步操作、再保存退出，效率差距非常明显。
7.2 日志与CSV文件的清洗：删除空行、按条件删行、提取字段
再说一个日常更常见的文本数据清洗场景。有一份处理后的访问日志文件，可能带着空行、注释行和无关杂项，我需要：只保留包含状态码200或500的行，把其中请求路径字段提取出来，并去掉行与行之间多余的空行。
这个需求如果一步步来，可以先做行筛选：
bash复制sed -n -E '/(status=(200|500))/p' access.log
接着提取请求路径字段：
bash复制sed -n -E 's/.*GET ([^ ]+) .*status=(200|500).*/\1/p' access.log
由于日志可能有非常多行，逐条把数据清洗逻辑写成管道，通常是这样一串操作：
bash复制cat access.log | sed '/^$/d' | sed -n -E '/status=(200|500)/p' | sed -E 's/.*GET ([^ ]+).*/\1/'
你可能会问，为什么不用awk？这个场景用awk当然也可以，但如果只是快速清理一遍并转到下一个任务，sed管道几乎是零思考成本的做法。哪个命令不是看文件而定，多掌握一种工具，在运维现场就意味着多一种解题路径。
7.3 先sed -n回显，再sed -i入库：我这几年养成的作业习惯
前面所有例子，执行后都不改动文件本身。但如果真正要“写入文件”，就需要 -i 参数了。-i 是in-place的意思，直接把修改结果写回原文件。在真实生产环境里，对配置文件执行 -i 操作风险相对较高，一个小数点点错就会导致线上配置被改坏，而Linux里没有后悔药可吃。
我的标准作业流程分为两步：
- 验证阶段：把
sed -i去掉，改为sed -n用p打印出即将受影响的行，或者直接让sed输出处理后的全部内容，确认效果正确。 - 执行阶段：确认命令无误后，再加
-i真正修改文件，并且优先为文件保留备份，比如sed -i.bak ...。这样出错时可以立即mv回滚。
这套流程虽然看起来多“浪费一步”，但在批量管理几十上百个节点时，它能避免绝大多数灾难性误操作。我在给刚入行的同学做指导时，会特别强调：先让程序输出你想要的，再让程序直接修改你不想失去的。
8. sed -i的真正风险和使用边界，手册正面上没告诉你的几件事
8.1 软链接文件在执行sed -i后会变成普通文件
这是生产环境里很容易出大事的一个坑，新手基本不知道，老手偶尔也会翻车。
原因在于：sed -i 不是直接修改原文件，而是创建一个临时文件，把处理结果写入临时文件，最后将临时文件重命名为原文件。这种机制对普通文件没有太大影响，但如果目标文件是一个 软链接（symbolic link），则会打破原来的链接关系。命令执行完后，软链接还在，但它指向的目标文件却不再是原来那个真实文件，你的修改落在了新的普通文件里。如果这个链接是某个应用运行时正在使用的，服务端可能读到旧配置却写不进新配置，引发难以排查的故障。
如果一定要修改软链接指向的真实文件，建议先解析链接的真实路径，再对真实文件执行sed：
bash复制real_file=$(readlink -f /etc/nginx/nginx.conf)
sed -i 's/worker_processes 1/worker_processes 4/' "$real_file"
或者先用 ls -l 确认目标不是软链接，再放心执行sed -i。这个检查环节我基本每次批量操作前都会跑一下。
8.2 使用了 -i 时要不要备份，备份后缀随平台而异
sed -i 本身支持备份机制，需要额外指定后缀。比如 sed -i.bak 's/foo/bar/' file，执行后会产生一个 file.bak 作为修改前的备份。
这里要特别注意：GNU sed和BSD sed对 -i 参数的解析方式不一致。 Linux绝大多数发行版用的是GNU sed，支持 -i 和 -i.bak 两种写法。而macOS自带的BSD sed要求必须提供备份后缀，直接写 sed -i 's/foo/bar/' file 会报错或行为异常。为了解决跨平台兼容性，有几种选择：
- 在Linux服务器上管理时，遵守
-i.bak写法，既能备份又避免在macOS上出问题。 - 在shell脚本里统一判断平台，针对Darwin系统使用
sed -i ''，空字符串表示不保留备份。 - 更彻底的做法是放弃
-i，先输出到临时文件，再统一用mv覆盖原文件。
考虑到这篇文章大量读者是在Linux服务器上操作，我会这样建议：在服务器环境里给sed -i加上备份后缀，在macOS本地做开发测试时了解它和GNU sed的差异，避免把一套命令在两个平台间直接拷贝。
8.3 CRLF换行符会打乱行尾匹配
如果你处理过从Windows上传上来的文件，会发现明明用sed想删除以某内容结尾的行，却怎么都匹配不上。原因通常是文件里的换行符是Windows风格的 \r\n，而行末尾多了一个 \r 光标回退字符，你看到的普通行尾匹配在底层带了特殊字符。
例如这样一个命令：
bash复制sed -i '/end-of-block$/d' win.conf
如果文件行尾是 \r\n，行末尾实际内容不是 end-of-block 而是 end-of-block\r，$ 锚点匹配自然失败。排查办法是先用 file 命令或 cat -A 检查文件是否含有 ^M（即CR字符）。
如果确定是CRLF，可以先把所有 \r 转成一个标记再处理，或者直接在sed命令里匹配CR字符。一个便于跨平台处理的方案，是先用 sed 's/\r$//' 把CR清理掉，再执行其他编辑。在日常运维里，治理这种行尾格式问题其实常常是第一步，不做这一步后面所有正则都可能被隐藏的\r搅乱。
8.4 命令执行顺序、行尾细节：面试官真正想考察的点
结合上面几处，你会发现在Linux面试题里，sed的考察很少停留在“会不会背命令”的层面。面试官更关心你有没有吃透sed的执行机制，是否知道它会自动打印模式空间、是否了解s命令默认只替换第一个匹配、是否清楚d命令会终结当前行的后续处理，以及是否能区分纯 -i 和带备份后缀行为在不同平台上造成的差异。
这些都是没有亲手踩过坑难得来的经验。你光知道 sed 's/foo/bar/g' 能替换文本，但要是遇到批量替换只改了一部分、文件软链接被意外替换成普通文件、Windows换行导致行尾匹配失效这几个问题的时候，才知道sed的细节深度远不止表面看起来那样简单。
从我个人的工作体会来说，sed这套工具给我最大的启发是：不一定要堆很多花哨的命令，把执行模型和一两条核心命令理解透，再灵活组合地址、命令和标志位，已经能解决文本处理领域的一大半问题。 平时在管道里用sed排查日志、在批量配置下发中用sed做标准化处理，我的习惯仍然是先列出计划要执行的行，确认无误再真正让sed修改文件。流式处理决定了它很快，谨慎使用的习惯决定了它不会在关键时刻让你后悔。