sed -i 后符号链接变成普通文件：原地编辑会替换路径

对配置文件的符号链接运行 sed -i，替换后的内容能看到，链接却变成了普通文件，原目标文件仍是旧内容。对于 GNU sed，这符合默认原地编辑方式：输出写入临时文件，再用临时文件替换命令行指定的路径。

先确定你要修改链接指向的共享文件，还是有意在这个路径建立独立副本。两者结果不同，不能因为文件名没变就认为文件关系也没变。下面按 GNU sed 在支持符号链接的 Linux 文件系统上的行为说明，BSD 或其他实现需核对自己的选项。

看链接本身，再看实际目标

操作前可以检查文件类型与链接文本。路径仅作示例：

ls -l ./app.conf
readlink ./app.conf

readlink 的结果可能是相对路径，应按链接所在目录解释，而不是随意拼到当前目录下面。多层链接还需要继续核对最终目标，确保不会越过预期目录改到另一份配置。

编辑后 app.conf 已是普通文件时，再查看原来记录的目标路径。默认 -i 可能只替换链接所在的路径；其他指向原目标的链接仍然读取旧内容，这就会出现“这个入口配置已改，其他服务还没改”的分歧。

这个现象与 sed 的匹配表达式是否成功是两个判断。先核对文件关系，再对比真正要修改的内容；不要继续对多个入口批量执行 -i，希望它们自动恢复成链接。

确实要保留链接，并修改它最终指向的文件时，可使用 GNU sed 的 --follow-symlinks。这个选项只有与 -i 配合时才有作用。

下面是将配置中的 old-value 换成 new-value 的示例，先检查匹配范围、记录链接文本并独立备份目标文件：

sed --follow-symlinks -i 's/old-value/new-value/g' ./app.conf

备份应保存目标的实际内容和需要恢复的权限信息，同时单独记录符号链接指向哪里。不要把一份只有链接的备份当成目标内容备份；已有备份路径也不能随意覆盖。应用共享该目标时，所有读取该目标路径的使用者都可能受影响。

该选项保证的是沿符号链接找到最终编辑路径，并不把 -i 变成对原 inode 的原地字节写入。最终文件仍通过临时文件替换，硬链接关系、正在打开旧文件的进程及其他文件属性需要另行评估，不能宣称保留了一切关联。

不带 -i 的 sed 会读取链接目标并把处理结果写到标准输出。可先将输出保存到独立、未占用的文件检查；不要写成 sed ... app.conf > app.conf，shell 重定向可能先截断输入路径指向的内容。

先确认脚本实际使用的是哪个 sed，包括 PATH、容器镜像和执行平台。GNU 扩展并不保证存在于系统自带的 BSD sed。不同实现的 -i 参数与备份后缀写法也有差异，不能仅凭命令没有明显报错就推断链接被保留。

如果工具没有跟随链接的选项，可以在受控脚本中先解析并审核最终目标，再对这个明确的普通文件编辑。解析与编辑之间若有其他程序能修改链接或路径，就存在竞争；涉及共享或不可信目录时，需要通过权限和部署流程约束，不能把一次 readlink 当作全过程保证。

不要把其他实现里的 -c 当作可移植修复。当前 GNU sed 应使用有明确语义的 --follow-symlinks，而不是依赖一个含义不同或不受支持的参数。

此时有两个对象需要处理：链接原目标，以及现在占据链接路径的普通文件。先分别保留它们，确定新内容应该迁回原目标、保留成独立文件，还是回退本次替换。不要直接删除新文件重建链接，否则可能丢掉本次有效修改。

重新建立链接前核对原链接文本，尤其是相对路径，并确认目标存在且内容符合决定。恢复链接只恢复了文件关系，不会自动把新文件里的修改合并到原目标。

涉及服务配置时，先验证新配置，再按该服务支持的流程加载。修改磁盘文件不证明运行中的服务已经读取它；需要同时核对链接类型、最终目标内容与服务实际行为。

完成标准是原入口仍是预期的符号链接、正确目标包含批准的变化、其他共享使用者得到预期结果，备份仍可恢复。回退也要分别恢复链接关系和目标内容，不能只恢复其中一个文件名。