我最早意识到“程序跑完日志全没了”这个问题是在一个值守脚本上。程序在终端里跑得好好的某一天终端窗口不小心被关掉所有print输出也跟着消失。对开发、测试、运维来说把程序运行打印重定向写进指定文件不是什么炫技操作而是最基础的生存技能。它能解决日志持久化、后台运行排查、错误信息捕获等一系列实际问题。今天这篇东西就把我从命令行到代码层面的各种重定向做法、原理和踩坑记录下来希望对正在被日志问题困扰的人有点帮助。1. 先想清楚一个问题程序输出到底去哪了很多新手写程序默认输出就是“屏幕”。但程序本身其实分得很清楚正常结果走标准输出错误信息走标准错误。终端窗口只是它们默认的展示位置并不是唯一的归宿。重定向的本质就是改变这个“归宿”。1.1 你看到的“打印”不只是print不管用哪种编程语言print、console.log、System.out.println最终都会落到操作系统提供的文件描述符上。Unix和Linux系统里每个进程启动时默认打开三个流标准输入文件描述符0、标准输出文件描述符1、标准错误文件描述符2。你写的print默认输出到标准输出报错堆栈走标准错误这两者默认都指向终端。理解这一点你就能明白命令行的重定向语法为什么长那样。我先用一个简单的方式画一下它们的关系程序有两个管道一个用来输出正常内容一个用来输出错误内容终端只是管道暂时接入的出口。重定向操作就是拔掉原本接往终端的管道把出口换成文件、打印机或者干脆扔进黑洞。1.2 真正需要重定向的场景在网上搜“程序输出重定向”大多数教程会直接甩给你符号表。我先不急着列符号先说清楚什么情况下你非用不可。第一种场景程序运行时间很长你不想全程盯着终端。比如一个数据同步脚本要跑三个小时不可能三小时不锁屏、不断网、不关终端。把输出写进文件过几个小时再来查结果这是最舒服的方式。第二种场景程序在后台运行没有终端可依附。服务器上部署的守护进程、定时任务触发的脚本它们启动时根本不连接终端输出如果没重定向直接被系统丢弃。等出了故障想查线索什么都找不到。第三种场景程序崩溃后终端内容丢失。终端窗口的滚动缓冲区有限程序崩了消息刷屏早期的日志被顶掉你根本找不到崩溃原因。把输出落盘连历史记录都能翻出来。第四种场景需要对输出做二次处理。程序输出JSON格式的监测数据你想把它重定向到文件再用另一个程序去解析。这比从终端复制粘贴可靠得多。理解了这些场景我们对普通重定向的诉求就该列出来了输出能落盘、能区分正常输出和错误输出、文件能追加而不是覆盖、必要时能在后台运行。接下来的内容沿这条线展开。2. Shell重定向的几个符号每一个都对应一种需求命令行里重定向的写法本质上是操作系统里“文件描述符复制”操作的语法糖。理解了每个符号对应的底层操作你才能灵活组合它们。2.1 和 覆盖还是追加是覆盖写 是追加写这是最基础的两个符号。./run.sh output.log这行命令的意思把脚本的标准输出重定向到 output.log如果文件原本有内容全部清除。适合每次运行只保留最新结果。./run.sh output.log这行命令的意思把标准输出追加到 output.log 末尾。适合循环任务、持续运行的守护程序每次输出都累加在同一份日志里。两个符号背后都是调用同一条系统调用链区别只在于打开文件时是否携带截断标志。这个细节决定了生产环境中选哪个想保留完整历史就选 想要干净的最新状态就选 。顺手提一个很常见的坑如果命令行写的是 output.log但程序已经在里面累计了很多数据你却想保留历史别犹豫用。2.2 21标准错误和标准输出的合并只做./run.sh output.log的话你会发现一个尴尬的情况正常输出进文件了但报错信息仍然打在屏幕上。因为 只重定向了标准输出文件描述符1标准错误文件描述符2没被处理。正确的写法是./run.sh output.log 21这行的解析顺序很关键先执行 output.log把标准输出指向文件再执行21把文件描述符2重定向到文件描述符1当前指向的位置也就是同一个文件。为什么顺序不能反过来我试过21 output.log结果不符合预期。因为第二句把标准输出指向文件时标准错误还保持着之前的指向两者最终落到了不同地方。记住合并重定向时先打开文件再合并错误流。等效的还有一种写法./run.sh output.log在 Bash 里相当于 file 21的简写但有些 shell 不支持比如早期的 POSIX sh。为了兼容性我建议在脚本里用完整写法在交互式终端里怎么顺手怎么来。2.3 /dev/null丢弃不需要的输出有些程序输出特别吵比如安装依赖时的进度、每次轮询的提示你一点都不想看到。重定向到 /dev/null 就能“丢进黑洞”./run.sh /dev/null 21这是个很有意思的文件它像一个永远填不满的无底洞。写进去的数据直接丢弃不占磁盘空间。我在实际中通常保留错误输出、丢弃正常输出./run.sh 2 error.log /dev/null这样磁盘里只有错误信息文件排查问题时一眼看重点不用在海量正常日志里捞异常。2.4 重定向在shell脚本里的组合用法实操中很少只用一个符号更多是组合。我举几个常见的组合模板。后台运行并记录完整日志nohup ./server.py logs/server.log 21 定时任务里把输出都收进一个文件*/5 * * * * /home/user/check.sh /home/user/check.log 21启动时想看到输出同时保存一份./run.sh | tee output.logtee相当于一个分叉管数据同时流向终端和文件。适合你想实时观察进度又想留档的场景。它还有个兄弟参数-a追加模式./run.sh | tee -a output.log。这些组合的底层逻辑不难懂文件描述符是可以“复制”和“重新指向”的符号只是调用接口。理解眼前这层程序运行时一切输出都在你的掌控之下。3. 写代码时就埋好重定向逻辑Python项目里的实现命令行重定向能解决“程序已写好运行时怎么处理输出”的问题。但如果你正在开发阶段或者要写一个可能长期运行的服务建议在代码层面就设计好输出落地方案而不是把命运交给调用方。3.1 脚本自身的输出重定向Python里最简单粗暴的玩法是直接替换 sys.stdoutimport sys with open(output.log, a, encodingutf-8) as f: sys.stdout f print(这条消息会写进文件) print(后续所有print都会进文件)这段代码的核心逻辑是把模块里的标准输出对象换成了一个文件对象。此后所有print默认都写进文件而不是终端。但我不太推荐在生产环境用这套原因是它影响全局出了问题不好追踪。更稳的做法是使用标准库的 logging 模块它从设计上就支持多输出目的地、日志级别和轮转等能力。import logging logging.basicConfig( levellogging.INFO, format%(asctime)s - %(levelname)s - %(message)s, filenameapp.log, filemodea, encodingutf-8 ) logging.info(服务启动) logging.error(连接超时)print 和 logging 的区别在于print是“给人看”的临时工具logging是“给程序用”的结构化记录。前者适合调试后者适合生产。如果你是运维一个正在跑的服务我强烈建议直接写logging。3.2 重定向子进程的输出还有一种常见场景你的Python程序去调用另一个命令行程序比如调用ffmpeg转码、调用git拉代码、调用某个编译命令。这时子进程的输出同样需要管理。Python的 subprocess 模块提供了完整方案import subprocess with open(build.log, wb) as f: result subprocess.run( [make, build], stdoutf, stderrsubprocess.STDOUT, textTrue )关键参数是 stdout 和 stderr。给它们传一个文件对象子进程输出就直接进文件传 subprocess.PIPE 则是把输出捕获到内存里便于你自己进一步解析。把 stderr 设为 subprocess.STDOUT是为了让错误信息和正常信息合并到同一个文件方便后续按时间顺序排查。如果想实时读取同时过滤内容可以一行行迭代import subprocess with open(pipeline.log, w, encodingutf-8) as f: proc subprocess.Popen( [python, worker.py], stdoutsubprocess.PIPE, stderrsubprocess.STDOUT, textTrue, bufsize1 ) for line in proc.stdout: f.write(line) if ERROR in line: print(f发现异常{line.strip()}) proc.wait()这套代码的价值在于既保存了完整输出又能实时监控异常。对于依赖第三方命令的自动化流程可以说是标配。3.3 日志格式时间戳、级别与回溯信息写日志文件时格式设计直接决定排查效率。我最开始用 print 裸输出满屏都是孤零零的一句话根本不知道哪条日志对应哪个时刻。后来统一改成 logging 格式包含三样东西时间戳、日志级别、具体消息。import logging import traceback logging.basicConfig( levellogging.DEBUG, format%(asctime)s | %(levelname)-8s | %(message)s, datefmt%Y-%m-%d %H:%M:%S ) try: result 10 / 0 except ZeroDivisionError: logging.exception(计算过程出现异常)logging.exception 会自动把当前的异常堆栈完整写进日志你不用手动调用 traceback.format_exc()。这个细节在我排查线上问题时省了很多力气。不过要注意一点logging模块自身的文件写入也有缓冲问题。如果程序被强杀最后几秒的日志可能来不及落盘。解决方案有两层程序退出时显式调用logging.shutdown()或者在配置项里把 flush 相关参数调到位。性能要求不高的场景推荐每条日志都立即落盘宁可慢一点不能丢关键信息。4. 运行时重定向的进阶方案nohup、文件描述符和日志轮转到了这一步你已经能处理“程序输出写入文件”的基本需求了。但真实生产环境还会问程序能脱离终端存活吗文件会不会无限增长把磁盘撑爆日志太多怎么分类这几个问题分别在下面展开。4.1 nohup 让程序在后台稳定运行之前说过后台运行的程序如果没有重定向输出无处可去。nohup的作用就是让进程忽略挂断信号即使你把终端关了它也能继续跑。标准启动命令nohup python app.py app.log 21 把进程放到后台nohup 让它不随终端退出而退出重定向把输出落盘。三条组合拳下来一个可靠的“守护进程式”启动方式就完成了。这里提醒一个新手常见误区只用不用 nohup可能你还会看到输出。但一旦父进程终端退出子进程可能会收到挂断信号而终止。所以做服务部署时务必把 nohup 加上除非你有 systemd 这类更专业的进程托管工具。进阶一点的偏好是启动后立刻确认进程是否健康nohup python app.py app.log 21 echo $!$!返回的是刚启动的后台进程PID记下它后面要停就用kill PID。这一步在自动化部署脚本里很实用虽然systemd提供了管理能力但在简单场景下nohup方案轻量直接。4.2 文件描述符的前世今生不妨回顾一下0、1、2为什么 0、1、2 这仨数字总在重定向前后出现因为它们是约定俗成的标准文件描述符名称缩写默认指向0标准输入stdin终端键盘1标准输出stdout终端屏幕2标准错误stderr终端屏幕21就是把标准错误指向标准输出此刻的位置。重定向的本质是修改进程内部这张“文件描述符指向表”。这也是为什么很多场景里我们能在同一个文件里同时拿到正常信息和错误信息的根本原因。理解这张表遇到“为什么这个命令输出位置不对”的问题能少踩一半坑。还有一个扩展玩法在shell脚本里自定义文件描述符把某个文件的打开句柄绑定到 3 号文件描述符。这个用途不少见但日常重定向基本用不到。我遇到复杂的日志分流需求时直接用编程语言里的日志库处理很少在shell层面对多描述符做复杂操作。毕竟可读性和维护性比炫技重要。4.3 日志轮转文件不会无限增长只重定向、不轮转时间长了会出事。某个程序每天产生100MB日志一个月就是3GB能把磁盘写满程序直接崩溃。Linux上最常用的轮转机制是系统自带的 logrotate。可以给日志文件配置一个轮转策略。配置文件示例放在/etc/logrotate.d/myapp/path/to/app/logs/*.log { daily rotate 7 copytruncate compress missingok }各参数含义daily每天轮转一次。rotate 7保留最近7份日志文件更早的自动删除。copytruncate先复制当前日志再清空原文件。适合程序持有着文件句柄、不主动关闭的情况。compress轮转后的旧日志用 gzip 压缩大幅节省空间。missingok日志文件不存在时不报错。logrotate的触发由系统定时任务管理配置完成后通常不用重启。需要注意copytruncate的机制它复制和截断之间存在极小的时间窗口可能丢失极少量日志。对于日志丢失零容忍的场景应该在代码里自己实现按大小滚动比如Python logging.handlers.RotatingFileHandler。import logging import logging.handlers handler logging.handlers.RotatingFileHandler( app.log, maxBytes10 * 1024 * 1024, backupCount5, encodingutf-8 ) logger logging.getLogger() logger.addHandler(handler)这段代码的作用日志文件达到10MB自动切割保留最近5份历史。这种进程内控制在Windows和Linux都适用跨平台部署时不依赖系统配置。5. 我踩过的坑缓冲、编码、权限与路径重定向语法再简单也敌不过实际运行环境的复杂性。这几个坑我反复遇到每次都能把新手绕晕。5.1 输出文件是空的缓冲机制在作祟最典型的情况程序在跑日志文件却始终是0字节直到进程退出才看到内容。原因是标准输出默认是全缓冲fully buffered模式只有当缓冲区写满或者进程正常退出时才刷新到文件。Python 中可在启动时关闭缓冲python -u app.py app.log 21-u参数让Python的标准输出、标准错误变成无缓冲模式print 写一条落一条。代价是频繁IO性能略降但日志实时性极佳适合排查观察阶段。程序内部也可以强制刷新import sys print(关键日志) sys.stdout.flush()在print后显式刷新或者每次print时带上flushTrueprint(关键日志, flushTrue)这个参数我记得在Python3.3加入使用起来非常顺手。如果是写服务程序我更推荐在日志模块层面解决而不是每个print手动刷新那样容易遗漏。另一个缓冲场景是管道缓冲。./run.sh | tee file时如果左边程序不刷新tee 可能迟迟看不到内容。同样建议在左边程序里加 flush 或者用stdbuf命令调整。5.2 中文乱码编码不一致日志里的中文变成乱码几乎每个开发者都遇到过。原因通常是程序输出的编码和文件读取时用的编码不一致。比如Python字符串默认是UTF-8但在Windows控制台里显示时可能被转成GBK重定向到文件时又被按GBK写入日志文件打开方式不同就花了。代码层面对策是在打开文件时明确编码with open(app.log, w, encodingutf-8) as f: f.write(中文日志)在 subprocess 重定向子进程输出时也要指定 text 模式的编码subprocess.run(cmd, stdoutf, stderrsubprocess.STDOUT, textTrue, encodingutf-8)Python 3.6之后 textTrue 时会默认采用本地编码跨平台可能导致不一致。显式传 encoding 参数最稳妥。查看已有输出文件编码的第一种方式file app.log它会告诉你文件是 UTF-8 还是 ISO-8859 之类方便判断写和读两端是否对上了。5.3 没权限、路径不存在重定向的边界问题重定向操作最容易被忽略的是目标文件的“前置条件”。比如当前用户对目标目录没有写权限 → bash 执行重定向时报Permission denied。目标目录不存在 → 文件根本创建不出来。目标文件被其他进程占用有锁 → 写入失败。一个安全启动模板LOG_DIR/var/log/myapp mkdir -p $LOG_DIR chmod 755 $LOG_DIR nohup python app.py $LOG_DIR/run.log 21 mkdir -p确保目录存在chmod确保权限合适。放在脚本开头能省掉一半排障时间。还有个罕见但棘手的坑当目标文件是符号链接且链接失效时重定向操作会重建一个新的普通文件。如果程序里引用了链接路径可能给后续日志分析造成误导。我发现这种情况时习惯先ls -l看一眼日志路径的类型。5.4 一个总结遇到日志缺失先这样排查遇到“程序跑了但日志没写进去”我习惯按顺序做这几个检查ps -ef | grep 程序名确认进程还活着。ls -l 日志文件确认文件存在看修改时间是否在变。tail -f 日志文件实时观察是否在写入。检查磁盘空间df -h磁盘满了写入会静默失败。检查缓冲设置确认有没有-u、flush或unbuffered。每次按这套顺序走绝大多数问题都能定位到具体环节。盲目改代码不如先确认数据到底死在哪个环节。6. 结合真实改造案例从print满天飞到规范日志落地理论和坑都说完了我记录一次完整的改造过程。这是我维护模拟项目X时实际走过的路径。虽然项目名和细节做了脱敏但思路完全真实可以复现。6.1 改造前的状态某数据同步程序之前一直直接在终端跑。通过定时任务启动输出全部无规则打印print(开始同步) print(拉取数据成功共1000条) print(写入数据库成功) print(出错了)运维人员发现问题时只能去系统日志里捞程序退出时间再靠猜。有一次某个下游接口超时同步任务连续失败三天居然没人及时发现因为根本没有落盘的错误记录。我给这个程序定的改造目标不是简单加日志文件而是实现“平时不打扰、出事能定位、历史可追溯”的一套输出体系。6.2 改造步骤第一步引入logging规划三种输出目的地。控制台保留info级别方便本地调试文件记录全部DEBUG级别保留最详细信息错误单独写入error.log集中呈现异常。import logging logger logging.getLogger(sync) logger.setLevel(logging.DEBUG) fmt logging.Formatter(%(asctime)s | %(levelname)s | %(message)s) console logging.StreamHandler() console.setLevel(logging.INFO) console.setFormatter(fmt) debug_handler logging.FileHandler(sync_debug.log, encodingutf-8) debug_handler.setLevel(logging.DEBUG) debug_handler.setFormatter(fmt) error_handler logging.FileHandler(sync_error.log, encodingutf-8) error_handler.setLevel(logging.ERROR) error_handler.setFormatter(fmt) logger.addHandler(console) logger.addHandler(debug_handler) logger.addHandler(error_handler)第二步关键操作点埋日志。不是只在开头结尾各打一行而是在每个关键决策点记录状态。logger.info(开始同步任务) try: data fetch_data() logger.info(拉取数据成功共 %d 条, len(data)) except Exception: logger.exception(拉取数据失败) raise logger.debug(数据详情%s, data[:20])logger.debug适合记录想了解但平时不想看的细节。写日志时带上变量值排查问题根本不需要复现看日志就能还原现场。第三步控制错误日志的发送方式。这里不涉及邮件通知但我在做的是错误日志单独文件中一旦产生新内容监控脚本能感知并触发告警。具体可以用文件大小变化作为判断依据。6.3 验证与复盘改造后跑了整整一周有一天深夜日志里出现了一次OOM错误。因为错误堆栈完整写进了 error.log第二天复盘时直接定位到是缓存列表占用内存过多一段代码改了十行就修复了。之前那种“只看status code”的做法根本不可能有这种定位效率。这次改造给我最深的体会日志不是一个文件的事是一套“何时记、记什么、记到哪”的设计。print 满天飞本质上是没有设计想到哪打哪。换成规范日志后能明显感觉到程序变“透明”了出问题不再六神无主。7. 几个我还在用的进阶建议日志从终端走向文件只是第一步。真正常用的人还会做这么几件事。第一给日志文件加时间戳或者按日期分目录。我的偏好是按天分目录LOG_DIRlogs/$(date %Y%m%d) mkdir -p $LOG_DIR nohup python app.py $LOG_DIR/run.log 21 这样排障时直接打开当天目录不会在几十个文件里找最后修改时间。第二关键日志要能“被搜索”。所有日志行尽量保持结构一致时间戳前缀统一放开头。我见过有人把时间戳放末尾grep 关键字的时候整行格式混乱看着就头大。第三不要什么都往一个文件里塞。正常流程和错误堆栈区分开业务日志和技术日志区分开。分类越清楚后续分析效率越高。当然也不需要过度设计两到三个文件足够覆盖日常需求。第四日志清理要趁早规划。每天跑的任务日志保留周期定个 7~30 天比较合理。logrotate 配置好之后基本上一劳永逸千万不要等磁盘报警了才想起来。我在实际使用中还有一个心得除非是极短的调试脚本否则生产环境尽量用 logging 而不是 print。等系统出故障时日志格式的规范程度直接跟你的熬夜程度成反比。程序运行打印重定向进文件听起来是一行命令的功夫但真正做到位背后是对输出的设计、对异常路径的覆盖、对运行环境的预判。这几层都想清楚了程序才算真正“可以交给机器运行”。