Golang中函数调用内返回SSH客户端命令输出及延迟关闭SSH资源的实现

Golang中函数调用内返回SSH客户端命令输出及延迟关闭SSH资源的实现 我正在处理一些代码，这些代码返回一个用于数据提取的 io.Reader，而不是将完整输出作为字节切片返回，因为对于非常大的数据，后者会占用更多内存。

对于这个问题，它是针对 SSH 客户端接口提出的，但也可以适用于任何其底层资源在某个时刻会被关闭的读取器。

示例测试/演示代码：Go Playground - The Go Programming Language。它在我的计算机上本地运行，也可以在 Go Playground 中运行，不过有时 Playground 沙箱环境的执行会失败。我之前也针对真实的 SSH 连接测试过代码，而不仅仅是使用这个使用测试/模拟 SSH 服务器的演示代码，但在这里展示此代码更容易进行演示。

package main

import (
	"fmt"
	"io"
	"net"

	"github.com/metarsit/sshtest"
	"golang.org/x/crypto/ssh"
)

func main() {
	addr := "localhost:2222"
  // 对于真实的演示，数据理想情况下应该是几百 MB 大小的非常大的字符串或字节数组
	data := "supposedly some very large data being streamed for I/O processing"

	// 初始化虚拟测试服务器，以连接到正在测试的 SSH 客户端相关代码
	hp := sshtest.NewHoneyPot(addr)

	// 在后台启动服务器
	go func() {
		hp.ListenAndServe()
	}()
	defer hp.Close()

	hp.SetReturnString(data)

	// 初始化 SSH 客户端依赖项，以测试执行命令和获取输出流
	cfg := &ssh.ClientConfig{
		User: "jdoe",
		Auth: []ssh.AuthMethod{
			ssh.Password("secret"),
		},
		HostKeyCallback: ssh.HostKeyCallback(
			func(hostname string, remote net.Addr, key ssh.PublicKey) error {
				return nil
			},
		),
	}

	outs, err := runSshCommand(addr, cfg, "echo \"hello world!\"")
	if err != nil {
		fmt.Printf("%v\n", err)
    return
	}
	//result, err := io.ReadAll(outs)
  result := make([]byte, 20) // 演示对读取器进行任意的部分读取
  // 注意/待办：当完全读取返回的 "outs" 读取器
  // 花费很长时间时会发生什么？SSH 会话或客户端连接是否会在
  // 远程端关闭并导致流读取失败？
  //
  // 更重要的是，`runSshCommand` 函数内部对会话和客户端的延迟关闭
  // 是否会影响调用方在函数已经返回但读取器尚未被
  // 完全读取的情况下对返回流的读取？从这个简单的
  // 演示来看，后一种情况似乎没有影响？
  _, err = io.ReadFull(outs, result)
	if err != nil {
		fmt.Printf("%v\n", err)
    return
	}
	fmt.Printf("main/caller output:\n%s\n", result)
}

func runSshCommand(addr string, cfg *ssh.ClientConfig, cmd string) (io.Reader, error) {

  client, err := ssh.Dial("tcp", addr, cfg)
	if err != nil {
		return nil, fmt.Errorf("Create client failed %v", err)
	}
	defer client.Close()

	// 打开会话
	session, err := client.NewSession()
	if err != nil {
		return nil, fmt.Errorf("Create session failed %v", err)
	}
	defer session.Close()

	stderr, err := session.StderrPipe()
	if err != nil {
		err = fmt.Errorf("cannot open stderr pipe for cmd '%s': %s", cmd, err)
		return nil, err
	}

	stdout, err := session.StdoutPipe()
	if err != nil {
		err = fmt.Errorf("cannot open stdout pipe for cmd '%s': %s", cmd, err)
		return nil, err
	}

	err = session.Run(cmd)
	if err != nil {
		err = fmt.Errorf("cannot run cmd '%s': %s", cmd, err)
		return nil, err
	}

	combinedOutputStream := io.MultiReader(stdout, stderr)

	return combinedOutputStream, nil
}

当我最初处理这段代码时，我不确定其运行结果（我的同事也有同样的想法，我们稍后会谈到），但示例代码确实可以工作。当我在工作中发布类似的代码进行审查时，一位同事提出了一个问题：io.Reader 的底层来源是 SSH 会话的 stdout，而被调用的函数对 SSH 资源（会话和客户端连接）有延迟关闭语句，那么在函数退出时，这些延迟关闭不会导致与返回的读取器关联的 stdout 被关闭（从而导致我们无法读取数据）吗？

因此，这里代码审查的问题是：

• 为什么示例代码仍然有效？我和我的同事是否对 stdout 相对于 SSH 客户端会话的运作方式有错误的假设？
• 在什么条件下代码会失效？如何修改示例以突出有问题的场景？

我假设一种思路是返回或传回对被关闭资源的引用，以便在从关联的读取器读取完数据或出错时根据需要关闭它们，而不是在被调用函数内部延迟关闭。这可能会让你认为，当传回给调用者时，读取器会超出作用域。但我认为这样做可能会让调用者变得繁琐和复杂，因为他们还必须管理关闭操作，并可能需要进行某种异步处理。在函数只是简单地读取所有 stdout 数据并返回一个字节切片而不是读取器的简化情况下，所有这些都不需要担心，但这是以消耗内存为代价来换取简化。

当您想要读取/传输大量数据（例如通过 SSH）但又不想在此过程中占用内存（或临时文件和磁盘空间）时，我们尝试使用像 io.Reader 接口这样的其他方式，对于这种情况，Go 的最佳实践是什么？我的方向对吗？还是有其他方法可以做到，或者我可以在这里进行一些改进？