ssh.localportforward 连不上因未手动启动监听与转发协程；需用 client.listentcp 绑定 "127.0.0.1:8080" 并对每个 accept 连接调 client.dial 远程目标，注意 defer 关闭和错误日志。
ssh.LocalPortForward 为什么连不上目标服务
本地端口转发失败，常见原因是 ssh.Client 建立后没主动发起隧道连接，只建了 SSH 连接但没调用端口转发逻辑。Go 的 golang.org/x/crypto/ssh 不像 OpenSSH 那样自动处理 -L 行为，必须手动启动监听 + 转发协程。
- 先用
ssh.Dial拿到*ssh.Client，再调用client.ListenTCP绑定本地地址（如"127.0.0.1:8080"） - 对每个
net.Listener.Accept()到的连接，用client.Dial连远程目标（如"10.0.1.5:3306"），然后双向io.Copy - 别漏掉
defer listener.Close()和错误日志——静默失败时往往卡在listener.Accept()或远程client.Dial()超时 - 本地绑定地址写
"localhost:8080"可能被系统解析成 IPv6，导致浏览器访问http://127.0.0.1:8080失败；统一用"127.0.0.1:8080"
ssh.ReversePortForward 如何让内网服务被外网访问
标准库不提供 ReversePortForward，得靠 ssh.NewChannel 手动实现反向隧道：本质是让远端 SSH 服务器监听一个端口，把进来的连接通过已建立的 SSH 通道发回客户端，再由客户端转发到本地服务。
- 远端需开启
GatewayPorts yes和AllowTcpForwarding yes（/etc/ssh/sshd_config），否则sshd会拒绝绑定0.0.0.0:2222 - 客户端调用
client.Listen("tcp", "0.0.0.0:2222")会失败——必须用client.RequestReversePortForward向服务端申请监听，返回的是内部 channel - 拿到
ssh.NewChannel后，立刻ch.Accept()，再用net.Dial("tcp", "127.0.0.1:9000")连本地真实服务，不能直接ch.Write - 注意并发：每个反向连接都要起 goroutine 处理，否则第二个请求会阻塞第一个
crypto/ssh 连接复用与超时控制的实际影响
每次新建 ssh.Client 开销大，但复用不当又会导致连接僵死、端口占用或认证失败。关键不是“能不能复用”，而是“怎么安全地复用”。
-
ssh.Client本身不是线程安全的，多个 goroutine 同时调用client.Dial可能 panic；应封装成带互斥锁的连接池，或每个隧道独占一个client - 设置
ssh.ClientConfig.Timeout只控制握手阶段，不影响后续隧道数据流；真正要防僵死，得在net.Listener层加KeepAlive或用SetDeadline - 用密码认证时，多次转发失败可能触发服务端
MaxAuthTries限制；推荐用私钥 +ssh.PublicKeys，并确保Signer复用同一私钥实例 - 连接断开后，
client.Conn不会自动重连，必须监听client.Conn.Close()事件并重建整个隧道链路
为什么转发 MySQL 或 Redis 时出现协议错乱
二进制协议直传看似简单，但实际容易丢包、粘包或连接提前关闭，尤其在高吞吐或弱网下。这不是 Go 实现问题，而是 TCP 流和应用协议边界不匹配的典型表现。
立即学习“go语言免费学习笔记（深入）”；
- MySQL 协议有 handshake 初始化交互，若客户端连接刚建好就发 query，而服务端还没完成 auth response，就会收不到响应——必须等
io.Copy启动后再触发业务连接 - Redis 的
PING或SELECT命令若发在隧道未 ready 时，可能被截断；建议在Accept()后加time.Sleep(10 * time.Millisecond)等隧道稳定（临时解法） - 不要用
bufio.Scanner处理二进制流，它按行切割，会破坏 MySQL packet header；一律用io.Copy或io.ReadFull - 如果目标服务启用了 TLS（如 MySQL 8.0+ 默认 require SSL），而隧道只是透传 TCP，那 TLS 握手会在隧道层失败，错误信息类似
"tls: first record does not look like a TLS handshake"
反向隧道最难调的永远不是代码，是两端 SSH 服务配置和网络策略的隐式耦合——比如云主机安全组放行了 22 端口，却忘了放开反向监听的 2222 端口，或者公司防火墙拦截了非标准端口的出向连接。
