redis string最大长度由proto-max-bulk-len配置项控制，默认512mb，是协议解析层的“入口闸门”，在请求解析阶段即拒绝超长bulk数据，早于内存分配与sds操作。
Redis String最大长度不是由SDS或内存分配器直接硬限为512MB，而是服务端配置 proto-max-bulk-len 的默认值，且该限制在协议解析层就生效——没到内存分配那步，请求已被拒绝。
proto-max-bulk-len 是什么，为什么它比 SDS 长度更关键？
Redis 6.0+ 中，proto-max-bulk-len 控制 RESP 协议里 bulk string（如 $123456789 开头的数据块）允许的最大字节数。它不是 SDS 的容量上限，而是“协议入口闸门”：客户端发一个 $536870913（512MB+1）开头的包，Redis 在解析协议阶段就报 invalid bulk length，根本不会调用 sdsnewlen 或 zmalloc。
常见误判是去翻 sds.h 或 zmalloc 源码找“512MB 硬编码”，其实从 Redis 6.2.7 起，checkStringLength 函数已改为读取 server.proto_max_bulk_len；早期版本（如 5.0.9）才真有 512*1024*1024 的常量判断。
-
proto-max-bulk-len单位是小写mb（如1gb合法，1GB会解析失败） - 修改后必须重启 Redis，热重载不生效
- 它同时约束
SET、LPUSH、HSET等所有带 bulk 数据的命令
SDS 结构本身能支持多大？别被 len 字段误导
SDS 的 len 字段在 Redis 3.2+ 是 size_t 类型（64 位系统下为 uint64_t），理论支持远超 512MB；旧版（3.2 前）用 unsigned int，上限约 4GB，但 Redis 主动截断在 512MB —— 这是策略性限制，不是能力天花板。
真正卡住大字符串的，从来不是 len 字段溢出，而是：
- 协议解析器拒绝超长
$N声明（proto-max-bulk-len） - 内存分配器（
zmalloc）申请连续大块内存失败（尤其在碎片化严重时） - 客户端库对响应体长度做缓冲区硬限制（如 redis-py 默认
socket_read_size=65536）
为什么改大 proto-max-bulk-len 还存不进 300MB 的值？
即使把 proto-max-bulk-len 改成 1gb 并重启，仍可能失败，原因在链路各环节：
- Redis 服务端
maxmemory已满，报错OOM command not allowed when used memory > 'maxmemory' - Docker/K8s 容器内存 limit 设为 1G，Redis 自身开销 + 其他 key 占用后，剩余连续内存不足 300MB
- 用
redis-cli --pipe导入时未分块，单条SET命令触发 client output buffer 超限（client-output-buffer-limit normal） - Java 应用用 Jedis 执行
set(key, bigBytes)，Jedis 内部Protocol.sendCommand对参数长度有隐式校验（部分版本会提前截断）
GET 一个 200MB String 时客户端崩了，问题不在 Redis
Redis 成功返回数据，但客户端进程 OOM crash，典型表现是 JVM 直接退出或 Python 报 MemoryError。这是因为：
- 客户端未流式消费，而是试图一次性
byte[] buf = new byte[200 * 1024 * 1024] - Netty 或 socket 层缓冲区配置过小（如 Netty 的
AdaptiveRecvByteBufAllocator默认 max 64KB） - redis-cli 执行
GET时，终端无法渲染或缓存超大输出，直接 hang 住或 kill 进程
真正需要存几百 MB 数据的场景，比如用户上传的 PDF 或模型权重，不要塞进 String。Redis 不是对象存储——它缺分片、缺流式读写、缺持久化保障。用 S3/OSS 存原始文件，Redis 只存 file_id、size、etag 等元数据，才是稳态做法。
