net.conn 读写不能直接套用 http 模式，因 telnet 是无边界的裸 tcp 流，需手动处理超时、iac 协商、串行命令及设备首条命令延迟。
为什么 net.Conn 读写不能直接套用 HTTP 模式
Go 的 Telnet 协议交互本质是裸 TCP 流，没有请求/响应边界、没有状态码、不自动断连。你用 http.Client 或照搬 json.Marshal + io.WriteString 往里塞数据，大概率卡死或收不到回显。
- 服务器可能不发换行符，
bufio.Scanner默认按\n切分就永远等不到“一行” -
conn.Write()成功只表示数据进了内核发送缓冲区，不代表对方已收到或已处理 - 很多嵌入式设备 Telnet 服务只支持单次连接处理一个命令，发完不主动
conn.Close()，下次连接会被拒绝
怎么安全读取 Telnet 命令响应（避免阻塞）
别依赖 ReadString('\n') 或 Scanner.Scan() —— 设备输出可能无结尾符，也可能分多次 TCP 包到达。必须自己控制超时和缓冲区边界。
- 用
conn.SetReadDeadline()配合循环conn.Read()，每次最多读1024字节，拼到[]byte切片里 - 检查响应是否含提示符（如
#、$、>）或命令回显开头，作为“响应结束”信号，而非等 EOF - 如果 3 秒内没匹配到任何有效标识，就中断读取，返回当前已收内容 —— 这比无限等待更符合运维真实场景
// 示例：带超时的响应读取
conn.SetReadDeadline(time.Now().Add(3 * time.Second))
var buf []byte
for {
b := make([]byte, 1024)
n, err := conn.Read(b)
buf = append(buf, b[:n]...)
if err == io.EOF || bytes.Contains(buf, []byte("# ")) {
break
}
if netErr, ok := err.(net.Error); ok && netErr.Timeout() {
break
}
}
telnet 协议协商字符（IAC）怎么处理才不乱码
真 Telnet 服务会发 \xFF（IAC）开头的协商指令，比如 \xFF\xFB\x01（WILL ECHO），如果你原样转发给前端，浏览器会显示乱码，甚至破坏 JSON 结构。
- 绝大多数管理后台不需要实现完整 Telnet 协议栈，直接忽略 IAC 序列更简单可靠
- 在读取原始字节流后，用
bytes.ReplaceAll(buf, []byte{0xFF}, []byte{})清掉所有\xFF及其后续 2 字节（IAC 总是 3 字节序列） - 如果设备要求必须应答（极少见），至少要识别
\xFF\xFD（DO）并回复\xFF\xFB（WILL），否则可能被静默断连
并发执行多条 Telnet 命令时连接怎么复用
Telnet 不是 HTTP，没有 Keep-Alive 概念。同一连接串行发多条命令可以，但并发写（goroutine 同时 Write）会导致命令粘连、响应错位。
立即学习“go语言免费学习笔记（深入）”；
- 对单台设备，用一个
sync.Mutex保护conn.Write()和读取逻辑，确保命令严格串行 - 不要为每条命令新建连接 —— 多数嵌入式设备最大连接数 ≤ 2，频繁建连会触发限速或拒绝服务
- 如果要批量操作 N 台设备，每个设备用独立连接 + 独立 goroutine，而不是一个连接上起 N 个 goroutine
Telnet 交互里最易被忽略的，是设备对「连接建立后首条命令前是否需要等待」的差异 —— 有些要 time.Sleep(500 * time.Millisecond)，有些一连上立刻发命令就丢包。这个延迟得实测，没法靠协议推导。
