1. 为什么ABAP里发个HTTP请求值得单独写一篇
做SAP开发的朋友大概都有过这种体验：外部系统给了一个接口文档，说"就一个POST，传个JSON过去就行"，听起来五分钟的事，结果在ABAP里折腾了一下午。不是语法不会写，而是从CL_HTTP_CLIENT的创建方式、IF_HTTP_CLIENT的方法调用顺序，到HTTPS证书握手、返回数据编码、超时设置，每一步都藏着能让请求直接失败的细节。更麻烦的是，SAP系统版本跨度大，老系统上能跑的写法搬到新系统可能报错，新系统推荐的写法在老系统里又找不到类。
这篇内容就是围绕"ABAP发送HTTP、HTTPS请求并接收返回数据"这个主题，把我在实际项目里反复用到的完整方案拆开讲清楚。核心关键词是ABAP HTTP请求、HTTPS调用、CL_HTTP_CLIENT、返回数据解析，覆盖的场景包括：调用外部REST接口推送业务数据、从第三方平台拉取主数据、对接消息通知服务、以及和云平台做轻量级集成。适合的人群很明确——有ABAP基础但没怎么做过外部接口的开发者、需要快速验证接口连通性的顾问、以及想搞清楚HTTPS在ABAP里到底怎么配的运维同学。不管你是第一次写CL_HTTP_CLIENT，还是已经写过但总在证书和编码上翻车，下面这些内容应该都能对上你的痛点。
我先把结论性的东西摆出来：ABAP发HTTP请求，主流就两条路，一条是CL_HTTP_CLIENT配合IF_HTTP_CLIENT，另一条是较新的CL_WEB_HTTP_CLIENT。前者兼容性最好，几乎通吃所有版本；后者封装更友好，但依赖系统补丁级别。HTTPS的关键不在代码，而在SSL证书是否被系统信任，代码写得再对，证书链不通照样握手失败。返回数据的处理，重点在编码识别和结构解析，尤其是中文和特殊字符，编码搞错就是一堆乱码。这些判断贯穿全文，后面会逐个展开。
2. 整体方案设计与技术选型拆解
2.1 两条技术路线的取舍逻辑
ABAP里发HTTP请求，绕不开客户端类的选择。最经典的是CL_HTTP_CLIENT，通过CREATE_BY_URL或者CREATE静态方法拿到实例，再调用IF_HTTP_CLIENT接口的方法设置请求方法、头部、正文，最后SEND和RECEIVE。这套写法从很早的版本就存在，一直沿用至今，属于"写到哪都能跑"的方案。它的特点是控制粒度细，请求头、超时、代理、SSL选项都能单独设，缺点是步骤偏多，样板代码长。
另一条路是CL_WEB_HTTP_CLIENT，它把请求方法、URL、头部、正文封装成更接近现代HTTP客户端的形式，调用链短，可读性好。但它对系统版本和补丁有要求，在一些维护级别较低的系统上可能不存在或者行为不一致。我的实际选择逻辑很简单：如果目标系统版本不确定，或者代码要在多个客户端间移植，优先用CL_HTTP_CLIENT；如果确认系统较新、只在一个环境跑，用CL_WEB_HTTP_CLIENT能省不少代码。
这里要解释一个"为什么"：很多人觉得新类一定更好，但在ABAP世界里，向下兼容是硬约束。一个传输请求从开发机走到生产，中间可能经过不同补丁级别的系统，用了新类结果在某个环境报"类不存在"，排查成本远高于多写几行样板代码。所以选型的核心不是"哪个先进"，而是"哪个在目标环境里确定可用"。
2.2 HTTPS不是代码问题而是信任问题
新手最容易误解的一点：以为HTTPS请求失败是代码写错了。实际上，ABAP发HTTPS请求时，底层走的是系统配置的SSL客户端身份（SSL Client Identity），系统需要用这个身份去和对方服务器完成TLS握手，并验证对方证书是否由受信任的证书颁发机构签发。如果对方证书不在系统的信任列表里，握手直接失败，报错通常是SSL handshake with ... failed或者peer not authenticated这类。
所以HTTPS方案设计的核心是证书信任链的建立，而不是在代码里加什么参数。标准做法是通过事务码STRUST进入SSL客户端身份配置，把对方服务器的根证书或中间证书导入到对应的客户端身份下。有些场景对方用的是自签名证书，那就得把那张自签名证书本身导进去。这一步做完，代码里其实不需要任何特殊处理，CREATE_BY_URL传https地址就能正常走。
注意：证书导入后不是立刻对所有会话生效，部分场景需要重新建立连接或者重启相关服务进程。测试时如果刚导完证书还报握手失败，先别急着怀疑证书导错了，换个新会话再试一次。
2.3 返回数据处理的整体思路
请求发出去只是前半程，返回数据的处理才是真正体现功力的地方。整体思路分三层：第一层是状态判断，看HTTP状态码是不是2xx，非2xx的要区分是客户端错误（4xx）还是服务端错误（5xx），不同错误处理策略不同；第二层是编码转换，把返回的二进制或字符串按正确编码转成可读文本，中文场景下这一步错了后面全乱；第三层是结构解析，JSON用/UI2/CL_JSON或者CL_TREX_JSON_SERIALIZER反序列化，XML用CL_XML_DOCUMENT或者IF_IXML解析，纯文本就按分隔符拆。
这三层的顺序不能乱。我见过有人先解析再判断状态码，结果服务端返回一个错误页面的HTML，解析器直接抛异常，真正的错误信息反而被吞掉了。正确做法永远是先看状态码和返回内容类型，再决定怎么解析。
3. 核心细节解析与实操要点
3.1 CL_HTTP_CLIENT的创建与关键参数
创建客户端实例是第一步，也是最容易埋坑的一步。CL_HTTP_CLIENT=>CREATE_BY_URL是最常用的方式，传一个完整URL进去，系统自动解析出主机、端口、路径。但这里有个细节：如果URL里带了查询参数，某些版本对参数的处理会有差异，稳妥做法是把路径和参数分开，参数通过SET_URI或者请求正文传递。
创建之后，必须显式设置请求方法。默认方法不一定是你要的，IF_HTTP_CLIENT提供了SET_REQUEST_METHOD，传IF_HTTP_REQUEST=>CO_REQUEST_METHOD_GET、CO_REQUEST_METHOD_POST这些常量。GET和POST的区别不只是方法名，GET的参数在URL里，POST的参数在正文里，正文还要设置内容类型。
超时设置经常被忽略。默认超时可能很长，接口卡住时程序会一直等。通过SET_TIMEOUT设置一个合理值，比如30秒或60秒，具体看接口的响应特征。推送类接口可以短一些，拉取大批量数据的接口要留足时间。
DATA: lo_client TYPE REF TO if_http_client. cl_http_client=>create_by_url( EXPORTING url = 'https://example.com/api/endpoint' IMPORTING client = lo_client EXCEPTIONS argument_not_found = 1 plugin_not_active = 2 internal_error = 3 OTHERS = 4 ). IF sy-subrc <> 0. " 创建失败，记录错误并退出 RETURN. ENDIF. lo_client->propertytype_logon_popup = lo_client->co_disabled.上面这段里，propertytype_logon_popup设为禁用很关键。默认情况下，如果对方要求认证而系统没配好，可能弹出一个登录框，在后台作业里这会直接卡死。禁用弹窗后，认证失败会以异常形式返回，便于程序处理。
3.2 请求头与正文的设置要点
请求头决定了对方怎么理解你的请求。最常设的是Content-Type，JSON接口设application/json，表单设application/x-www-form-urlencoded，XML设application/xml。还有一个常被忽略的是Accept，告诉对方你期望的返回格式。有些接口不设Accept会返回默认格式，和你解析逻辑对不上。
正文设置分两种情况。如果正文是字符串，用SET_CDATA，它会按字符处理；如果正文是二进制或者需要精确控制编码，用SET_DATA配合XSTRING。这里有个坑：SET_CDATA在某些版本里对非ASCII字符的处理依赖系统代码页，中文可能出问题。稳妥做法是先把正文转成UTF-8的XSTRING，再用SET_DATA传，同时Content-Type里带上charset=utf-8。
DATA: lv_body TYPE string, lv_xbody TYPE xstring. lv_body = '{"key":"value","name":"测试数据"}'. " 转UTF-8二进制，避免编码问题 CALL METHOD cl_abap_conv_out_ce=>create( EXPORTING encoding = 'UTF-8' ) RECEIVING writer = DATA(lo_writer). lo_writer->write( lv_body ). lv_xbody = lo_writer->get_buffer( ). lo_client->request->set_header_field( name = 'Content-Type' value = 'application/json; charset=utf-8' ). lo_client->request->set_data( lv_xbody ).这段代码的价值在于把编码控制权握在自己手里。系统代码页可能是非UTF-8的，直接传字符串容易在传输环节被二次转换，导致对方收到乱码。显式转UTF-8二进制，等于告诉系统"这段数据你别动"，传输出去就是原样。
3.3 发送、接收与状态判断
设置完请求，调用SEND发送，再调用RECEIVE接收。这两个方法都可能抛异常，必须用TRY...CATCH包住。发送阶段的异常通常是网络层问题，比如主机不可达、连接超时；接收阶段的异常可能是对方返回了不符合协议的内容。
接收之后第一件事是取状态码，lo_client->response->get_status( )返回结构里包含code和reason。2xx表示成功，4xx表示请求有问题（参数错、认证失败、路径不对），5xx表示对方服务端出错。不同状态码的处理策略要分开写，不能一律当成功处理。
TRY. lo_client->send( EXCEPTIONS http_communication_failure = 1 http_invalid_state = 2 http_processing_failed = 3 OTHERS = 4 ). IF sy-subrc <> 0. " 发送失败处理 RETURN. ENDIF. lo_client->receive( EXCEPTIONS http_communication_failure = 1 http_invalid_state = 2 http_processing_failed = 3 OTHERS = 4 ). CATCH cx_root INTO DATA(lx_error). " 记录异常 RETURN. ENDTRY. DATA(ls_status) = lo_client->response->get_status( ). IF ls_status-code >= 200 AND ls_status-code < 300. " 成功，取返回数据 ELSE. " 失败，记录状态码和返回内容便于排查 ENDIF.提示：
SEND和RECEIVE之间不要插入其他逻辑，有些开发者习惯发送后先做点别的再接收，这在长连接场景下可能出问题。发送完立刻接收，是最稳的节奏。
3.4 返回数据的编码识别与转换
取返回数据用lo_client->response->get_data( )拿到XSTRING，或者用get_cdata( )拿到字符串。get_cdata方便但有编码风险，它按系统代码页解释数据，如果对方返回的是UTF-8而系统代码页不是，中文就乱。所以推荐用get_data拿二进制，再按返回头里的Content-Type中声明的编码去转。
如果返回头没声明编码，常见默认是UTF-8，但也不绝对。稳妥做法是先按UTF-8转，转出来如果发现乱码特征（比如大量问号或异常字符），再尝试其他编码。实际项目里我一般会看对方接口文档，文档说UTF-8就按UTF-8，文档没说就按UTF-8试，同时把原始二进制留一份用于排查。
DATA: lv_rbody TYPE xstring, lv_text TYPE string. lv_rbody = lo_client->response->get_data( ). CALL METHOD cl_abap_conv_in_ce=>create( EXPORTING encoding = 'UTF-8' input = lv_rbody ) RECEIVING reader = DATA(lo_reader). lo_reader->read( IMPORTING data = lv_text ).这段转换是中文场景的保命代码。少了它，返回的JSON里中文全是乱码，后续解析出来的字段值也没法用。
4. 完整实操流程与关键环节实现
4.1 从零搭建一个可复用的请求封装
实际项目里不会每次都从头写一遍请求逻辑，通常会封装一个通用方法，入参是URL、方法、请求头、正文，出参是状态码、返回头、返回正文。封装的价值在于把创建、设置、发送、接收、异常处理、资源释放这些重复动作收拢到一处，业务代码只关心"发什么、收什么"。
封装时要注意几个点。第一，客户端实例用完必须调CLOSE释放，否则连接资源不回收，高频调用会耗尽连接。第二，异常要转成明确的返回结构，而不是往上抛，业务层不需要关心底层是网络异常还是协议异常。第三，日志要记全，URL、请求方法、状态码、返回内容摘要都记下来，出问题时这是唯一的排查依据。
METHOD send_http_request. " 入参：iv_url, iv_method, it_header, iv_body " 出参：ev_status, ev_response, et_response_header DATA: lo_client TYPE REF TO if_http_client. cl_http_client=>create_by_url( EXPORTING url = iv_url IMPORTING client = lo_client EXCEPTIONS OTHERS = 1 ). IF sy-subrc <> 0. ev_status = 'CREATE_FAILED'. RETURN. ENDIF. lo_client->propertytype_logon_popup = lo_client->co_disabled. lo_client->set_request_method( iv_method ). LOOP AT it_header INTO DATA(ls_header). lo_client->request->set_header_field( name = ls_header-name value = ls_header-value ). ENDLOOP. IF iv_body IS NOT INITIAL. lo_client->request->set_cdata( iv_body ). ENDIF. TRY. lo_client->send( ). lo_client->receive( ). CATCH cx_root. ev_status = 'COMM_FAILED'. lo_client->close( ). RETURN. ENDTRY. DATA(ls_status) = lo_client->response->get_status( ). ev_status = ls_status-code. ev_response = lo_client->response->get_cdata( ). lo_client->close( ). ENDMETHOD.这个封装是骨架，实际用的时候根据项目需要加日志、加超时、加编码转换。骨架的意义是让你有个确定的起点，而不是每次面对空白编辑器回忆方法名。
4.2 GET请求的完整实现与参数处理
GET请求的参数拼在URL里，拼接时要注意URL编码。参数值里如果有空格、中文、特殊符号，不编码直接拼会导致对方解析错误。ABAP里用CL_HTTP_UTILITY=>ESCAPE_URL做编码，把参数值转成URL安全的形式再拼。
DATA: lv_param TYPE string, lv_url TYPE string. lv_param = cl_http_utility=>escape_url( '测试 值&特殊=字符' ). lv_url = |https://example.com/api/search?q={ lv_param }|.拼接完URL再走创建客户端的流程。GET请求一般不带正文，但有些接口要求带，那就按POST的方式设正文，方法仍然用GET，这种非标准用法要看对方文档确认。
GET的返回处理相对简单，多数是JSON或纯文本。JSON用/UI2/CL_JSON=>DESERIALIZE反序列化到结构或内表，注意目标结构的字段名要和JSON的key对应，大小写敏感的场景要特别留意。纯文本按业务约定的分隔符拆，拆之前先去掉首尾空白和换行。
4.3 POST请求的完整实现与JSON正文构造
POST是推送数据的主力方法，正文构造是关键。手工拼JSON字符串容易出错，尤其是嵌套结构和特殊字符转义。推荐用/UI2/CL_JSON=>SERIALIZE把ABAP结构或内表序列化成JSON字符串，它会自动处理转义和格式。
TYPES: BEGIN OF ty_item, id TYPE string, name TYPE string, qty TYPE i, END OF ty_item. DATA: ls_item TYPE ty_item, lv_json TYPE string. ls_item-id = '1001'. ls_item-name = '测试物料'. ls_item-qty = 10. lv_json = /ui2/cl_json=>serialize( data = ls_item pretty_name = /ui2/cl_json=>pretty_mode-camel_case ).序列化出来的JSON字段名默认按ABAP字段名转，pretty_mode-camel_case会把下划线命名转成驼峰，适配多数REST接口的命名习惯。如果对方要求特定字段名，可以在结构里用/UI2/CL_JSON的注解或者直接定义成对方要求的名字。
正文设进去之后，Content-Type必须和正文格式匹配，JSON正文配application/json，缺了这个头对方可能按表单解析，直接报格式错误。
4.4 HTTPS调用的证书配置实操
HTTPS调用的代码和HTTP几乎一样，区别只在URL的协议和证书信任。证书配置走STRUST事务码，进入后选择"SSL客户端身份"，找到系统实际使用的那个身份（通常是ANONYM或者某个具名身份），双击进入证书列表，点导入，把对方服务器的证书链导进去。
导入的证书来源有两种：一种是从对方服务器直接导出，浏览器访问对方地址，查看证书，导出为Base64格式；另一种是对方直接提供证书文件。导入时注意格式，STRUST接受Base64编码的证书文件，二进制格式的可能需要先转换。
导入完成后，在同一个界面点"证书"按钮可以查看信任列表，确认目标证书在列表里。然后回到代码测试，如果还报握手失败，检查三点：URL里的主机名和证书里的主机名是否一致（证书是绑定域名的，用IP访问可能不匹配）、证书是否过期、系统时间是否准确（时间偏差大会导致证书有效期校验失败）。
注意：证书导入属于系统级配置，改动会影响该系统上所有使用同一SSL客户端身份的程序。操作前确认影响范围，生产环境改动要走变更流程。
4.5 返回JSON的解析与异常兜底
返回JSON解析用/UI2/CL_JSON=>DESERIALIZE，目标结构按对方返回的字段定义。解析时最容易出问题的是字段类型不匹配，比如对方返回数字但ABAP结构定义成字符串，或者对方返回null但ABAP字段不允许初始值。/UI2/CL_JSON对null的处理是跳过赋值，目标字段保持初始值，一般不会报错，但业务上要能接受初始值。
解析异常必须兜底。对方返回的如果不是合法JSON（比如错误时返回HTML），反序列化会抛异常。用TRY...CATCH包住，捕获后把原始返回内容记进日志，这是排查对方接口问题的第一手材料。
DATA: ls_result TYPE ty_result. TRY. /ui2/cl_json=>deserialize( EXPORTING json = lv_response pretty_name = /ui2/cl_json=>pretty_mode-camel_case CHANGING data = ls_result ). CATCH cx_root INTO DATA(lx_json). " 记录原始返回内容，便于排查 RETURN. ENDTRY.5. 常见问题与排查技巧实录
5.1 握手失败与证书问题的排查路径
握手失败是HTTPS场景最高频的问题，报错信息通常指向SSL层。排查顺序我一般这样走：先确认URL协议是https且主机名正确，再用浏览器或命令行工具访问同一地址确认对方服务正常，然后检查STRUST里对应SSL客户端身份下是否有对方证书链，最后检查系统时间和证书有效期。
有一个隐蔽的坑：对方服务器可能配置了多个证书，或者用了中间证书而没在握手时完整下发。这种情况下浏览器能访问是因为浏览器会自动补全中间证书，而ABAP系统不会。解决办法是把完整的证书链（服务器证书加中间证书）一起导入。判断方法是对比浏览器里看到的证书链和STRUST里导入的证书，缺哪张补哪张。
另一个坑是主机名不匹配。证书是签发给特定域名的，如果代码里用IP地址访问，而证书只对域名有效，握手会失败。这种情况要么改用域名访问，要么让对方提供包含IP的证书（少见）。实际项目里遇到过测试环境用IP、生产环境用域名的情况，测试通生产不通，就是这个问题。
5.2 中文乱码的定位与解决
中文乱码的表现是返回内容里中文变成问号、方块或者一串看不懂的字符。定位思路是先确认乱码发生在哪个环节：是对方返回的就是乱码，还是ABAP接收后转换错了。判断方法是把返回的原始XSTRING用十六进制查看，对照UTF-8编码表看字节序列是否正确。如果原始字节是对的，那就是转换环节的编码参数错了；如果原始字节就不对，那是对方的问题或者传输环节的问题。
解决方向有两个：一是接收端显式按UTF-8转换，用CL_ABAP_CONV_IN_CE指定编码；二是发送端也统一用UTF-8，避免请求和返回编码不一致。两头都统一到UTF-8，是中文场景最省心的做法。
5.3 超时与连接资源耗尽
高频调用外部接口时，如果每次都不CLOSE客户端实例，连接资源会累积，最终报连接数超限。这个问题的特征是程序跑一段时间后开始大量失败，重启应用服务器后恢复。解决办法很简单：所有创建了客户端的地方，无论成功失败，最后都要调CLOSE。用TRY...CATCH...CLEANUP结构确保异常路径也能释放。
超时设置不合理也会引发问题。超时太短，对方处理慢一点就失败；超时太长，对方卡死时程序一直等，占用工作进程。合理值要看接口的实际响应时间分布，取P99响应时间的两到三倍比较稳妥。推送类接口30秒通常够，批量拉取类接口可能要几分钟。
5.4 常见问题速查表
| 现象 | 可能原因 | 排查方向 | 解决方式 |
|---|---|---|---|
| 握手失败 | 证书未信任 | 检查STRUST信任列表 | 导入完整证书链 |
| 握手失败 | 主机名不匹配 | 对比URL主机名与证书域名 | 改用域名访问 |
| 握手失败 | 系统时间偏差 | 检查系统时间 | 校准系统时间 |
| 返回乱码 | 编码不一致 | 查看原始XSTRING字节 | 统一UTF-8转换 |
| 连接超限 | 未释放客户端 | 检查CLOSE调用 | 所有路径补CLOSE |
| 请求超时 | 超时设置过短 | 看接口响应时间 | 调大超时值 |
| 解析异常 | 返回非预期格式 | 记录原始返回内容 | 加格式判断和兜底 |
| 认证失败 | 未设认证头 | 检查对方认证要求 | 补Authorization头 |
5.5 几个踩过坑才明白的实操心得
第一个心得：永远先记录原始返回再解析。我早期的习惯是拿到返回直接解析，解析失败才回头找原始内容，但那时候原始内容可能已经被覆盖或者没保存。后来改成接收后第一件事就是把原始XSTRING和转换后的文本都记进日志表，解析失败时直接查日志，排查效率高一个量级。
第二个心得：测试环境用真实证书链。有些项目测试环境图省事，对方给了自签名证书就导自签名，结果生产环境换成正式证书链，中间证书没导全，上线当天握手失败。稳妥做法是测试阶段就按生产的证书链标准配，避免环境差异。
第三个心得：封装里留一个"调试模式"开关。调试模式下把请求头、请求正文、返回头、返回正文全量输出到日志，正常模式只记摘要。排查疑难问题时打开调试模式，一次就能看清全貌，比反复加日志改代码快得多。
第四个心得：GET请求的参数编码别偷懒。参数值里带空格、中文、&、=这些字符时，不编码直接拼URL，对方解析出来的参数值可能被截断或者错位。CL_HTTP_UTILITY=>ESCAPE_URL一行代码的事，省了它后面排查半天。
6. 扩展场景与性能优化建议
6.1 批量调用时的连接复用思路
单次请求的写法掌握后，批量场景要考虑效率。每次请求都创建和关闭客户端，开销主要在连接建立和TLS握手。如果对方接口支持长连接，可以在一个客户端实例上连续发多次请求，减少握手次数。但要注意，长连接下每次请求后要正确读取返回，否则下一次请求可能读到上一次的残留数据。
不过连接复用要谨慎，不是所有接口都适合。对方如果对连接数有限制，或者接口本身是无状态的短请求，复用带来的收益有限，反而增加了状态管理的复杂度。我的经验是：单次批量在几十次以内，老老实实每次创建关闭，代码简单不易错；上百次的批量，再考虑复用或者并发。
6.2 并发调用的可行性与风险
ABAP里做并发调用，常见方式是用RFC异步调用或者SPTA框架起并行任务。并发能缩短总耗时，但风险也明显：对方接口可能限流，并发太高被拒绝；并行任务的错误处理比串行复杂，一个任务失败不影响其他任务，但汇总结果时要能区分；资源占用上升，工作进程被大量占用可能影响其他业务。
实际项目里我用并发的前提是：对方明确支持并发且给了限流阈值，单次批量确实大到串行不可接受，且有完善的错误汇总机制。三个条件缺一个，我都倾向串行加优化单次请求效率，而不是上并发。
6.3 日志与监控的落地方式
外部接口调用的日志，我一般记这几项：调用时间、目标URL（脱敏处理，去掉敏感参数）、请求方法、状态码、耗时、返回内容摘要（截断到合理长度）、异常信息。日志存自定义表，按时间分区，定期归档。监控方面，可以做一个简单的报表，统计各接口的成功率、平均耗时、失败分布，接口出问题时能快速定位是普遍失败还是个别失败。
日志的价值在出问题时才体现，但记录的成本是持续的。所以日志设计要平衡：记太少排查时抓瞎，记太多存储和性能压力大。我的做法是正常调用记摘要，异常调用记全量，这样既控制了日常开销，又保证了问题现场可还原。
6.4 安全层面的几个基本约束
调用外部接口时，认证信息（如Token、密钥）不能硬编码在代码里，应该放配置表或者安全存储，按环境区分。URL和参数里的敏感信息在日志里要脱敏。对方返回的错误信息如果包含内部细节，不要直接展示给最终用户，转成友好的提示。这些约束不复杂，但落地时容易图省事跳过，后面审计或者出安全事件时就是麻烦。
另外，对外调用要有明确的失败处理策略。是重试、是降级、还是直接报错让业务中断，不同接口不同对待。推送类接口失败可以重试，但要防重复推送；拉取类接口失败可以降级用缓存数据；关键业务接口失败就该明确报错，不能静默吞掉。
这套东西写下来，核心其实就几句话：客户端选兼容性好的，HTTPS重点在证书信任，返回数据先判状态再转编码后解析，封装里把释放和日志做扎实，批量场景量力而行。剩下的就是在具体项目里对着对方接口文档调参数、对字段、试错误场景。我自己的习惯是每接一个新接口，先写个最小可跑的测试程序把连通性、编码、返回格式三件事验证完，再往正式代码里搬，这样能把大部分坑挡在早期。
