最直接的方式是在终端运行python脚本，print()输出和错误信息会默认显示在终端；2. 使用ide（如vs code、pycharm）可在内置控制台查看输出，便于调试；3. 通过i/o重定向将输出保存到文件，如python script.py > output.txt；4. 使用logging模块实现结构化日志记录，支持分级输出和日志管理；5. 若脚本无输出，可能因缓冲未刷新、异常中断、输出被重定向或print语句未执行；6. 生产环境不应依赖print()，应使用logging避免污染输出流；7. 处理大量或持续输出时，可结合less、tail -f命令分页或实时追踪日志文件；8. 启用日志轮转（rotatingfilehandler）防止日志文件无限增长。
运行Python脚本时想看它到底在干嘛，最直接的方式就是观察终端窗口。Python脚本默认会将
print()函数输出的内容，以及一些错误信息，直接发送到标准输出（stdout）和标准错误（stderr）流，而这些流通常都会直接显示在你运行脚本的那个命令行界面上。所以，绝大多数时候，你只需要在终端里执行
python 你的脚本名.py，就能看到它在运行过程中打印出来的所有东西。
解决方案
要查看Python脚本的执行输出，我们有几种常用且有效的方法，它们各有侧重，满足不同场景的需求。
首先，最基础也是最常用的，就是直接在命令行终端运行脚本。当你敲下
python your_script.py后，脚本内部所有
print()语句输出的内容，以及任何运行时产生的异常或错误信息，都会即时地显示在你的终端屏幕上。这是最直观、门槛最低的方式，适合日常开发和快速调试。
立即学习“Python免费学习笔记（深入）”；
# my_script.py
print("脚本开始执行...")
for i in range(3):
print(f"当前迭代：{i}")
# 假设这里可能有个错误
# print(1/0)
print("脚本执行完毕。")在终端里运行：
python my_script.py你会看到：
脚本开始执行... 当前迭代：0 当前迭代：1 当前迭代：2 脚本执行完毕。
其次，如果你使用集成开发环境（IDE），比如PyCharm、VS Code或者Jupyter Notebook，它们通常会提供一个内置的输出窗口或控制台。在这些环境中运行脚本，所有的标准输出和错误输出都会被捕获并显示在对应的面板里。这对于大型项目或需要调试的场景非常方便，因为IDE通常还集成了调试器，可以让你逐行查看代码执行，并观察变量状态。我个人很喜欢VS Code的集成终端，它让开发流程变得很顺畅，输出和代码在一个界面里，切换上下文的成本很低。
再者，当输出内容很多，或者你需要将输出保存下来以供后续分析时，重定向输出到文件就显得尤为重要了。通过操作系统的I/O重定向功能，你可以将标准输出
>或标准错误
2>甚至两者
&>重定向到一个文本文件中。
将标准输出重定向到文件：
python my_script.py > output.txt这样，
my_script.py中所有
output.txt文件，而不会显示在终端。
将标准错误重定向到文件：
python my_script.py 2> error.log如果脚本报错，错误信息会写入
error.log。
同时重定向标准输出和标准错误到同一个文件：
python my_script.py &> full_output.log或
python my_script.py > full_output.log 2>&1这两种方式都能将所有输出（包括正常输出和错误）都捕获到
full_output.log中。这对于自动化任务或后台运行的脚本尤其有用，毕竟你不可能一直盯着终端看。
最后，对于更复杂的应用，特别是那些需要长时间运行、有不同级别信息（如调试信息、警告、错误）的程序，Python内置的logging
模块是你的不二之选。
logging模块提供了比
# advanced_script.py
import logging
# 配置日志
logging.basicConfig(level=logging.INFO, format='%(asctime)s - %(levelname)s - %(message)s')
logging.debug("这是一条调试信息，通常不会显示，除非级别设置为DEBUG")
logging.info("脚本开始处理数据...")
try:
result = 10 / 2
logging.info(f"计算结果：{result}")
# result_error = 10 / 0 # 故意制造一个错误
except ZeroDivisionError as e:
logging.error(f"发生错误：{e}", exc_info=True) # exc_info=True 会打印完整的堆栈信息
logging.warning("处理完成，但可能存在一些小问题。")运行
python advanced_script.py，你会在终端看到类似：
2023-10-27 10:30:00,123 - INFO - 脚本开始处理数据... 2023-10-27 10:30:00,124124 - INFO - 计算结果：5.0 2023-10-27 10:30:00,125 - WARNING - 处理完成，但可能存在一些小问题。
如果发生错误，错误信息会以更结构化的方式被记录。这种方式在生产环境中是不可或缺的，它能让你更好地追踪应用程序的行为和问题。
为什么我的Python脚本没有输出？
这是一个非常常见的困惑，尤其对于初学者。我见过太多次，代码明明写了
一个可能是输出被缓冲了。Python的
sys.stdout.flush()），内容才会被真正输出。如果你在脚本运行过程中期待实时看到输出，但又没有，这可能就是原因。一个简单的测试方法是在
flush=True，例如
print("Hello", flush=True)。
另一个常见情况是，脚本执行过程中发生了未捕获的异常，导致程序提前终止。当Python脚本遇到一个它不知道如何处理的错误时，它会抛出一个异常，并默认将错误信息（包括堆栈跟踪）打印到标准错误流（stderr），然后退出。如果你只关注标准输出，或者错误信息一闪而过，你可能就会误以为没有任何输出。有时候，终端滚动太快，错误信息确实容易被忽略。这时候，我通常会尝试将标准错误也重定向到文件，或者在IDE中运行，IDE的输出窗口通常会保留所有输出，包括错误。
还有一种可能，是输出确实存在，但被重定向到了你没注意到的地方。就像前面提到的，如果你在命令行中使用了
>或
2>这样的重定向符号，那么输出就不会在终端显示，而是默默地写入了文件。如果你不小心在某个地方配置了日志系统，将
最后，也是最简单的一种情况，就是你的脚本里压根就没有 print
语句，或者 print
语句所在的逻辑分支根本没有被执行到。比如，一个
if条件块里，而这个条件从未满足；或者在一个函数里，但这个函数从未被调用。这时候，最直接的办法就是用调试器单步执行代码，或者在关键位置多加几个
什么时候不应该只用 print()
查看输出？
print()函数无疑是Python开发者最常用的调试工具，它简单、直接。但说实话，在某些场景下，仅仅依赖
print()就不那么合适了，甚至会带来一些麻烦。
一个明显的例子是生产环境中的应用程序。想象一下，一个服务器上的Web应用，如果它还在到处
print()调试信息，那这些信息要么会污染Web服务器的日志，要么会因为没有被捕获而丢失，这都不是我们希望看到的。生产环境需要的是结构化、可控的日志，能够区分信息级别（比如是调试信息、普通信息、警告还是致命错误），并且能够方便地输出到文件、日志服务甚至监控系统。这时候，
logging模块就是不二之选。它能让你在不修改代码的情况下，通过配置来调整日志的输出级别和目的地，这对于维护和排查问题至关重要。
再比如，当你的脚本需要处理大量数据，或者运行时间很长时，
print()的局限性就暴露出来了。大量的
logging模块将不同类型的信息记录到不同的日志文件，显然更合理。你可以用
tail -f这样的命令实时跟踪日志文件的最新内容，或者在脚本结束后慢慢分析完整的日志文件。
还有，当你的脚本是作为其他程序的一个组件，或者通过管道（pipe）与其他程序交互时，
print()可能会干扰正常的输入输出流。在这种复杂的系统集成场景中，明确哪些是程序的“正常”输出，哪些是调试信息，就变得非常重要。
logging允许你将调试信息和正常输出分开处理，避免了混淆。例如，一个脚本可能通过标准输出返回JSON数据，而所有的内部调试信息则通过日志系统写入一个单独的文件，这样就不会污染JSON输出。
如何处理大量或持续的输出流？
面对大量或持续的Python脚本输出，直接在终端里滚动查看确实不太现实，体验也很差。我们需要一些更高级的技巧来有效地管理这些信息。
首先，最基础但实用的方法是结合操作系统的管道（pipe）命令。如果你在Linux/macOS环境下，或者Windows的WSL/Git Bash中，
less或
more命令是你的好帮手。它们允许你分页查看文本内容，而不是让所有内容一股脑地冲出来。
python my_long_output_script.py | less
这样，脚本的输出会被管道传输给
less命令，你就可以用空格键向下翻页，用
b键向上翻页，用
/搜索特定内容，或者按
q退出。这对于一次性生成大量日志的脚本非常有效。
对于那些会持续产生输出的脚本，比如一个长时间运行的服务或者一个实时监控工具，tail -f
命令就显得不可或缺了。你需要先将脚本的输出重定向到一个文件，然后用
tail -f命令来实时“追踪”这个文件的末尾内容。
python my_daemon_script.py > daemon_log.log 2>&1 &(在后台运行，并将所有输出写入文件) 然后，在另一个终端窗口：
tail -f daemon_log.log
tail -f会持续显示
daemon_log.log文件中新增的内容，就像看直播一样。这对于调试后台服务或观察长时间运行的批处理任务非常有用。如果是在Windows的PowerShell里，你可以用
Get-Content -Path .\daemon_log.log -Wait达到类似的效果。
此外，当涉及到持续输出时，我们还需要考虑Python的输出缓冲机制。默认情况下，Python的stdout是行缓冲的（当输出到终端时），或者块缓冲的（当输出重定向到文件时）。这意味着，内容可能不会立即写入文件，而是累积到一定量或遇到换行符才写入。如果你的脚本输出频率不高，但又希望立即看到，可以使用
flush=True参数在
print()函数中强制刷新缓冲区，或者使用
sys.stdout.flush()。
import time
import sys
for i in range(5):
print(f"处理中... {i}", flush=True) # 立即输出
time.sleep(1)对于更专业的日志管理，特别是当你的程序规模越来越大时，引入日志轮转（Log Rotation）的概念就很有必要了。如果一个脚本持续运行并写入同一个日志文件，这个文件会无限增长，最终耗尽磁盘空间。
logging模块本身不支持日志轮转，但你可以结合
logging.handlers模块中的
RotatingFileHandler或
TimedRotatingFileHandler来实现。它们可以根据文件大小或时间间隔自动创建新的日志文件，并删除旧的日志文件，从而有效地管理日志文件的生命周期和磁盘占用。
import logging
from logging.handlers import RotatingFileHandler
import time
# 配置日志轮转，最大1MB，保留3个备份
handler = RotatingFileHandler('app.log', maxBytes=1*1024*1024, backupCount=3)
logging.basicConfig(level=logging.INFO, handlers=[handler], format='%(asctime)s - %(message)s')
for i in range(100000): # 模拟大量输出
logging.info(f"这是一条日志信息，当前计数：{i}")
time.sleep(0.01)这样，即使脚本持续运行，
app.log文件也不会无限膨胀，而是在达到一定大小后自动创建
app.log.1,
app.log.2等备份文件。这对于生产环境中的长时间运行服务是标准实践。
