为什么 textproto.NewReader 读不到完整的 Telnet 响应？
因为 textproto.NewReader 默认按行（\n 或 \r\n）切分，而 Telnet 协议本身不强制用换行分隔消息，服务端可能直接发二进制控制字节（如 \xff\xfb\x01 表示 WILL ECHO）、无换行的提示符（如 Login:），甚至连续写入不带分隔的多段数据。ReadLine 会卡住或提前截断。
- 别用
ReadLine()接收 Telnet 交互中的任意响应，它只适合纯文本、严格换行分隔的协议（如 SMTP） - 改用底层
conn.Read([]byte)配合缓冲管理，或者用bufio.Reader的ReadBytes('\n')/ReadString('\n')—— 但要接受“等不到换行就阻塞”的风险 - 真实 Telnet 客户端必须解析 IAC（
\xff）转义序列，textproto完全不处理这个
如何安全地从 Telnet 连接中读取原始字节流？
绕过 textproto，直接操作 net.Conn 是唯一可靠方式。重点不是“怎么读”，而是“怎么判断读到哪儿了”——Telnet 没有长度头，也没有固定结束符，只能靠超时 + 应用层语义（比如看到 Login: 就停，或收到 \xff\xfe\x01 后跳过后续协商字节）。
- 用
conn.SetReadDeadline设置短超时（如 500ms），避免Read永久阻塞 - 分配足够大的 buffer（如 4096 字节），循环
Read直到返回0或io.EOF，或超时触发os.SyscallError: i/o timeout - 对读到的
[]byte手动扫描\xff开头的 Telnet 命令，跳过或响应它们（否则服务端可能卡住） - 示例片段：
buf := make([]byte, 4096)<br>n, err := conn.Read(buf)<br>if err != nil && !errors.Is(err, os.ErrDeadline) { /* 处理真实错误 */ }
textproto 在 Telnet 场景下有哪些隐蔽兼容性问题？
textproto 的设计目标是 RFC 822 类协议（邮件、HTTP headers），它假设：每行结尾有规范换行、无内嵌 NUL、无状态协商、无控制字符干扰。Telnet 全部违反这些假设。
-
ReadMIMEHeader会把\xff\xfd\x03（WILL SUPPRESS GO AHEAD）当成非法 header key，直接报malformed MIME header -
ReadContinuedLine遇到\r不跟\n时行为未定义，某些 Telnet 服务端只发\r - 所有
textproto方法内部都调用bufio.Scanner或类似逻辑，无法禁用自动换行切割 —— 你不能告诉它“这次我想读 17 字节，不管有没有 \n” - Go 1.22+ 中
textproto对 CRLF 处理更严格，遇到孤立\r可能 panic，而老旧 Telnet 设备很常见这种输出
如果非要用标准库模拟简单 Telnet 客户端，该选什么组合？
放弃 textproto，用 net.Conn + bufio.Reader + 手动 IAC 解析是最小可行路径。标准库没有现成 Telnet 实现，硬套其他协议工具只会掩盖问题。
立即学习“go语言免费学习笔记（深入）”；
- 连接后立即发
\xff\xfd\x01（WONT ECHO）和\xff\xfd\x03（WONT SUPPRESS GO AHEAD）抑制服务端协商，减少干扰字节 - 用
bufio.NewReader(conn)，配合Peek(1)判断下一个字节是否为\xff，是则调用自定义函数 consumeIAC() - 接收用户输入时，记得把
\n转成\r\n（多数 Telnet 服务端期望 CR-LF） - 别依赖
textproto的任何方法做核心读写 —— 它不是为这个设计的，强行用等于在解析器里塞错语法的代码
真正麻烦的从来不是连上或发命令，而是服务端随时插播一段 IAC 序列，或者返回一串没换行的二进制提示符。这时候看文档不如抓包，信 textproto 不如信自己写的 bytes.Contains(b, []byte{0xff})。
