paramiko.exec_command()无法获取实时输出是因为其默认采用执行完毕后读取方式，stdout/stderr为缓冲流，需手动轮询channel.recv_ready()判断数据到达，且不支持自动非阻塞读取。
paramiko.exec_command() 为什么拿不到实时输出
因为 exec_command() 默认走的是“执行完再读取”路径，stdout/stderr 是缓冲式流，不主动轮询就卡在那儿。它不会自动监听 channel 是否有新数据到达，更不会帮你做非阻塞读取。
常见表现：命令已执行完毕（比如 ping -c 1 google.com），但 stdout.read() 一直阻塞，或返回空字符串；shell.send() 发了命令，却等不到回显。
- 必须手动调用
channel.recv_ready()判断是否有可读数据 - 不能依赖
read()一次性收全——尤其对交互式设备（如华三、Cisco），“分段吐数据”是常态 - 如果没设超时，
recv()可能永远挂起（比如设备卡在 pager 提示符--More--）
invoke_shell() 下命令发出去了但没回显，怎么办
这是伪终端（PTY）没配好或 Shell 初始化失败的典型信号。你看到光标不动、敲键无反应、shell.recv() 返回空或乱码，大概率不是网络问题，而是远端没真正进入交互式 Shell 环境。
关键检查点：
立即学习“Python免费学习笔记（深入）”；
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
- 确认调用了
shell.get_pty()（或transport.open_session().get_pty()），否则远程进程没有 TTY，.bashrc里的stty设置、readline初始化全失效 - 发完命令后要加换行符：
shell.send('dis cu\n')，缺\n就像人敲完命令不按回车 - H3C/Cisco 类设备默认开启分页，需先发
screen-length disable或terminal length 0，否则卡在--More-- - 某些设备（如老版本 H3C）对 TERM 类型敏感，可显式设置：
shell.get_pty(term='vt100')
解码后还是空白或双换行，怎么清理控制字符
拿到的原始字节流里混着大量终端控制序列：\r（回车）、\x00（空字符）、ANSI 转义序列（如 \x1b[2K 清行）、设备 banner 中的不可见填充符。直接 .decode('utf-8') 会保留这些，导致打印为空白或错位。
实用清洗逻辑：
- 先
.decode('utf-8', errors='ignore')避免解码失败中断 - 用
.replace('\r', '')干掉回车（xterm.js 等前端不处理\r） - 用
.replace('\x00', '')去掉空字符（常见于 H3C 设备回显开头） - 用正则
re.sub(r'\x1b\[[?0-9;]*[a-zA-Z]', '', s)清 ANSI 序列（如需保留颜色可跳过） - 最后
.strip()去首尾空白——但别用.splitlines()后 join，容易吃掉中间空行
为什么 exit_status 是 0 却拿不到 stdout，或者 stderr 为空但命令明明失败了
这不是 paramiko 的 bug，而是底层 Unix 进程的 I/O 设计：标准输出和标准错误是两个独立管道，且退出码与输出内容无必然绑定。有些命令（如 grep 找不到匹配时不输出任何内容但返回 1）就属于“静默失败”。
可靠做法是三路并行检查：
- 用
channel.recv_ready()和channel.recv_stderr_ready()分别轮询两路输出 - 调用
channel.recv_exit_status()必须放在所有 recv 循环结束后——提前调可能返回 -1（未结束） - 如果
stderr为空但exit_status != 0，不要直接返回空错误信息，至少拼一条提示：f'Command failed with exit code {exit_status}' - 对无输出但需确认成功的场景（如
touch /tmp/test），只依赖exit_status == 0即可，不必强求 stdout 非空
最易被忽略的一点：很多网络设备的 CLI 命令（比如 H3C 的 display version）根本不走标准流——它们把输出直接写到当前 TTY，而 paramiko 的 channel 只捕获子进程 stdout/stderr。这种情况下，唯一可靠的方式是用 invoke_shell() + 主动发送 + 持续 recv，而不是 exec_command()。
