go标准库crypto/ssh仅提供ssh通道能力，不实现sftp协议；sftp是运行于ssh之上的独立子系统，需第三方库（如github.com/pkg/sftp）封装rfc 4253/4250协议细节、帧格式、重传与状态同步等。
Go 标准库不支持 SFTP，crypto/ssh 只提供 SSH 连接能力，SFTP 协议层必须靠第三方库补全；直接用 ssh.Client 调 os.Open 或发 scp 命令是错的，既不可靠也不符合协议规范。
为什么不能只用 crypto/ssh 做 SFTP 传输
crypto/ssh 是底层 SSH 通道实现，它能建连接、执行命令、开 shell，但 SFTP 是运行在 SSH 之上的独立子系统（RFC 4253 + RFC 4250），需要协商 channel 类型为 "sftp"，再按二进制帧格式收发 SSH_FXP_OPEN、SSH_FXP_WRITE 等包。手动拼包极易出错，且不处理重传、分块、状态同步等细节。
常见误操作包括：
- 用
ssh.Session.Run("scp -f ...")模拟上传 —— 实际触发的是 SCP 协议，不是 SFTP，服务端行为不一致，ls看不到文件或权限错乱 - 把
*os.File直接写进ssh.Session.Stdin—— 缺少 SFTP 协议头和响应校验，服务端返回SSH_FXP_STATUS错误码（如SSH_FX_FAILURE）但 Go 侧无感知 - 忽略
ssh.Channel的SendRequest返回值 —— SFTP 初始化失败时仍继续调OpenFile，panic 在 nil pointer dereference
推荐用 github.com/pkg/sftp：它是最稳定、文档最全、维护最勤的 Go SFTP 客户端库
它封装了全部协议细节，暴露的是符合 Go 习惯的 io.ReadWriteCloser 和 fs.FS 接口，不用碰字节流。安装只需：
go get github.com/pkg/sftp
关键使用要点：
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 先建
*ssh.Client，再用sftp.NewClient(conn)升级为 SFTP 客户端；别跳过conn.Close()，否则 SFTP client 会卡死 - 所有路径都是相对于用户登录后默认目录的**相对路径**，
client.Open("/home/user/file.txt")会失败，应写"file.txt"或"subdir/file.txt" - 上传大文件务必用
io.Copy+ 显式Close()：dst, _ := client.Create("a.zip")→io.Copy(dst, src)→dst.Close()；漏掉Close()会导致文件写入不完整且服务端句柄未释放 - 下载时检查
err：即使client.Open("x.log")成功，后续Read()可能因网络中断返回io.ErrUnexpectedEOF，不能只判 open 错误
上传中文名文件失败？不是编码问题，是服务端策略限制
SFTP 协议本身强制 UTF-8 编码（RFC 3659），所以 Go 客户端发的中文路径字节流一定是合法 UTF-8。失败原因通常是：
- 服务端文件系统不支持 UTF-8 文件名（如某些旧版 ext3 + locale=en_US.ISO-8859-1）
- 服务端配置了
StrictModes yes且用户主目录权限太松（如 777），OpenSSH 拒绝创建文件 - SELinux 或 AppArmor 拦截了带非 ASCII 字符的路径操作
验证方式：用命令行 sftp -P 22 user@host 手动 put 同名文件，看是否报 Couldn't create file；若同样失败，就是服务端问题，跟 Go 代码无关。
并发上传多个文件时连接复用与超时设置
*sftp.Client 本身是线程安全的，可被多个 goroutine 共享，但每个 Open/Create 操作会独占一个 ssh.Channel。默认最大并发 channel 数由服务端 MaxStartups 控制（常为 10），超过会拒绝新 channel。
实操建议：
- 用
&ssh.ClientConfig{Timeout: 10 * time.Second}控制连接建立时间，避免 DNS 卡住整个 goroutine 池 - 对单个文件传输加 context：用
context.WithTimeout(ctx, 5*time.Minute)包裹io.Copy，防止某次上传 hang 死整个流程 - 不要为每个文件新建
*sftp.Client—— 每次 NewClient 都要走一次 SSH 密钥交换，开销极大；复用一个 client，仅对每个文件建独立*sftp.File - 若需限速，别改 TCP 层，直接包装
io.Reader做 token bucket 限流，SFTP 协议层对此完全透明
真正难调的不是上传逻辑本身，而是服务端的 sshd_config 细节：比如 SFTPSubsystem internal-sftp -u 0002 里的 umask 会影响上传文件权限，而 Go 侧根本收不到这个信息。调试时优先查服务端日志，而不是反复改客户端代码。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
