Redis的STRLEN命令返回的是键对应值的字节长度，并非字符数量。要理解这个结论，需要从Redis的字符串存储机制说起：Redis使用二进制安全的SDS（Simple Dynamic String）结构存储字符串，SDS内部有一个len字段，记录当前字符串实际占用的字节数。STRLEN命令的实现非常直接，就是读取这个len字段并返回，时间复杂度为O(1)，不需要遍历整个字符串内容。无论字符串中存放的是ASCII字符、UTF-8编码的中文还是任意二进制数据，len字段记录的始终是字节数。
很多开发者第一次接触这个命令时，会想当然地认为它和高级语言里的字符串长度函数一样返回字符个数。比如在Python中，len("你好")返回2；在JavaScript中，"你好".length也返回2。但当你在Redis中执行SET msg "你好"然后STRLEN msg时，返回的结果却是6。这个差异正是由于Redis把字符串当作字节序列处理，而高级语言在内存中通常使用更丰富的字符串对象，能够感知Unicode字符边界。因此，使用STRLEN之前必须明确：你统计的究竟是字节数，还是用户所能看到的字符数。
STRLEN的底层实现与字节计数本质
Redis的字符串对象在底层可能使用三种编码：int、embstr和raw。对于长度较短的字符串，Redis会使用embstr编码，这种编码将RedisObject结构和SDS结构分配在连续内存中；对于长度较长的字符串，则使用raw编码。无论哪种编码，SDS的结构都是相似的。一个典型的SDS结构在C语言中可以表示为：
struct sdshdr {
unsigned int len; // 已经使用的字节数
unsigned int free; // 未使用的字节数
char buf[]; // 字节数组，存储实际内容
};
如代码所示，len字段记录了buf数组中实际存储的字节长度。当我们执行STRLEN命令时，Redis服务器会先根据键找到对应的字符串对象，然后直接读取其SDS结构中的len字段并返回。由于返回的是C语言中size_t类型的数值，不会受到字符串内部空字符的影响。这一点与C标准库中的strlen函数完全不同，strlen函数需要遍历字符串直到遇到第一个空字符，但Redis的二进制安全特性允许字符串中间包含空字符，STRLEN依然能正确返回实际存储的字节总数。
这种设计保证了STRLEN的高效性。获取长度只需要一次内存读取，不存在遍历开销。同时，由于Redis将所有字符串都视为字节序列，STRLEN天然地与编码格式无关。无论客户端使用UTF-8、GBK还是其他编码方式写入数据，STRLEN返回的都是这些字节的个数。这也就意味着，同一个中文字符在UTF-8编码下通常占3个字节，在GBK编码下占2个字节，使用STRLEN会得到不同结果。因此，如果项目中需要跨编码环境交互，必须确保写入Redis的数据编码保持一致，否则长度统计会产生偏差。
字符与字节的编码差异及实例验证
为了直观感受字符数和字节数的差异，可以启动一个Redis实例，使用redis-cli进行测试。下面的命令分别向Redis中写入纯ASCII字符串和包含中文的UTF-8字符串，然后执行STRLEN：
127.0.0.1:6379> SET ascii_str "hello" OK 127.0.0.1:6379> STRLEN ascii_str (integer) 5 127.0.0.1:6379> SET utf8_str "你好" OK 127.0.0.1:6379> STRLEN utf8_str (integer) 6 127.0.0.1:6379> SET emoji_str "👍" OK 127.0.0.1:6379> STRLEN emoji_str (integer) 4
从输出可以看出，纯ASCII字符串每个字母占1个字节，返回5；两个中文字符在UTF-8编码下每个占3个字节，返回6；一个emoji表情在UTF-8编码下需要4个字节，返回4。如果业务逻辑期望得到“2个字符”或“1个字符”的结果，直接使用STRLEN就会得到完全不同的数值。这种差异在限制用户输入长度、生成固定长度的key、或者做数据分片时都必须认真对待。
还需要注意，Redis的SET命令支持二进制安全的数据写入，但大多数客户端库在发送命令时会将字符串按照某种编码转换成字节序列。例如，使用Python的redis-py库时，如果传入的是str类型，默认会使用UTF-8编码成bytes；如果传入的是bytes类型，则直接发送原始字节。了解客户端的编码行为有助于预测STRLEN的返回值。如果遇到返回值和预期不符的情况，建议先用TYPE命令确认键类型，再用GET命令查看原始内容，确认编码方式是否与假设一致。
业务场景中的正确处理方式与常见误区
在实际业务中，最常见的误区是把STRLEN当作字符串所包含的字符数量直接展示给用户。比如开发用户注册功能时，要求昵称最多10个字符，前端已经按照字符数量做了限制，后端却用Redis的STRLEN来校验长度。如果用户输入的是纯中文昵称，每个中文字符占3个字节，后端通过STRLEN得到的数值就会超过10，导致合法昵称被错误拒绝。反之，如果后端用STRLEN小于等于10来放行，一个昵称可能只包含3个中文字符就达到9个字节，实际字符数不足10，造成长度限制形同虚设。
要正确统计字符数量，必须依赖应用层语言提供的Unicode处理能力。以Python为例，如果从Redis获取的值是bytes类型，可以先解码成字符串，再计算字符长度：
import redis
client = redis.Redis(host='localhost', port=6379, decode_responses=True)
client.set('nickname', '你好')
value = client.get('nickname') # decode_responses=True 时返回 str
char_count = len(value) # 返回字符数 2
byte_count = len(value.encode('utf-8')) # 返回字节数 6
print(char_count, byte_count)
上面的代码中，decode_responses参数让客户端自动使用UTF-8解码，get方法返回的是Python字符串对象，此时len函数统计的是字符数。如果需要字节数，再手动编码即可。类似地，在Node.js中可以使用Buffer.byteLength来获取字节长度，使用字符串的length属性获取UTF-16码元个数（对于大部分常用字符等同于字符数，但需要注意emoji等代理对字符）。核心原则是：Redis只负责存储和返回字节，字符语义必须由应用层负责解析。
另一个常见场景是使用Redis的INCRBY命令配合STRLEN做限流或计数，此时STRLEN返回的数字字符个数与数值大小无关，例如数字100的STRLEN是3，数字1000是4。开发者不能依赖STRLEN来判断数值的位数，因为数值在Redis内部可能使用int编码存储，STRLEN读取的是字符串形式下的字节数，而int编码存储时并没有实际的字符串表示，Redis会先将整数转换成字符串再计算长度。这个转换过程虽然对结果没有影响，但提醒我们STRLEN的本质是面向字符串对象的字节长度，而不是面向数值类型。只有清晰理解STRLEN的字节语义，才能在缓存设计、数据校验、序列化等环节避免隐蔽的bug。