在B端产品开发中，产品经理与技术团队的紧密合作至关重要。本文将为B端产品经理介绍一些必须掌握的技术核心词汇，包括API（应用程序接口）、SDK（软件开发工具包）、前后端分离、同步与异步处理以及消息队列等。

在正文之前，先说一下B端产品经理为什么需要懂技术语言？

B端产品，也叫2B（To Business）产品，通常服务于企业客户，包括内部外企业。B端产品是为了解决企业的经营问题，目的是为了获得更多的超额利益。

通常来说，B端产品需求复杂度更高，涉及的流程更多、更为严谨，通常又涉及多系统交互和集成，对技术依赖性强。所以B端产品经理懂一些必要的技术词汇和概念是非常有必要的，具体好处如下：

1. 和开发沟通更顺畅：避免与开发、架构师出现“鸡同鸭讲”的沟通障碍。
2. 需求可行性判断：自己可以快速评估需求的技术实现难度与成本，避免提出“空中楼阁”式需求。同时会造成开发的反感，影响后续的合作。
3. 更合理地设计产品方案：比如，在一些业务流程设计中，能大概想到可能的技术限制（如数据同步延迟、性能问题等）。
4. 提高合作效率，赢得认同：懂技术语言，和技术团队合作会更为顺畅，效率更高，别人也更容易认可你的专业性。

正文开始~

一、API（应用程序接口）

1.API 的定义

API是系统间数据交互的桥梁，它定义了不同模块、服务或应用之间如何交换数据与功能。

比如，通过天气数据API，我们可以获取到天气情况；通过订单创建接口，我们可以创建订单，使订单进行后续流转。

2.为什么需要API？

① 解耦：系统A无需知道系统B的内部逻辑，只需按规则调用。

② 复用：通用能力（如支付、地图）可被多个系统共享，避免重复开发。

B端究竟需要什么样的产品经理？

B端产品经理都是以提升供应侧的工作效率为目的，所以B端需求主要是以业务问题为导向。 这个是B端产品比较重要的一点，B端产品是服务于一个主体 ...

查看详情 >

③ 安全：通过权限控制（如Token）限制访问范围，保护核心数据。

3.API 的基本流程

① 请求（Request）：调用方发送指令（如“获取用户信息”）。

② 处理（Process）：被调用方验证权限、执行逻辑（如查询数据库）。

③ 响应（Response）：返回结果（成功数据或错误提示）。

4.API 文档规范

一个接口文档的组成要素如下：

① 接口请求地址：例如https://api.mch.weixin.qq.com

② 请求方式：一般有POST、GET、PUT和DELETE等

③ 请求参数：请求该API必须携带的参数（信息），比如下单接口，请求参数中需有下单用户和下单商品信息。

④ 返回参数：响应请求返回的信息，比如查询订单接口，返回订单号及商品信息等。

⑤ 错误码：请求有误，返回的错误提示，包括该条请求的返回状态、错误原因及解决措施。

5.API的常见类型与场景

(1) 按开放范围分类

(2) 按功能分类

6.产品经理必须关注的API核心问题

(1) 业务侧

需求价值：API是否解决了业务痛点？

例：接入物流API实现实时轨迹跟踪 → 提升客户满意度。

成本评估：调用次数是否收费？开发维护成本如何？

例：第三方地图API按调用量计费，需预估用户规模。

合规性：数据隐私（GDPR）、行业监管要求是否满足？

(2) 用户体验侧—产品要介入和定义

交互反馈：API调用失败时，前端如何提示用户？

例：地图加载失败显示“重新加载”按钮，而非白屏。

数据映射：API返回的数据如何转化为界面展示？

例：API返回status: 1，前端需转换为“已发货”。

二、SDK（软件开发工具包）

1.SDK 的定义

SDK（Software Development Kit，软件开发工具包）是为特定平台、硬件、服务或框架提供的开发工具集合，通过提供预构建和标准化的模块、组件、程序包和工具，供开发人员快速构建、测试和部署软件应用程序，大幅降低开发复杂度。

常见的例子：

• 平台级 SDK：Android SDK、iOS SDK、Windows SDK。
• 支付类：支付宝 SDK、Stripe SDK（集成支付流程）。
• 地图类：高德地图 SDK、Google Maps SDK（地理位置服务）。
• 社交类：微信分享 SDK、极光推送 SDK、第三方登录SDK
• 广告类：Google AdMob SDK、穿山甲 SDK（应用内广告投放）。
• 硬件类 SDK：无人机 SDK（如 DJI SDK）、智能手表 SDK。

2.SDK 的核心组成

一个完整的 SDK 通常包含以下内容：

3.SDK 和 API 的区别和联系

SDK：是工具包，包含 API、文档、工具等，封装了完整功能，拿来即用。

API：仅是接口定义，用于实现特定交互（如 HTTP 请求），实现完整功能需要另外代码实现。

联系：SDK 通常封装了很多个 API，并提供更多开发支持。

比喻：

• API 像一本“菜谱”：告诉你如何用食材（参数）做菜（功能），但需要自己准备厨具（代码实现）。
• SDK 像“预制菜套餐”：食材、调料、厨具都打包好，直接按步骤加热即可。

三、前后端分离

1. 什么是前后端分离？

前后端分离是一种将前端（用户界面）与后端（服务器逻辑）独立开发、部署的架构模式。

两者通过API接口进行数据交互，前端负责界面展示和用户交互，后端专注于业务逻辑与数据处理。

后端做好逻辑处理和数据准备，前端定义交互和页面样式，从服务端获取数据并根据业务逻辑填充到页面。页面的响应速度提高，且接口和数据的复用性很高。

2. 为什么需要前后端分离？

传统开发模式的痛点：

• 耦合度高：后端直接生成HTML（如JSP、PHP），前后端代码混杂，修改困难。
• 效率低下：前后端开发需同步进行，无法并行。
• 多终端适配难：同一后端需适配Web、App等多端，重复开发。

前后端分离的优势：

• 独立开发：前端与后端团队可并行工作，通过接口文档约定交互规则。
• 技术栈灵活：前端可用React/Vue，后端可选Java/Go/Python。
• 易于扩展：支持多终端（Web、App、小程序）共用同一API。
• 性能优化：前端可本地缓存、异步加载，后端专注高并发处理。

3. 前后端分离的核心实现

(1) 前后端分工

(2) 数据交互流程

1. 用户操作：前端界面触发事件（如点击按钮）。
2. API请求：前端通过AJAX/Fetch API发送HTTP请求（GET/POST等）。
3. 后端处理：后端接收请求，验证权限，处理业务逻辑，查询数据库。
4. 返回数据：后端返回JSON/XML格式数据。
5. 前端渲染：前端解析数据并更新界面（如渲染列表、显示提示信息）。

四、同步、异步和回调

1. 同步

同步是指代码按顺序执行，每个操作必须等待前一个操作完成后才能开始。执行流程是阻塞的（Blocking）。

比如我们在美团APP购买团购券发起支付请求时，如果美团采取的是同步机制，将可能发生什么？

1. 支付过程阻塞，用户体验差

发起支付后，可能因为网络慢、第三方支付响应慢等原因，你返回美团APP，订单仍没有显示已支付，需要被迫等待结果返回，等待时间无法确定，用户体验非常不好。

2. 系统性能差

① 高并发场景系统易崩溃

美团作为高并发平台，如果采用同步支付策略，每个支付请求都会占用服务器资源直到完成。在高峰时段（如促销活动、节假日），大量请求会迅速堆积，导致服务器资源耗尽（如线程池阻塞、CPU/内存不足），最终引发系统崩溃。

② 资源浪费

同步模式下，服务器在等待支付结果（如与银行或第三方支付平台交互）时，线程会被“阻塞”，无法处理其他请求，导致资源利用率低下。

3.系统稳定性风险

① 单点故障影响全局

如果支付环节出现延迟或故障（如第三方支付接口异常），同步策略会导致整个订单流程被阻塞。例如，用户提交订单后，支付接口响应超时，可能导致订单状态无法更新，甚至引发订单数据不一致（如已扣款但订单未标记为成功）。

② 难以扩展和容错

同步流程难以通过分布式架构（如消息队列、异步回调）实现负载均衡和故障转移，系统抗风险能力较弱。

4. 业务逻辑复杂度增加

① 难以处理超时和重试

同步模式下，支付超时后的重试逻辑需要在当前线程中处理，可能引发死锁或资源竞争。例如，用户支付超时后手动刷新页面，可能导致重复提交订单和支付请求，增加重复扣款风险。

② 状态一致性维护困难

同步模式下，订单状态和支付状态需要严格实时同步，但实际中支付结果可能因网络延迟而滞后，导致订单状态与实际支付结果不一致（如用户已支付但订单未更新）。

推荐使用同步的业务场景：

1、需要严格顺序执行的任务

用户注册，必须按照手机号输入 → 身份验证 → 验证成功，写入用户信息的流程，如果异步处理，信息可能错乱。

2、实时性要求高的任务

比如验证码登录时，点击获取验证码，需要快速发送验证码给用户。

3、简单、快速、无高并发的任务

任务执行时间短，无需异步的复杂性，且结果需立即返回。

• 本地计算：如简单的数学运算、字符串处理等，同步执行更直接高效。
• 短时I/O操作：读取小文件或快速网络请求（如查询本地缓存），比如数据量很小的文件下载，可以使用同步机制，通过游览器直接下载。

4、对数据一致性要求更的场景

比如金融交易（支付、转账）、医疗机构的用药记录等。

总结：同步的核心价值是确保操作的顺序性、原子性和线程安全性，以避免数据不一致或系统崩溃。

2. 异步

异步机制的核心是“不等待耗时操作，通过回调处理结果”，同步机制资源占用高，适合数据一致性和实时性要求高的场景，相对应的，异步可以提高性能和吞吐量，适合可容忍数据短时不一致、高延迟的场景。

异步的典型使用场景：

① 网络请求（如API调用、HTTP请求）

场景特点：高延迟（几十毫秒到几秒不等），阻塞等待会导致界面冻结。

异步处理：发起请求后，主线程继续执行其他任务，响应返回后触发回调。

② 文件读写（如大文件上传/下载）

场景特点：I/O（(input/output)）操作耗时，同步处理会卡死程序。

异步处理：后台读写文件，完成后通过回调通知结果。—参考后台的导出功能

③ 高延迟场景

同步 vs 异步的适用场景：

3. 同步/异步回调（Callback）、轮询

回调是一个“回头再调用”的函数，它被传递给另一个函数作为参数，并在某个特定事件发生时被调用。

回调有同步回调和异步回调，举个生活化的例子：你去一家店订餐并告诉店家做好了通知你。

• 如果期间你一直在餐厅等待店家回复，没有进行其他操作，这个就是同步回调；
• 如果期间你去逛街，并让店家做好了打电话给你，这个是异步回调。
• 如果你在等待过程中每5分钟问一下店家做好了没有，直到得到确定或取消的结果（终态）。这个每5分钟问店家的操作，就是轮询。

轮询是一种主动查询机制，主动周期性地发送请求以获取最新数据或状态更新。

前后端都有可能是轮询的主动方，比如常见的支付场景，用户发起支付后，前端会持续一定频率轮询后端的支付状态查询接口。

若获取到状态变为“已支付”或“取消支付/支付失败”，则前端页面相应刷新；若超过一定时间未获取到状态变化，则刷新页面为待支付（不能让用户一直停留在支付结果加载页面）。

轮询涉及以下2个问题，产品经理应该考虑的：

• 资源消耗：频繁轮询可能占用 CPU、网络等资源，尤其在无新事件时会造成空转。
• 延迟不确定性：轮询间隔直接影响事件响应的实时性。例如，3秒轮询一次，最多会有 3秒的延迟，可能第1秒就状态更新了，3秒后查询已经有延迟了。

五、消息队列

消息队列（Message Queue），简称为MQ，是一种跨进程的通信机制，用于上下游传递消息。

IBM官网对于消息队列的定义：消息队列是消息传递中间件解决方案的一个组件，旨在支持独立的应用和服务之间的信息交换。

我们首先定义 参与消息队列的双方分别为消息的发送方/生产方、接收方/消费方。

我们可以把消息队列看作一个存放消息的容器（圆柱形），发送方往容器中塞入消息，接收方需要的时候从容器中取出并使用消息。

1.消息生产和消费异常：消息队列可能因网络、系统故障导致消息丢失、重复、延迟，需提前规划异常处理逻辑。

2.异步延迟问题：异步处理任务时，用户无法立即看到结果，需设计合理的交互反馈。

3.平衡业务和技术：作为产品，我们可能更看重用户体验和系统性能，但也要衡量代码改造和优化的代价。需要和研发团队共同讨论和确定最终方案。

以上完结，非研发，理解可能不到位，欢迎交流指正~