介绍：

这里面都是一些比较短小的名词，不值得被单独拉出来写成一篇文章。因此我们把他放在这里。

非技术类：

PRD:

PRD 是 Product Requirements Document 的缩写，中文意思是产品需求文档，是产品经理在需求评审会前产出的核心交付物，也是后端开发、测试、设计等所有角色理解需求、开展工作的唯一依据。

简单说，PRD 就是把产品要做的功能、要解决的问题、要达到的目标，用清晰、无歧义、可量化的文字写下来，避免大家对需求 “各说各话”。

ABTest：

A/B Test 全称是 A/B 测试，本质是一种对照实验方法：在产品迭代时，将用户随机分成两组（或多组），给不同组推送功能、策略、界面等维度的不同版本，通过统计分析用户行为数据，判断哪个版本的效果更优，最终选择效果好的版本全量推广。

比如说你不知道把网页设置成为明亮的好，还是黑暗的好，那就都做，然后不同用户分流到明亮/黑暗中。根据用户反馈来看哪个更好。

PD：

其实是英文缩写Person/Day。其实就是量化人力资源。是项目管理（包括后端开发、软件开发、运维等技术项目）中最基础、最核心的工作量计量单位，用来量化完成某个任务 / 模块 / 项目所需的人力投入。

比如说你写这个需求用了五天，那这个需求需要的资源就是5PD

wlb：

WLB 是 Work-Life Balance 的缩写，中文意思是“工作与生活平衡”，是职场中高频提及的概念，核心是指在完成工作任务的同时，能有足够的时间和精力兼顾个人生活（如休息、陪伴家人、发展爱好等），避免工作过度侵占生活时间。

简单说，就是“不被工作绑架，能平衡好赚钱和过日子”。对于后端开发者而言，WLB 通常和加班强度、项目节奏相关，比如“这个团队WLB很好”，意思是团队很少强制加班，能保证正常下班和周末休息；反之“WLB较差”则意味着经常需要熬夜赶项目、应对紧急故障。

岗位JD：

JD 是 Job Description 的缩写，中文意思是“职位描述”，是企业招聘时发布的核心文档，也是求职者了解岗位信息的主要依据，属于职场通用黑话，后端求职场景中高频出现。

简单说，岗位JD就是“岗位说明书”，清晰告知“这个岗位要做什么、要求求职者会什么、能提供什么福利”。对于后端岗位而言，JD 会明确核心信息，避免求职者与企业对岗位认知偏差。

Base地：

在哪上班的意思，base北京就是指在北京上班

技术类：

埋点：

埋点全称是埋点监控，本质是在前端页面或后端代码中植入特定的采集逻辑，当用户触发特定行为（如点击按钮、提交订单）或系统运行到特定节点（如接口调用成功 / 失败、数据入库完成）时，自动收集并上报相关数据的技术手段。

简单说，埋点就是给产品 / 系统装 “传感器”，用来捕捉你关心的每一个关键行为和运行状态，为数据分析、产品迭代、故障排查提供数据支撑 —— 之前提到的 A/B Test，核心数据来源就是埋点。

可以看一看美团的开源的Cat工具，了解一下什么是埋点。这个网上也有很多网课。

覆盖率：

在大厂后端开发和测试流程中，覆盖率 通常指 代码覆盖率，是衡量测试用例对代码的执行程度的核心指标，反映测试的充分性 —— 简单说就是：你的测试跑了多少行、多少分支的新增代码。

比如你新增了下面的方法，我们可以看到能执行的语句有4行，一共有两个分支。那你的测试用例就要覆盖这四行，两个分支。就叫做覆盖率100%。

public int calculate(int a) {
    if (a > 0) { // 分支1
        return a + 1;
    } else { // 分支2
        return a - 1;
    }
}

它是判断单元测试 / 集成测试是否到位的关键依据，也是很多大厂 提测、合入主干代码的质量门禁之一。

单元测试：

在大厂后端开发流程中，单元测试是指针对代码中最小的可独立测试的单元（通常是一个函数、方法或类）编写的自动化测试用例，核心目的是验证这个单元的逻辑是否完全符合预期，且能在隔离环境下独立运行，不依赖外部系统（如数据库、第三方接口）。

简单说，单元测试就是给代码的 “最小零件” 做单独体检，确保每个零件本身没问题，再组装到整个系统中。如果你之前没接触过写单测，但第一次写还是蛮痛苦的。可以提前学一下Junit

灰度发布：

大厂后端上线新功能时的标准风险控制流程，核心是分阶段、小范围地将新版本推向用户 / 服务器，而非一次性全量切换，通过监控验证稳定性后再逐步扩大范围，出问题可快速回滚，避免影响所有用户。

比如先让新版本上线15%的机器，观察30分钟服务大盘有没有异常，再发布30%，再观察30分钟服务大盘有没有异常。如此重复直到服务发布完。不过这里一般也不需要你操作多少，依旧是点点点。

PR：

其实是git命令：pull Request的缩写。其实就是指当你在自己的分支上完成后端代码开发（比如新增接口、修复 bug）后，向团队提出 申请，请求将你的代码合并到项目的目标分支（比如主分支 main/master、开发分支 dev），这个申请就是 PR。

MR：

其实就是git命令：merge Request的缩写。就是指你把代码合并到主干分支这个操作。

CR：

这个不是git命令了，是英文缩写：code Review。其实就是代码审查，大家聚在一起看一看你新需求的代码写的怎么样。一般是后端开发流程中避不开的一个环节。

TP99/TP999

其实就是百分比。指XXX比例的请求能在XXXs内完成。比如我说这个接口的TP99是2s，意思就是99%的接口都能在2s内完成请求。

一般都是服务大盘重点观测的数据，如果有剧烈波动一般都要小心。发版的时候观测大盘也主要看这个数据。

N个9：

这个我们一般说三个9（99.9%），四个9(99.99%)。

比如我说我们的服务要尽量达到三个9，其实就是指一年内，服务的稳定性可以达到99.9%的时间

上下游：

后端语境中的“上下游”，核心是描述服务/模块/系统之间的依赖关系和数据流向，本质是“谁给谁提供支持、谁依赖谁”的协作逻辑——上游是提供数据、服务或资源的一方，下游是依赖并使用上游输出结果的一方。

简单说，就像供应链：上游是“供货方”，下游是“收货使用方”。后端系统中，数据和请求通常从下游流向上游，处理结果从上游返回下游。

比如电商下单流程的上下游关系：用户点击下单（下游触发）→ 订单服务（下游）调用用户服务校验用户状态（上游）、调用库存服务锁定库存（上游）、调用支付服务创建支付单（上游）；

服务大盘：

后端服务的“全局监控面板”，整合了QPS/TPS、TP99、错误率、服务器CPU/内存/磁盘等所有核心监控数据，是运维、开发人员实时掌握服务状态的“仪表盘”。

简单说，就是服务的“体检报告实时大屏”。发版时看大盘确认服务无异常，大促时盯大盘防峰值崩溃，出现故障时先看大盘定位影响范围（比如是全量用户还是部分地区，是哪个接口报错）。

比如发版后，大盘显示“支付接口错误率从0飙升到5%”，就能立刻感知到发版引入了问题，及时触发回滚。

QPS/TPS：

两者都是衡量服务并发能力的核心指标，QPS是Queries Per Second（每秒查询数），TPS是Transactions Per Second（每秒事务数），日常沟通中常混用，重点看场景。

简单说，就是服务每秒能处理多少个请求/事务。QPS侧重“查询类请求”（比如查询商品详情），TPS侧重“带数据修改的完整事务”（比如下单、支付，包含查询+新增+修改等多个步骤）。

比如“商品详情接口QPS能扛1万”，就是每秒能处理1万个商品查询请求；“支付接口TPS峰值500”，就是每秒最多能完成500笔支付事务，这也是压测时的核心达标指标。

最后：

我是程序员牛肉，目前就职于字节跳动。文章来自我的学习笔记《牛牛八股》。如果你对后端有任何疑问的话，都欢迎私信我哦。希望我可以帮到你。

关注我，带你了解更多代码之外的生存之道。欢迎订阅我的专栏（目前免费），后续也会持续更新。如果这篇文章帮到了你的话，就送我朵花花吧。