Go手写RESP解析器最常因换行空格处理不当崩溃：必须用bufio.Reader.ReadBytes('\n')并校验\r\n，而非strings.Split或Scanner；写入需显式拼接\r\n；读bulk string要先解析长度再io.ReadFull(n+2)并截取；简易客户端无需支持RESP3。
Go 里手写 RESP 解析器最常崩在换行和空格上
RESP 协议看着简单，但 \r\n 是硬性分隔符，不是可选的。很多初学者用 strings.Split(line, "\n") 或 bufio.Scanner 默认行为（丢弃 \r\n）直接切，结果读到一半就卡住或错位。
真正该用的是 bufio.Reader 配合 ReadBytes('\n')，它会原样保留前面的 \r，再手动检查末尾是否为 \r\n。否则遇到 "$5\r\nhello\r\n"，你 split 出来可能是 "$5\r" 和 "hello\r"，彻底乱套。
- 永远用
bufio.NewReader(conn)，别用Scanner - 读一行必须调用
r.ReadBytes('\n')，然后检查bytes.HasSuffix(b, []byte{'\r','\n'}) - 遇到
"*3\r\n$3\r\nSET\r\n$4\r\nkey1\r\n$5\r\nvalue\r\n"这种嵌套结构，不能一次性全读完再解析，得递归或栈式处理
Go 客户端发命令时最容易漏掉的两个字节
Redis 要求每个命令结尾是 \r\n，但 Go 的 conn.Write() 不自动加。写 "SET key val" 发过去，Redis 收到的是不合法的帧，直接返回 Protocol error: expected '$', '*' or '%' —— 因为它等的是 "*3\r\n$3\r\nSET\r\n..." 这种格式，而不是裸字符串。
更隐蔽的是批量命令（如 pipeline），每条命令之间也得严格用 \r\n 分隔，中间多一个空行、少一个 \r，服务端就断连接。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 所有写入必须显式拼接
\r\n：conn.Write([]byte("PING\r\n")) - 构造数组类型命令时，先算好元素个数，再逐个写
"*N\r\n"+ 每个"$len\r\ncontent\r\n" - 调试时用
tcpdump -i lo port 6379 -A看原始字节流，比看日志更准
为什么 io.ReadFull 在读 bulk string 时总超时
RESP 的 $5\r\nhello\r\n 中，$5 后面的长度是内容字节数，不含 \r\n。但很多人误以为要读 5+2=7 字节，实际该读 5 字节内容 + 2 字节 \r\n 结尾。如果只调 io.ReadFull(r, buf[:5])，后面 \r\n 就留在缓冲区，下一次读就错位。
还有一种情况：服务端返回 $-1\r\n（表示 nil），你却按正数去分配 buffer，就会 panic。
- 读 bulk string 先解析出长度
n，若n == -1直接返回nil；否则分配make([]byte, n+2)，再用io.ReadFull读满 - 读完后手动验证最后两字节是
\r\n，再截取前n字节作为内容 - 永远假设网络可能粘包，不要依赖单次
Read返回完整帧
简单客户端要不要支持 Redis 6 的 RESP3？
不用。除非你明确要处理 set 命令返回的 OK 变成 !OK 这类新类型，或者需要 map/array/set 的语义区分。RESP2（即传统 +/$/*/:/-）覆盖了 95% 的日常操作，且所有 Redis 版本都默认兼容。
RESP3 引入了类型前缀（如 ~ 表示 set，% 表示 map），解析逻辑变复杂，还要处理类型协商（HELLO 3 命令）。对简易客户端来说，这是过早优化。
- 初始化连接后，直接发
"PING\r\n"测试通路，别先发"HELLO 3\r\n" - 所有响应按 RESP2 规则解析，
+开头当字符串，:当整数，-当错误，$和*按长度递归处理 - 如果未来要支持集群或 stream，再考虑升级协议层，现在先跑通
GET/SET/DEL就够用
真正难的从来不是协议本身，而是怎么让读写状态在并发请求里不互相污染 —— 比如一个 goroutine 正在读 *2\r\n 后的两个字符串，另一个同时发了新命令，缓冲区就混了。所以哪怕最简客户端，也得有 per-connection 的 reader/writer 锁或 channel 隔离。
