1. EOF 到底是什么从一个小例子说起我最早接触 EOF是看同事写初始化脚本时满屏幕的cat EOF当时第一反应是“这玩意儿是要读文件直到文件尾吗”后来才搞清楚这里的 EOF 根本不是“文件末尾”的意思它只是一个自定义的分隔符叫 End of File 只是习惯而已本质上你可以把它换成任何一串字符。先看一段最常见的用法cat EOF hello world this is a test EOF执行结果是输出两行字符串。看到这里你可能会觉得“这不就是 echo 吗”别急这只是它的开胃菜。EOF 真正厉害的地方在于它能把多行内容一次性传给任意命令比如生成配置文件、拼接 SQL、给 ssh 传一段远端脚本、往文件里批量写入内容这些都是它最常出现的场景。适合谁来用我觉得只要你平时需要在 Linux 终端里处理配置文件、写部署脚本、批量生成文本那 EOF 就是绕不开的基础技能。它属于那种“看着简单但用不好全是坑”的语法尤其是变量展开、引号处理、层级嵌套这几个点网上能讲透的教程不多这篇文章就把我这几年的实战经验一次说清楚。2. 基础语法与设计思路为什么选 EOF 而不是 echo/printf2.1 heredoc 的完整格式拆解在 Linux 中这种写法有一个正式的名字叫 heredoc中文社区常翻译成“内嵌文档”或“此处文档”。它的完整格式是这样命令 分隔符 内容区 分隔符四个部分缺一不可命令接收标准输入的命令常见的有cat、tee、ssh、python3、mysql等重定向运算符表示“把后面这段文本喂给命令的标准输入”分隔符建议使用大写字母组合比如EOF、END、EOF_MARKER它起一个界标作用内容区你要传入的实际文本可以是配置、脚本、数据甚至是代码。这里有个关键点后面的分隔符在内容区结束后必须原样再出现一次而且必须顶格写在行首前面不能有空格后面除了换行符不能有多余字符。不然 shell 就会一直等输入直到报错unexpected EOF。先说一个小类比方便理解。想象你要寄一个纸箱箱子里放各种杂物箱子上贴一张标签写着“完毕”。箱子就是命令cat杂物就是内容区标签就是结束分隔符。你把想放的东西放好贴上标签这箱货才算完整。 EOF就是箱子的开口最后一个EOF就是那张“完毕”标签。2.2 为什么实战中都爱用 EOF 而不是 echo 拼接很多人写脚本时喜欢用一连串echo来输出多行内容比如echo server_name example.com; /etc/nginx/conf.d/app.conf echo listen 80; /etc/nginx/conf.d/app.conf echo root /var/www/html; /etc/nginx/conf.d/app.conf这种写法有三大痛点一是引号容易打架比如内容里既有单引号又有双引号时echo 命令的转义非常折磨人二是每行都要写一次命令和重定向脚本读起来冗长三是变量混合在引号里时展开规则复杂你以为的字符串到最后可能会被解释得面目全非。而 heredoc 的写法直接把整个文本块当作一个整体处理不用关心每行的转义内容和脚本逻辑分离维护起来一目了然cat /etc/nginx/conf.d/app.conf EOF server_name example.com; listen 80; root /var/www/html; EOF注意这里的是覆盖写如果你写的是cat 那就是追加写。这个细节经常有人踩坑覆盖写会把原文件清空所以重要配置文件建议先备份再操作。3. 三种分隔符写法带引号和不带引号的区别是最大的坑3.1EOF、EOF、\EOF分别代表什么很多教程会告诉你 heredoc 里的变量会展开但实际情况要分三种写法这是整个 heredoc 最容易踩坑也是最重要的知识点。第一种不写引号namenode1 cat EOF hostname: $name date: $(date %F) EOF输出结果hostname: node1 date: 2025-01-15这里$name和$(date %F)都被 shell 展开了。如果你希望变量能自动替换成值用这种写法就行。第二种分隔符加单引号namenode1 cat EOF hostname: $name date: $(date %F) EOF输出结果hostname: $name date: $(date %F)所有内容全部原样输出$、反引号、反斜杠都不做任何解释。这一种在写脚本模板、SQL 语句、配置文件片段时非常实用尤其是内容里包含大量$符号时能帮你避开一堆转义噩梦。第三种分隔符前加反斜杠cat \EOF content: $PATH EOF效果和EOF完全一样都是关闭变量展开。区别只是书写习惯老派运维更喜欢用反斜杠因为少按一次 Shift但单引号更直观可读性更好。我自己一般固定用单引号团队统一风格减少沟通成本。3.2 双引号包裹分隔符是什么效果除了上面三种还有一种写法是EOF比如cat EOF hello $USER EOF双引号包裹分隔符时效果等于不写引号也就是说变量仍然会展开。因为 shell 解析EOF时会把引号去掉剩下的逻辑和不加引号一致。很多新手看到这里容易乱我建议你直接记住一条规律带单引号或反斜杠的全部原样输出不带引号或带双引号的里面的变量、命令替换、转义都会被 shell 处理。这条规律我写在便利贴上贴在显示器边框上用了好几年没出过错。3.3 表格对比三种写法的行为差异为了方便查阅我把三种写法的行为整理成一个对照表建议收藏。写法变量$VAR命令替换$(cmd)反斜杠\适用场景 EOF展开执行转义需要动态生成内容时 EOF不展开不执行原样保留写配置模板、脚本片段 \EOF不展开不执行原样保留等效于单引号版看个人习惯 EOF展开执行转义等效于不带引号版这里特别提醒一句如果你写 shell 脚本给别人用而内容里恰好有$符号比如 systemd 服务文件里的$MAINPID、awk 命令里的$1不包裹单引号的话shell 会先把这些变量展开成空字符串运行结果就会和你预期差得十万八千里。我之前给一个 systemd 写启动脚本就吃过这个亏service 文件里的$MAINPID被展开成了空串服务怎么都启不来。3.4-的写法专门处理 Tab 缩进还有一种变体写法-EOF它只在一种场景下有用内容区里的行首 Tab 会被忽略。注意是 Tab不是空格。什么时候会用到当你把 heredoc 写在函数里时为了提高可读性你可能会把内容区缩进几个 Tabfunction write_conf() { cat /tmp/app.conf -EOF server_name example.com; listen 80; EOF }没有-的情况下行首的 Tab 会被原样写入文件导致配置文件解析失败。加上-之后这些 Tab 会被自动剥离。但有一点要注意如果缩进用的是空格-是不生效的这也是很多人用了-依然报错的原因。我建议函数内嵌 heredoc 时直接统一用 Tab所见即所得不容易出错。4. 几个高频实战场景配置文件、ssh 远程脚本、函数嵌套与命令管道4.1 用 heredoc 批量生成配置文件最经典的场景是生成 nginx、redis、mysql 的配置文件。生成静态配置时推荐带单引号的写法避免变量误展开cat /tmp/nginx_demo.conf EOF server { listen 80; server_name example.com; root /var/www/html; index index.html; location /healthz { return 200 ok; } } EOF如果配置文件里需要动态填入当前环境的 IP 或目录路径那就去掉单引号APP_PORT8080 APP_ROOT/data/www cat /tmp/app.conf EOF server { listen ${APP_PORT}; root ${APP_ROOT}; } EOF注意我用了${APP_PORT}而不是$APP_PORT这是一种好习惯它能明确变量的边界尤其是后面紧跟字母或下划线时能避免 shell 把变量名读错。比如你想要$PORT_8080这个变量但实际 shell 会把$PORT_8080整体当作变量名若变量不存在就替换成空串。4.2 通过 ssh 执行远端 heredoc 脚本运维场景里经常需要把一段脚本传到远端机器执行。heredoc 配合 ssh 的典型写法是这样的ssh user192.168.1.10 EOF echo remote hostname: $(hostname) echo remote user: $(whoami) uname -a EOF这里结尾的EOF在本地 shell 里作为标准输入传给 sshssh 会把它原样送到远端 shell 里执行。由于分隔符带了单引号本地的$(hostname)不会被本地 shell 抢先执行而是传到远端后由远端 shell 执行输出的自然是远端的机器名。如果这里你忘了写单引号本地 shell 就会先执行$(hostname)然后传过去的就是本机的主机名等远端再执行时已经晚了。这种“本地执行还是远端执行”的混淆我在排查线上问题时见过不止一次。再往深一层如果你要在远端执行一段脚本而脚本内部本身又有 heredoc这个时候就要把内层分隔符改名比如ssh user192.168.1.10 EOFOUT cat /tmp/inner.sh EOF echo inner: $HOME EOF bash /tmp/inner.sh EOFOUT外层用EOFOUT里层用EOF两个分隔符必须不同否则 shell 遇到第一个EOF就会以为是外层文本结束了后面的内容全部错乱。这个嵌套技巧在写自动化部署脚本时几乎必用。4.3 函数内通过 tee 和 heredoc 写文件tee在 heredoc 中的价值在于可以同时输出到文件和标准输出一边写配置一边看回显用于调试非常方便setup_app() { local version$1 tee /tmp/app_settings.conf EOF version${version} path/opt/app user$(id -un) EOF }调用setup_app v2.1后终端会重新打印一遍内容而且文件也写好了。tee默认覆盖写如果想追加就加-a参数tee -a /tmp/app_settings.conf EOF extra_flagtrue EOF这段内容会追加到文件末尾不会覆盖原有内容。如果你在函数里用 heredoc建议把结束分隔符顶格不要缩进否则 shell 会一直找不到结束标记。如果想缩进美观就记住前面说的用-这是唯一能解决这种矛盾的原生方案。4.4 通过管道把 heredoc 内容交给命令行工具heredoc 不一定要接cat或tee它本质上就是一段标准输入所以只要命令能读标准输入就能接过来。比如把一段多行数值传给bc做计算bc EOF 1 2 3 * 4 scale2; 10 / 3 EOF输出结果是 3、12、3.33。又比如传到 Python 里执行多行代码python3 EOF for i in range(3): print(fline {i}) EOF这种方式在做快速实验时特别顺手不用专门建文件直接在终端里就能把多行代码跑完。还有一种技巧是配合mysql命令批量执行 SQL比如mysql -u root -p EOF USE app_db; SELECT * FROM users WHERE status1; UPDATE users SET status2 WHERE id1; EOF好处是免去每次敲一行 SQL 都要等响应的问题整个事务在同一个会话里顺序执行调试效率高很多。5. 常见错误与排查技巧我踩过的几个最具迷惑性的坑5.1unexpected EOF的原因和定位方法这是遇到最多的报错。很多人一看到unexpected EOF就以为是系统层面的连接断开了其实在 heredoc 的语境里它往往只是说“shell 没有等到结束分隔符”。常见的触发原因有四个结束分隔符没写结束分隔符行首有空格或 Tab结束分隔符行尾有隐藏字符比如 Windows 换行符\r内容区里的某一行恰好和分隔符同名shell 把它当成结束标记提前收场了。排查方法很简单先看你是不是在交互式 shell 里敲的如果敲完内容后回车终端没返回命令提示符而是继续显示提示符说明 shell 还在等结束分隔符。这时候立刻输入分隔符再回车即可。如果是脚本文件建议用cat -A 脚本名检查行尾是否有^M$这样的符号^M就是 CRLF 换行符处理掉即可。5.2 变量展开“翻车”现场单引号到底该不该加我之前帮同事排查过一个很有意思的案例。他写了一段生成环境变量的脚本cat /tmp/set_env.sh EOF export PATH$PATH:/opt/bin EOF执行后他一看文件发现路径被当前 shell 的 PATH 展开成了超长的一串直接把原来的 PATH 全部复制进去了根本不是他想要的模板效果。原因就是不写单引号时$PATH被剪贴板式地替换了。他的本意是文件里保留$PATH这个变量名编译到目标机器上再展开于是正确的写法应该是cat /tmp/set_env.sh EOF export PATH$PATH:/opt/bin EOF这类问题的本质在于“现在展开”和“以后展开”的取舍。我的习惯是凡是内容里包含$、反引号、\这些特殊字符一律先上单引号包裹分隔符只有确认需要立刻动态生成文本时才去掉单引号。5.3 行尾反斜杠和空格的隐形陷阱heredoc 内容区里如果出现行尾反斜杠比如cat EOF hello \ world EOF输出会变成一行hello world因为反斜杠转义了换行符。有时候你从网页上复制多行文本贴进去每一行末尾残留空格这些空格也会原样写入文件。对 shell 脚本来说行尾空格基本无感但如果是配置文件的 key-value这些空格就会成为万恶之源。建议写完 heredoc 后先执行一遍用cat或sed -n l检查输出是否符合预期尤其是不可见字符。对于关键脚本我会加一段调试开关if [[ $DEBUG 1 ]]; then cat -A /tmp/generated_file fi这样能在不打断脚本的情况下看到隐藏字符排查效率极高。5.4 结束分隔符和后续命令抢行的问题再讲一个经常出现的低级错误。有人在脚本里写cat /tmp/test.txt EOF line1 EOF echo done这样写没问题。但如果你写成cat /tmp/test.txt EOF line1 EOF echo done那echo done就会被当成内容区的一部分写进文件因为结束分隔符必须独占一行其后不能跟任何内容。有的编辑器在自动补全时会把下一个语句拼到同一行就特别容易触发这个问题。遇到文件内容莫名多出一行命令的情况十有八九就是外面编辑器的锅。还有人在 heredoc 结束后马上想做条件判断if true; then cat /tmp/x EOF content EOF fi注意最后的fi必须另起一行不能紧跟在EOF后面。这和上一条同理。5.5 关于docker: unexpected eof的延伸说明很多人看到热搜里有个词“docker: unexpected eof”顺手把锅甩给 heredoc其实这是完全两回事。Docker 客户端报unexpected EOF时大多是和守护进程通信时连接被掐断比如镜像拉取到一半断网、磁盘满了、Docker 服务重启了或者代理层中断了连接。这和 shell 里的 heredoc 报错只是同一个英文短语内核完全不同。这里也提醒一句排查报错时不要光看关键词先确认报错来源是哪个程序。heredoc 的unexpected EOF出现时shell 通常会停在某个提示符Docker 的报错则会带上docker进程名和 daemon 通信相关的上下文。定位错了方向花一晚上也查不出问题。5.6 常见问题速查表现象原因解决方案敲完 heredoc 内容后终端卡在结束分隔符没输入或没顶格输入同名的顶格分隔符文件里的$VAR变成空串分隔符没加单引号改用 EOF文件里的$VAR被本机值替换分隔符没加单引号确认要“以后展开”时改用单引号内层 heredoc 和外部冲突分隔符同名导致提前闭合换一个不同的分隔符如EOFOUT函数里 heredoc 内容带 Tab模式会保留 Tab改用-配合 Tab 缩进结束分隔符后带空格文件内容多出多余内容保证结束符独占一行且无尾随字符内容区本来是原始文本却被转义行尾反斜杠触发了续行用 EOF或删除行尾反斜杠脚本在 Windows 上编辑过导致报错换行符为 CRLF用sed -i s/\r$//转换6. 关于命名规范和脚本安全的个人建议最后再说几个我养成的习惯虽然不算语法硬性要求但在多人协作或上线部署时能省去很多麻烦。第一分隔符不要只用EOF一种。一个脚本里如果只有一个 heredoc用EOF没问题一旦有嵌套建议按层级取名比如EOF_HEAD、EOF_BODY、EOF_TAIL或者EOFOUT、EOFIN这样看 log 时能快速定位是哪个段落出问题。我见过所有 heredoc 都用EOF的脚本改一次配置要找半天。第二写脚本前先确认当前 shell 是 bash 还是 sh。虽然 heredoc 是 POSIX 标准支持的但here string 以及某些数组特性在 sh 下可能不工作。如果你写的脚本用#!/bin/bash开头那就全程按 bash 的规则来如果环境里只有sh就尽量避开那些高级特性减少兼容性风险。第三把 heredoc 当作“模板系统”来用。需要重复生成的配置或代码文件完全可以用一个带单引号的 heredoc 当模板再用sed或envsubst做变量替换产出最终的动态文件。这种“模板 替换”的玩法在大规模批量部署时非常好用比起逐个文件手工改既快又稳。第四生产环境脚本执行前先做语法检查。heredoc 本身不会直接导致语法错误但它生成的内容如果是要继续执行的脚本可能会引入脏字符。习惯性在写完脚本后跑一遍bash -n和shellcheck能在上线前拦截掉很多低级错误。我自己的流程是先在终端里手动执行一遍 heredoccat看一眼输出再进到生成文件里确认无误最后才把这套脚本同步到部署任务里。多花一分钟验证能避免一次莫名其妙的线上事故。这算是我在这上面付出过不少学费之后总结出来最实用的一点经验。