摘要：

网上查小红书薪资，R4、R5、R6 依然满天飞，R5 百万年包、R6 接近 200 万的数字也很常见。

但问题是，小红书早在 2024 年就取消了 R 职级。

所以到了 2026 年，这些数据到底还能不能参考？现在应该怎么判断一个岗位的级别和薪资？如果准备面试小红书测试开发，又应该重点准备什么？

这篇文章把这几个问题放在一起讲清楚。

很多人第一次查小红书薪资，都会看到这样一张表：

R4，月薪大约 5.2 万，年包 77.5 万。

R5，月薪大约 5.6 万，年包 101.1 万。

R6，月薪大约 7.1 万，年包 191.5 万。

第一眼看过去，最容易冒出来的问题 probably 是：

“那我现在去面小红书，能定到 R 几？”

但这个问题现在其实已经问不通了。

因为从 2024 年开始，小红书已经取消了 R 职级。

所以今天再看到 R4、R5、R6，最好先把它当成一套历史坐标。

它还能帮助你理解过去不同责任范围岗位之间的薪资差距，但不能再直接拿来套今天的岗位。

这点先搞明白，后面的薪资、晋升和面试才不会越看越乱。

一、小红书现在还有 R4、R5、R6 吗？

没有了。

2024 年 8 月，小红书调整职级体系，其中比较明确的一项就是取消 R 职级，同时取消 L0，各级 Leader 改为任命制。

这次调整之后，过去那种：

R4 → R5 → R6 → R7

非常直观的职级梯子就不再是现行体系了。

但网上为什么到现在还能看到大量 R4、R5、R6 的薪资数据？

原因也很简单。

过去几年，大量员工薪资、招聘 Offer 和职场讨论都是围绕 R 职级展开的，所以历史样本非常多。

因此现在看到这些数据，并不是说它们完全没用了。

只是用途变了。

以前你可能拿它回答：

“这个人是什么职级？”

现在更适合拿它回答：

“过去这个责任范围的技术岗位，大致对应什么收入水平？”

这两个问题不是一回事。

二、那 R4、R5、R6 的薪资还值得看吗？

值得。

但千万不要把它当成“小红书 2026 官方薪资表”。

目前公开样本里，技术研发岗位比较常见的一组数据是：

这里最容易出现两个误区。

第一个误区是：

把平均样本当成标准 Offer。

同样一个技术岗位，不同业务线、工作年限、招聘年份、候选人背景，报价差距可能很大。

第二个误区是：

把总包直接理解成现金收入。

尤其看到 R6 的 191.5 万，很容易产生一种错觉：

“一年差不多能拿 190 万现金。”

实际上不是这么算的。

三、为什么 R5 到 R6，总包突然拉开这么多？

这一段反而比“R6 到底是什么级别”更值得看。

R5 样本折算月薪大概是：

5.6 万。

R6 大概是：

7.1 万。

如果只看月薪，两边虽然有差距，但远远没有到翻倍的程度。

但年包从 101 万直接到了 191.5 万。

钱差在哪？

主要差在奖金和股权。

按照这组历史样本：

R6 年度工资大约 84.9 万；

奖金大约 22 万；

年度股权激励大约 84.6 万。

也就是说，在这份样本里，股权已经占到整个 Package 的四成以上。

这也是为什么看互联网大厂薪资时，只盯着“年包”很容易看错。

一个 150 万年包的 Offer，和另一个 150 万年包的 Offer，可能完全不是一回事。

一个可能现金占 120 万；

另一个可能现金 80 万，剩下大部分是股权。

账面数字一样，实际体验差很多。

四、拿到 Offer，至少把这三笔账算开

如果以后真的拿到小红书 Offer，建议别只问 HR 一句：

“总包多少？”

至少拆成三部分看。

第一笔：固定工资

这个最好理解。

月薪多少？

一年固定发几个月？

有没有固定 13 薪？

这一部分决定你每个月相对稳定能拿多少钱。

第二笔：奖金

这一部分要问细。

比如招聘里写 16 薪，你至少应该继续确认：

其中多少是固定？

多少跟绩效有关？

奖金是目标值还是保证值？

入职不到一年怎么算？

什么时间发？

如果这些都没问，只看到“16 薪”就直接拿月薪乘 16，算出来的数字可能跟最终收入差得不少。

第三笔：股权

股权最不能只看一个总金额。

比如 Offer 里告诉你：

授予 40 万股权。

你还要继续问：

几年归属？

第一年归多少？

归属节奏是什么？

有没有行权条件？

后续怎么变现？

所以真正比较 Offer，建议把现金、奖金和权益分三列。

表一拉出来，有时候比问十遍“这大概相当于以前的 R 几”都有用。

五、R 职级取消以后，一个岗位到底怎么看高低？

其实没有 R 职级以后，反而逼着大家回到一个更实际的问题：

这个岗位到底在负责什么？

拿测试开发举例。

同样都叫测试开发工程师，工作可以差得非常远。

一种岗位可能主要做业务测试、接口自动化、回归。

再往上一层，可能负责测试框架、持续集成、质量平台。

再往后，可能需要解决性能、稳定性、全链路压测、故障演练。

还有一些更偏基础设施的岗位，会碰到存储、调度、集群、AI Infra、模型训练和推理链路。

职位名称没变。

但系统复杂度完全不在一个量级。

所以现在判断一个岗位，不妨直接看三件事：

负责的问题有多难；

覆盖的系统范围有多大；

出了问题，你需要负责到哪一层。

这三个问题，比“以前大概是 R5 还是 R6”更接近真实工作。

六、小红书测试开发，面试到底在看什么？

这一部分我想多讲一点。

因为我们学社最近收到的一些小红书测试开发面试反馈，放在一起看之后，特点还是挺明显的。

小红书测开本身一直就不是只考测试用例的岗位。

项目、代码、数据库、缓存、消息队列、网络、操作系统、性能，包括算法，本来就在测开的能力范围里。

而面试里有一个特点尤其明显：

喜欢顺着你的项目往下挖。

比如你简历上写：

使用 Redis 提升系统性能。

面试官一般不会停在：

“Redis 有哪些数据结构？”

更可能继续问：

为什么这个地方要用 Redis？

不用行不行？

缓存更新策略是什么？

数据库更新成功、缓存更新失败怎么办？

高并发下有没有热点 Key？

如果 Redis 挂了系统怎么跑？

这套方案你当时怎么测？

所以如果只准备一份八股文，面试的时候很容易出现一种情况：

第一问能答。

第二问开始绕。

第三问就回到“这个是后端同学做的”。

这对测试开发岗位不太占优势。

七、第一类高频题：项目深挖

项目基本是测开面试绕不过去的一关。

而且这一部分没有什么标准答案。

面试官真正想确认的是：

简历上的东西到底是不是你干的。

一般会先从：

“介绍一个你做过的项目。”

开始。

后面很快就会进入细节：

你负责哪一块？

为什么这么设计？

当时最大的技术难点是什么？

怎么验证方案有效？

线上有没有出过问题？

最后是怎么定位的？

如果项目涉及性能测试，还会继续追：

压测数据怎么准备？

测试数据是真实数据还是模拟数据？

怎么避免数据重复？

压测过程中哪个指标最先到瓶颈？

服务器扩容以后性能有没有线性提升？

为什么没有？

这里举个很典型的例子。

如果你的简历里写：

使用 JMeter 完成核心接口高并发压测。

这句话写出来很轻松。

但面试的时候至少要准备回答：

压了多少并发？

TPS 多少？

P95、P99 怎么样？

压测数据从哪里来？

JMeter 自己有没有成为瓶颈？

数据库连接池当时配置多少？

Redis 命中率多少？

CPU 到多少？

GC 有没有异常？

如果性能突然下降，你是怎么判断瓶颈到底在应用、数据库还是下游服务？

到了这一层，考的已经不是 JMeter 怎么配线程组。

考的是性能工程。

八、第二类高频题：业务场景怎么测

小红书自己的产品场景非常多，所以搜索、推荐、点赞、收藏、评论这类题很容易被拿出来问。

例如：

“点赞功能怎么测试？”

如果是普通测试面试，很多人第一反应是：

正常点赞；

取消点赞；

重复点赞；

未登录点赞；

弱网测试；

异常测试。

这些都对。

但测开岗位一般不会停在这里。

再往下一层，问题就开始变了。

接口层

点赞接口是否幂等？

用户连续点击十次，会不会真的写十次？

请求超时后客户端重试，服务端会不会重复记账？

数据层

点赞数和点赞明细是一套数据还是两套数据？

如果计数已经 +1，但明细写失败怎么办？

取消点赞以后，两边怎么保证一致？

缓存层

点赞数量是不是放在 Redis？

如果缓存和数据库数据不一致，以谁为准？

热点内容突然爆发，大量请求集中到一个 Key 怎么处理？

消息队列

如果点赞行为异步写入 MQ：

消息丢了怎么办？

重复消费怎么办？

消息积压会不会导致页面点赞数延迟？

性能

热门笔记一分钟突然进来几十万次点赞请求，系统瓶颈在哪里？

是 Redis？

数据库？

MQ？

还是下游统计服务？

用户体验

用户点下去以后，是先在前端展示成功，再异步确认？

如果服务端失败，页面状态怎么回滚？

你看，同样一道“点赞怎么测”，如果只列功能用例，是一个层次。

如果能顺着：

接口 → 数据 → 缓存 → MQ → 性能 → 故障

把整个链路拆开，这才更像测试开发。

九、第三类高频题：Java / Python

测试开发的“开发”两个字，不是岗位名称里摆着好看的。

Java 和 Python 基础，基本都会涉及。

比较常见的内容包括：

HashMap；

ArrayList 和 LinkedList；

Java 类加载；

JVM 内存结构；

GC；

线程；

锁；

面向对象；

继承和接口；

Spring 基础。

如果继续深挖，可能会问：

HashMap 为什么线程不安全？

扩容时发生什么？

ConcurrentHashMap 怎么处理并发？

公平锁和非公平锁有什么区别？

什么情况下会频繁 Full GC？

一次接口 RT 飙升，会不会跟 GC 有关系？

这一部分准备的时候，不建议单纯背定义。

比如 HashMap。

知道：

数组 + 链表 + 红黑树。

只能算第一层。

更值得准备的是：

为什么这样设计？

什么时候扩容？

什么时候树化？

高并发下有什么问题？

如果测试一个大量使用 HashMap 的服务，你可能观察到什么异常？

这时候知识才真正跟岗位连起来。

十、第四类高频题：MySQL、Redis、MQ

如果是互联网公司的测试开发，这三块建议别只学到“知道是什么”。

MySQL

至少应该能讲：

索引为什么用 B+Tree；

联合索引；

最左匹配；

索引失效；

事务；

隔离级别；

MVCC；

慢 SQL；

Explain。

还有一个非常现实的问题：

一个接口突然从 100ms 变成 2 秒，怎么判断是不是 SQL 导致的？

这比“什么是索引”更接近真实工作。

Redis

建议重点准备：

常用数据结构；

缓存穿透；

缓存击穿；

缓存雪崩；

热点 Key；

缓存一致性；

Redis 高可用。

然后一定补一句：

这些场景怎么测。

比如缓存击穿。

不能只解释概念。

还应该知道如何构造大量并发，在缓存刚好失效的瞬间请求同一个 Key，观察数据库连接数、QPS、RT 和错误率。

这才叫测开视角。

MQ

MQ 面试里很容易问：

消息为什么会重复？

怎样保证幂等？

消息会不会丢？

生产者成功了，消费者没收到怎么办？

消费者处理成功但 ACK 失败怎么办？

MQ 积压以后怎么处理？

这些问题本质上都不是背 Kafka 或 RocketMQ 参数。

而是考你对分布式系统可靠性的理解。

十一、第五类高频题：网络和操作系统

这块很多人准备的时候会觉得：

“我又不是面后端，为什么还要学？”

但真到了线上排障，很快就知道为什么要学。

比如你看到的现象可能只是：

接口偶发超时。

背后原因可能完全不同：

线程池耗尽；

TCP 重传；

连接池满；

DNS 异常；

下游服务抖动；

Full GC；

数据库锁等待。

所以至少建议把下面这些东西搞明白：

TCP 和 UDP；

三次握手、四次挥手；

TCP 重传；

流量控制；

拥塞控制；

进程和线程；

线程切换；

死锁；

虚拟内存；

进程间通信。

不是要求把操作系统教材背下来。

而是要能把它们和实际故障对应上。

十二、性能测试这一块，最好真会做

如果准备小红书测开，性能测试我会建议单独花时间。

因为这一块特别容易把：

会用工具的人

和

真正能分析系统的人

区分开。

几个指标最好张口就能说清楚：

QPS；

TPS；

响应时间；

P95；

P99；

错误率；

并发数；

CPU；

内存；

GC；

线程池；

连接池；

数据库连接；

Redis；

MQ Lag。

但更关键的是故障定位。

例如：

3000 QPS 之前接口一直稳定在 100ms，继续加压以后突然变成 2 秒。

你怎么查？

不要一上来就说：

“看 CPU。”

建议形成自己的排障路径：

先看压测端。

JMeter 自己是不是打满了？

带宽是不是满了？

然后看：

负载均衡。

请求有没有均匀落到所有实例？

再看应用：

CPU；

Load；

内存；

GC；

线程池；

连接池。

再往下：

Redis；

MySQL；

RPC；

MQ；

下游服务。

性能测试不是“把服务器压到挂”。

真正的目标是：

找到系统开始失速的那个点，以及为什么失速。

这句话面试的时候能讲明白，和只会跑报告的人区别就出来了。

十三、算法也不用抱侥幸心理

测试开发不是算法岗。

但代码题还是会有。

目前准备的话，把常见题型过一遍基本比较稳：

数组；

字符串；

链表；

Hash；

栈；

队列；

二叉树；

排序；

二分；

DFS；

BFS。

像：

最长公共前缀；

链表相交；

二叉树层序遍历；

最近公共祖先；

字符串处理；

快排；

这类题都值得练。

算法这里我反而不建议过度刷。

比起一天刷几十道题，更重要的是：

一道 Medium 给你以后，你能先讲思路，再把代码写完整，最后还能说清时间复杂度和空间复杂度。

对测开岗位来说，这已经很实用了。

十四、2026 年还有一块新东西值得留意：AI 测试

这一块不是说：

“2026 年不会 AI 就找不到测开工作。”

没必要制造这种焦虑。

但从岗位变化来看，AI 确实已经开始进入测试开发需要面对的系统。

比如现在一些偏 AI Infra 的测试岗位，已经会涉及：

GPU；

CUDA；

大模型训练；

大模型推理；

vLLM；

性能 Profiling；

集群稳定性。

普通业务测开当然不需要一上来研究 CUDA。

但如果你未来还准备做测试开发，我建议至少开始理解几个问题：

大模型应用怎么做回归？

传统接口输入固定，输出通常也比较稳定。

但大模型不是。

同一个 Prompt 调两次，输出可能不同。

那测试用例到底怎么写？

断言怎么做？

RAG 怎么评测？

只看“回答有没有生成出来”肯定不够。

还要看：

召回对不对；

召回内容够不够；

答案是否基于知识库；

有没有幻觉。

Agent 怎么测试？

Agent 不只是调一次模型。

中间还有：

规划；

工具调用；

状态；

上下文；

失败重试；

多步执行。

所以测试对象从一个接口，变成了一条执行链。

大模型性能怎么测？

除了传统 QPS 和 RT，还可能看：

TTFT，首 Token 延迟；

TPOT，每个 Token 的生成延迟；

吞吐量；

并发请求；

Token 数量；

GPU 利用率。

这些东西现在可能还不是每一个测开岗位都会问。

但它们已经开始进入测试开发的技术栈。

这点值得提前知道。

十五、小红书测试开发面试，可以重点准备这些题

最后我把前面的内容压成一份清单。

如果近期准备面试，可以直接照着查缺补漏。

测试设计

• 小红书搜索怎么测试？
• 点赞、收藏怎么测试？
• 推荐系统怎么测试？
• 音视频业务怎么测试？
• 一个新接口怎么设计完整测试方案？
• UI 自动化怎么降低维护成本？

Java / Python

• HashMap 底层结构是什么？
• HashMap 为什么线程不安全？
• ArrayList 和 LinkedList 怎么选？
• Java 类加载过程是什么？
• JVM GC 有哪些类型？
• 多线程安全怎么保证？
• Python 多线程和多进程分别适合什么场景？

MySQL / Redis / MQ

• MySQL 为什么使用 B+Tree？
• 什么情况下索引会失效？
• MVCC 是怎么实现的？
• Redis 为什么快？
• 缓存和数据库不一致怎么处理？
• 缓存击穿怎么测试？
• MQ 为什么会重复消费？
• 消息丢失怎么处理？
• MQ 积压怎么排查？

网络与系统

• TCP 和 UDP 有什么区别？
• TCP 为什么可靠？
• 三次握手解决什么问题？
• 进程和线程有什么区别？
• 死锁的四个条件是什么？
• 一个接口大量超时怎么定位？

性能

• QPS 和 TPS 有什么区别？
• P95、P99 是什么？
• 百万级测试数据怎么准备？
• 秒杀系统怎么压测？
• CPU 很低，但接口特别慢，先查什么？
• 数据库连接池打满会出现什么现象？
• Redis 成为瓶颈怎么判断？

算法

重点把这些结构练熟：

字符串、数组、链表、Hash、二叉树、排序、二分、DFS、BFS。

写在最后

我觉得小红书取消 R 职级以后，有一个变化反而挺有意思。

以前大家很喜欢问：

“几年能升 R6？”

因为有一个职级数字放在那里，职业发展看起来特别直观。

但真正做过几年技术以后会发现，职级只是最后呈现出来的结果。

前面真正拉开差距的，其实一直是：

别人只能测一个功能，你能看懂整个链路；

别人能发现 Bug，你能判断 Bug 为什么发生；

别人会跑自动化，你能把自动化做成平台；

别人看到接口慢，只知道报性能问题，你能一路查到线程池、Redis、数据库和下游服务。

这些能力不管公司有没有 R4、R5、R6，都不会消失。

对于准备小红书测试开发的同学来说，也不用被那张“R6 年包 190 万”的表带跑偏。

先把自己的项目、代码、数据库、缓存、MQ、性能和系统基础扎实下来。

因为真正坐到面试桌前以后，面试官最后看的还是一件事：

这个系统交给你，你到底能不能把质量这件事做明白。

说明： 文中 R4、R5、R6 薪资为旧职级体系下的公开历史样本，主要用于理解过去不同岗位责任范围和薪酬结构，不代表小红书 2026 年现行职级体系或统一薪资标准。测试开发面试部分结合学社近期收到的学员面试反馈整理，不同业务线、校招/社招以及面试官的考察方向会存在差异。