Mock测试【免费下载链接】motoA library that allows you to easily mock out tests based on AWS infrastructure.项目地址https://gitcode.com/gh_mirrors/mo/moto点击查看免费下载Moto 通过拦截发往 AWS 的 HTTP 请求来模拟 AWS 基础设施。要新增或调试某个服务的 mock 行为最核心的一步就是确定「该服务哪些 URL 应该被拦截」并让请求精确命中对应 backend 的处理方法。本文以 Moto 官方开发文档 urls.rst 为骨架结合仓库内 botocore_stubber.py、backend_index.py、responses.py 等源码实现系统讲解三种确定拦截 URL 的方法、如何使用 MITM 代理抓取真实 AWS 请求以及拦截链路在 Moto 内部是如何工作的。一、为什么 Moto 需要知道「拦截哪些 URL」Moto 的本质是一个请求级 mock它不替换 boto3 的整个客户端而是监听客户端发出的每个 AWS 请求凡是被判定为「应该拦截」的请求就不再发往真实的 amazonaws.com而是交给内存中的 backend 直接返回模拟响应未被判定为拦截的请求则原样放行或直接返回 404。从 botocore_stubber.py 的process_request可以看出Moto 对每个请求做两级匹配服务级匹配遍历 backend_index.py 中自动生成的backend_url_patterns服务名 正则判断该 URL 属于哪个 AWS 服务如https://ses.xxx.amazonaws.com属于ses操作级匹配拿到对应 backend 后再遍历该服务urls.py中声明的url_pathsURL 正则 → 处理方法命中后调用 BaseResponse._dispatch 完成参数解析、Action 分发与响应序列化。因此URL 正则写对了请求才能被截获并路由到正确的方法URL 正则写漏了请求就会落到 botocore_stubber.py 末尾的兜底分支返回404, {}, Not yet implemented。确定 URL 是给 Moto 新增/修正一个 API 的最前置步骤。二、确定拦截 URL 的三种方式官方文档给出了三种逐步进阶的确定方式可按需组合使用。方式一直接参考已有服务的 URL 写法如果你要实现的新 API 与某个已实现的 API 同属一个服务最省力的做法是打开该服务的urls.py照着现有 pattern 复制、微调路径然后祈祷它能匹配上文档原话是 copy/paste the url-path for an existing feature and cross your fingers and toes。以 SES 为例moto/ses/urls.py 声明了from .responses import EmailResponse url_bases [ rhttps?://email\.(.)\.amazonaws\.com, rhttps?://ses\.(.)\.amazonaws\.com, ] url_paths {{0}/$: EmailResponse.dispatch}其中url_bases服务级正则决定哪些主机名属于该服务。SES 同时支持历史域名email.*.amazonaws.com与现域名ses.*.amazonaws.com这类「新旧域名并存」的模式在 Moto 中很常见例如dynamodb同时匹配dynamodb.*.amazonaws.com与*.ddb.*.amazonaws.com见 backend_index.pyurl_paths操作级正则{0}会被替换为url_bases中的完整 base后面的路径部分才是关键。SES 几乎所有操作send_email、list_identities、verify_domain_dkim等都走POST /这一个路径因此{{0}/$: EmailResponse.dispatch}一条即可覆盖。不过这种方式的风险在于如果新 API 的路径里带有路径参数如/jobsByPipeline/{PipelineId}照抄一个只匹配根路径的 pattern 是拦截不到的此时应优先采用方式二。方式二从 botocore 服务模型中读取 requestUribotocore 自带每个 AWS 服务的完整 API 模型botocore/data/service/version/service-2.json其中每个操作都声明了http.requestUri字段——这正是该操作真实的 HTTP 请求路径。Moto 的 REST 风格服务restJson1 / restXml依赖这套模型做「路径 → Action」的反查在 responses.py 的_get_method_urls中Moto 为每个服务加载 boto3 客户端遍历operation_names取出每个操作的http[method]与http[requestUri]再调用BaseResponse.uri_to_regexp把 URI 模板编译为正则def uri_to_regexp(uri: str) - str: converts uri w/ placeholder to regexp /accounts/{AwsAccountId}/namespaces/{Namespace}/groups - ^/accounts/(?PAwsAccountId[^/])/namespaces/(?PNamespace[^/])/groups$ /trustStores/{trustStoreArn} - ^/trustStores/(?PtrustStoreArn.)$ 细节要点responses.py花括号{Param}变成具名捕获组(?PParam[^/])捕获到的值会在parse_parameters阶段通过self.uri_match.groupdict()注入请求参数见 responses.pySmithy 规范中的贪婪标签{Param}或位于 URI 末尾的标签会编译为(?PParam.)用于匹配跨/的路径匹配时按正则长度降序排序保证/mrap/instances/{name}/policy这类更具体的 pattern 优先于/mrap/instances/{name}见 responses.py。仓库内的协议测试夹具 rest-json.json 就是 requestUri 与解析期望值的真实样本例如/2014-01-01/jobsByPipeline/{PipelineId}、/2014-01-01/vaults/{vaultName}/archives等可作为理解这套「URI 模板 → 正则 → 具名参数」机制的直观教材。方式三用代理抓取真实的 AWS 请求如果目标 API 的 URI 结构复杂、或者你希望连请求参数、请求/响应格式一起拿到最可靠的办法是对 AWS 本身发一次真实调用并用本地代理把请求截下来。安装并启动一个 HTTPS 代理例如 MITMProxy默认监听localhost:8080将代理地址写入环境变量让 AWS CLI / SDK 的流量经过代理对目标服务发起一次调用即可在代理界面中看到完整的 URL、请求头、请求体与响应体——这些信息足以反推出url_bases/url_paths正则以及响应序列化格式。三、实战用代理拦截 AWS 请求3.1 通过 AWS CLI 走代理官方文档给出的 CLI 方式bashexport HTTP_PROXYhttp://localhost:8080 export HTTPS_PROXYhttp://localhost:8080 aws ses describe-rule-set --no-verify-ssl说明HTTP_PROXY/HTTPS_PROXY让所有经过 AWS CLI 的流量先到达本地代理--no-verify-ssl关闭 SSL 证书校验否则 MITM 代理自签证书会被 botocore 的 SSL 校验拦下示例中的describe-rule-set并非真实存在的 SES 操作这里仅用于演示「任何一次调用都会被代理记录」这一流程。实际操作时请替换为你要研究的目标 API。3.2 通过 Python 的 boto3 走代理官方文档给出的 Python 方式from botocore.config import Config proxy_config Config(proxies{http: localhost:8080, https: localhost:8080}) boto3.client(ses, configproxy_config, use_sslFalse, verifyFalse)说明Config(proxies...)为单个客户端注入代理不影响进程内其他客户端use_sslFalse与verifyFalse配合代理的中间人证书避免握手失败拿到抓包结果后重点是关注request.path决定url_paths正则以及request.headers如X-Amz-Target决定 query-protocol 服务的 Action见 responses.py 的_get_action逻辑。3.3 抓包结果的解读方向从代理记录中应重点提取四类信息信息用途完整 URLscheme host path反推url_bases正则与url_paths路径HTTP 方法GET/POST/PUT/…用于 rest 风格服务的_get_action_from_method_and_request_uri分发请求参数 / body验证responses.py中的参数解析逻辑响应格式XML / JSON判断该服务走 query / rest-json / rest-xml 协议决定序列化方式四、源码级透视一个请求从「到达」到「被处理」的完整链路理解了「如何确定 URL」之后再看 Moto 内部如何处理它能帮你更快定位「为什么我的正则没拦截到」。整条链路如下URL 归一化BotocoreStubber.process_request先调用 get_equivalent_url_in_aws_domain 把 ISO 区域域名.amazonaws.com.cn等和自定义 S3 endpoint 归一化为标准amazonaws.com域再去掉 query string得到干净的clean_url见 botocore_stubber.py服务级匹配遍历 backend_index.py 的backend_url_patterns一旦命中某服务再检查该服务是否在 passthrough / whitelist 例外清单中见 config.py 的passthrough_service与service_whitelisted操作级匹配从backends.get_backend(service)取得 backend 实例遍历其urls属性由各服务urls.py的url_paths组装而来用re.compile(url).match(clean_url)命中具体处理方法并返回(status, headers, body)见 botocore_stubber.py响应分发命中后调用EmailResponse.dispatch这类入口 → BaseResponse._dispatch →call_action()见 responses.py。call_action先把 Action 名用camelcase_to_underscores转成小写下划线SendEmail→send_email再在responses.py的类方法里查表调用找不到就抛NotImplementedError。关于第 2 步的backend_url_patterns它是 scripts/update_backend_index.py 自动生成的缓存脚本遍历moto.backend.urls模块把每个模块的url_bases收集为(backend, re.compile(pattern))写入 backend_index.py并显式忽略moto_server、neptune、opensearch与 RDS / ES 共享 URL等特例。也就是说你在某个服务的urls.py里新增url_bases条目后需要重新生成 backend_index 缓存新的主机名才会进入拦截表。反向的工具函数是 get_service_from_url其测试用例见 test_backends.py如https://bucket.s3.amazonaws.com→s3、https://unknown.com→None。五、例外机制不拦截某些 URL / 服务并非所有经过的 AWS 请求都必须拦截。Moto 提供了两层「放行」配置源码见 config.pypassthrough.urls按正则匹配的 URL 直接放行不进入 Moto backend。例如把https://ec2.*.amazonaws.com加入后EC2 请求会真实发往 AWS。相关测试见 test_request_passthrough.py含通配 URL 的test_passthrough_calls_for_wildcard_urlspassthrough.services按服务名整体放行service_whitelist只 mock 白名单内的服务白名单外的服务命中时直接抛出ServiceNotWhitelisted见 botocore_stubber.py。在开发调试时如果你希望「某个请求真实打到 AWS、其余照常 mock」可以在测试装饰器中配置from moto import mock_aws mock_aws( config{ core: { passthrough: {urls: [https://ec2\\.eu-west-1\\.amazonaws\\.com/.*]}, } } ) def test_something(): ...这类代理场景的配置方式可进一步参考 test_proxy.py 的test_configure_passedthrough_urls。六、开发时的验证与调试建议先确认服务级匹配用moto.backends.get_service_from_url(url)直接验证某个 URL 会被判给哪个服务返回None说明url_bases/ backend_index 有问题再确认操作级匹配检查该服务urls.py的url_paths正则是否覆盖目标路径。若拦截到了但报NotImplementedError: The xxx action has not been implemented说明服务级匹配成功、只是responses.py中缺少对应方法——此时可参考 development_tips/index.rst 的命名规范responses.py负责输入输出格式化与校验models.py负责核心逻辑测试方法名为test_import_certificate式按既有服务的模式补齐实现关注协议差异query 协议服务通过Action参数或X-Amz-Target头分发见 responses.pyrest 协议服务通过method requestUri分发见 responses.py两者确定 URL 的侧重点不同善用代理当正则始终无法命中时用方式三抓一次真实请求对比实际 path 与你的正则最常见的问题是漏掉了尾随斜杠、路径参数未转义为{Param}模板或$未被转义uri_to_regexp中会专门处理$转义见 responses.py。七、小结确定 Moto 要拦截哪些 URL本质上就是回答两个问题这个主机名属于哪个服务url_bases与这个路径应该路由到哪个操作url_paths。三种方式——照抄现有服务、读 botocore 服务模型的requestUri、用 MITM 代理抓真实 AWS 请求——覆盖了从「快速实现」到「精确还原」的全部需求。配合 botocore_stubber.py 的两级匹配链路与 backend_index.py 的自动生成机制开发者可以在几分钟内定位并修正任意服务的 URL 拦截问题为后续在responses.py/models.py中实现具体 API 打好基础。赞分享Mock测试【免费下载链接】motoA library that allows you to easily mock out tests based on AWS infrastructure.项目地址https://gitcode.com/gh_mirrors/mo/moto点击查看免费下载相关推荐Moto Proxy Mode 实战指南用 HTTPS 代理透明拦截并 Mock 所有 AWS SDK 请求Moto Proxy Mode 实战指南用 HTTPS 代理透明拦截并 Mock 所有 AWS SDK 请求 Moto 除了提供进程内的 mock 装饰器还Mock测试NocoBase 客户端请求开发指南APIClient、拦截器与自定义请求头全解析NocoBase 客户端请求开发指南APIClient、拦截器与自定义请求头全解析 NocoBase 提供了一套基于 Axios 封装的 APIClient低代码后端前端人工智能AI 应用工作流自动化Moto 使用 FAQ 深度解读测试数据生命周期、并发安全与自定义请求拦截实战Moto 使用 FAQ 深度解读测试数据生命周期、并发安全与自定义请求拦截实战 Moto 是一个基于 Python 的 AWS 基础设施模拟库让你可以在本地Mock测试上一篇3种导入方式详解vite-svg-loader让SVG在Vue项目中灵活应用下一篇Sentry Dart SDK 教程创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Moto 开发指南：如何确定并拦截 AWS 请求的 URL（Intercepting URLs 全解析）
Mock测试【免费下载链接】motoA library that allows you to easily mock out tests based on AWS infrastructure.项目地址https://gitcode.com/gh_mirrors/mo/moto点击查看免费下载Moto 通过拦截发往 AWS 的 HTTP 请求来模拟 AWS 基础设施。要新增或调试某个服务的 mock 行为最核心的一步就是确定「该服务哪些 URL 应该被拦截」并让请求精确命中对应 backend 的处理方法。本文以 Moto 官方开发文档 urls.rst 为骨架结合仓库内 botocore_stubber.py、backend_index.py、responses.py 等源码实现系统讲解三种确定拦截 URL 的方法、如何使用 MITM 代理抓取真实 AWS 请求以及拦截链路在 Moto 内部是如何工作的。一、为什么 Moto 需要知道「拦截哪些 URL」Moto 的本质是一个请求级 mock它不替换 boto3 的整个客户端而是监听客户端发出的每个 AWS 请求凡是被判定为「应该拦截」的请求就不再发往真实的 amazonaws.com而是交给内存中的 backend 直接返回模拟响应未被判定为拦截的请求则原样放行或直接返回 404。从 botocore_stubber.py 的process_request可以看出Moto 对每个请求做两级匹配服务级匹配遍历 backend_index.py 中自动生成的backend_url_patterns服务名 正则判断该 URL 属于哪个 AWS 服务如https://ses.xxx.amazonaws.com属于ses操作级匹配拿到对应 backend 后再遍历该服务urls.py中声明的url_pathsURL 正则 → 处理方法命中后调用 BaseResponse._dispatch 完成参数解析、Action 分发与响应序列化。因此URL 正则写对了请求才能被截获并路由到正确的方法URL 正则写漏了请求就会落到 botocore_stubber.py 末尾的兜底分支返回404, {}, Not yet implemented。确定 URL 是给 Moto 新增/修正一个 API 的最前置步骤。二、确定拦截 URL 的三种方式官方文档给出了三种逐步进阶的确定方式可按需组合使用。方式一直接参考已有服务的 URL 写法如果你要实现的新 API 与某个已实现的 API 同属一个服务最省力的做法是打开该服务的urls.py照着现有 pattern 复制、微调路径然后祈祷它能匹配上文档原话是 copy/paste the url-path for an existing feature and cross your fingers and toes。以 SES 为例moto/ses/urls.py 声明了from .responses import EmailResponse url_bases [ rhttps?://email\.(.)\.amazonaws\.com, rhttps?://ses\.(.)\.amazonaws\.com, ] url_paths {{0}/$: EmailResponse.dispatch}其中url_bases服务级正则决定哪些主机名属于该服务。SES 同时支持历史域名email.*.amazonaws.com与现域名ses.*.amazonaws.com这类「新旧域名并存」的模式在 Moto 中很常见例如dynamodb同时匹配dynamodb.*.amazonaws.com与*.ddb.*.amazonaws.com见 backend_index.pyurl_paths操作级正则{0}会被替换为url_bases中的完整 base后面的路径部分才是关键。SES 几乎所有操作send_email、list_identities、verify_domain_dkim等都走POST /这一个路径因此{{0}/$: EmailResponse.dispatch}一条即可覆盖。不过这种方式的风险在于如果新 API 的路径里带有路径参数如/jobsByPipeline/{PipelineId}照抄一个只匹配根路径的 pattern 是拦截不到的此时应优先采用方式二。方式二从 botocore 服务模型中读取 requestUribotocore 自带每个 AWS 服务的完整 API 模型botocore/data/service/version/service-2.json其中每个操作都声明了http.requestUri字段——这正是该操作真实的 HTTP 请求路径。Moto 的 REST 风格服务restJson1 / restXml依赖这套模型做「路径 → Action」的反查在 responses.py 的_get_method_urls中Moto 为每个服务加载 boto3 客户端遍历operation_names取出每个操作的http[method]与http[requestUri]再调用BaseResponse.uri_to_regexp把 URI 模板编译为正则def uri_to_regexp(uri: str) - str: converts uri w/ placeholder to regexp /accounts/{AwsAccountId}/namespaces/{Namespace}/groups - ^/accounts/(?PAwsAccountId[^/])/namespaces/(?PNamespace[^/])/groups$ /trustStores/{trustStoreArn} - ^/trustStores/(?PtrustStoreArn.)$ 细节要点responses.py花括号{Param}变成具名捕获组(?PParam[^/])捕获到的值会在parse_parameters阶段通过self.uri_match.groupdict()注入请求参数见 responses.pySmithy 规范中的贪婪标签{Param}或位于 URI 末尾的标签会编译为(?PParam.)用于匹配跨/的路径匹配时按正则长度降序排序保证/mrap/instances/{name}/policy这类更具体的 pattern 优先于/mrap/instances/{name}见 responses.py。仓库内的协议测试夹具 rest-json.json 就是 requestUri 与解析期望值的真实样本例如/2014-01-01/jobsByPipeline/{PipelineId}、/2014-01-01/vaults/{vaultName}/archives等可作为理解这套「URI 模板 → 正则 → 具名参数」机制的直观教材。方式三用代理抓取真实的 AWS 请求如果目标 API 的 URI 结构复杂、或者你希望连请求参数、请求/响应格式一起拿到最可靠的办法是对 AWS 本身发一次真实调用并用本地代理把请求截下来。安装并启动一个 HTTPS 代理例如 MITMProxy默认监听localhost:8080将代理地址写入环境变量让 AWS CLI / SDK 的流量经过代理对目标服务发起一次调用即可在代理界面中看到完整的 URL、请求头、请求体与响应体——这些信息足以反推出url_bases/url_paths正则以及响应序列化格式。三、实战用代理拦截 AWS 请求3.1 通过 AWS CLI 走代理官方文档给出的 CLI 方式bashexport HTTP_PROXYhttp://localhost:8080 export HTTPS_PROXYhttp://localhost:8080 aws ses describe-rule-set --no-verify-ssl说明HTTP_PROXY/HTTPS_PROXY让所有经过 AWS CLI 的流量先到达本地代理--no-verify-ssl关闭 SSL 证书校验否则 MITM 代理自签证书会被 botocore 的 SSL 校验拦下示例中的describe-rule-set并非真实存在的 SES 操作这里仅用于演示「任何一次调用都会被代理记录」这一流程。实际操作时请替换为你要研究的目标 API。3.2 通过 Python 的 boto3 走代理官方文档给出的 Python 方式from botocore.config import Config proxy_config Config(proxies{http: localhost:8080, https: localhost:8080}) boto3.client(ses, configproxy_config, use_sslFalse, verifyFalse)说明Config(proxies...)为单个客户端注入代理不影响进程内其他客户端use_sslFalse与verifyFalse配合代理的中间人证书避免握手失败拿到抓包结果后重点是关注request.path决定url_paths正则以及request.headers如X-Amz-Target决定 query-protocol 服务的 Action见 responses.py 的_get_action逻辑。3.3 抓包结果的解读方向从代理记录中应重点提取四类信息信息用途完整 URLscheme host path反推url_bases正则与url_paths路径HTTP 方法GET/POST/PUT/…用于 rest 风格服务的_get_action_from_method_and_request_uri分发请求参数 / body验证responses.py中的参数解析逻辑响应格式XML / JSON判断该服务走 query / rest-json / rest-xml 协议决定序列化方式四、源码级透视一个请求从「到达」到「被处理」的完整链路理解了「如何确定 URL」之后再看 Moto 内部如何处理它能帮你更快定位「为什么我的正则没拦截到」。整条链路如下URL 归一化BotocoreStubber.process_request先调用 get_equivalent_url_in_aws_domain 把 ISO 区域域名.amazonaws.com.cn等和自定义 S3 endpoint 归一化为标准amazonaws.com域再去掉 query string得到干净的clean_url见 botocore_stubber.py服务级匹配遍历 backend_index.py 的backend_url_patterns一旦命中某服务再检查该服务是否在 passthrough / whitelist 例外清单中见 config.py 的passthrough_service与service_whitelisted操作级匹配从backends.get_backend(service)取得 backend 实例遍历其urls属性由各服务urls.py的url_paths组装而来用re.compile(url).match(clean_url)命中具体处理方法并返回(status, headers, body)见 botocore_stubber.py响应分发命中后调用EmailResponse.dispatch这类入口 → BaseResponse._dispatch →call_action()见 responses.py。call_action先把 Action 名用camelcase_to_underscores转成小写下划线SendEmail→send_email再在responses.py的类方法里查表调用找不到就抛NotImplementedError。关于第 2 步的backend_url_patterns它是 scripts/update_backend_index.py 自动生成的缓存脚本遍历moto.backend.urls模块把每个模块的url_bases收集为(backend, re.compile(pattern))写入 backend_index.py并显式忽略moto_server、neptune、opensearch与 RDS / ES 共享 URL等特例。也就是说你在某个服务的urls.py里新增url_bases条目后需要重新生成 backend_index 缓存新的主机名才会进入拦截表。反向的工具函数是 get_service_from_url其测试用例见 test_backends.py如https://bucket.s3.amazonaws.com→s3、https://unknown.com→None。五、例外机制不拦截某些 URL / 服务并非所有经过的 AWS 请求都必须拦截。Moto 提供了两层「放行」配置源码见 config.pypassthrough.urls按正则匹配的 URL 直接放行不进入 Moto backend。例如把https://ec2.*.amazonaws.com加入后EC2 请求会真实发往 AWS。相关测试见 test_request_passthrough.py含通配 URL 的test_passthrough_calls_for_wildcard_urlspassthrough.services按服务名整体放行service_whitelist只 mock 白名单内的服务白名单外的服务命中时直接抛出ServiceNotWhitelisted见 botocore_stubber.py。在开发调试时如果你希望「某个请求真实打到 AWS、其余照常 mock」可以在测试装饰器中配置from moto import mock_aws mock_aws( config{ core: { passthrough: {urls: [https://ec2\\.eu-west-1\\.amazonaws\\.com/.*]}, } } ) def test_something(): ...这类代理场景的配置方式可进一步参考 test_proxy.py 的test_configure_passedthrough_urls。六、开发时的验证与调试建议先确认服务级匹配用moto.backends.get_service_from_url(url)直接验证某个 URL 会被判给哪个服务返回None说明url_bases/ backend_index 有问题再确认操作级匹配检查该服务urls.py的url_paths正则是否覆盖目标路径。若拦截到了但报NotImplementedError: The xxx action has not been implemented说明服务级匹配成功、只是responses.py中缺少对应方法——此时可参考 development_tips/index.rst 的命名规范responses.py负责输入输出格式化与校验models.py负责核心逻辑测试方法名为test_import_certificate式按既有服务的模式补齐实现关注协议差异query 协议服务通过Action参数或X-Amz-Target头分发见 responses.pyrest 协议服务通过method requestUri分发见 responses.py两者确定 URL 的侧重点不同善用代理当正则始终无法命中时用方式三抓一次真实请求对比实际 path 与你的正则最常见的问题是漏掉了尾随斜杠、路径参数未转义为{Param}模板或$未被转义uri_to_regexp中会专门处理$转义见 responses.py。七、小结确定 Moto 要拦截哪些 URL本质上就是回答两个问题这个主机名属于哪个服务url_bases与这个路径应该路由到哪个操作url_paths。三种方式——照抄现有服务、读 botocore 服务模型的requestUri、用 MITM 代理抓真实 AWS 请求——覆盖了从「快速实现」到「精确还原」的全部需求。配合 botocore_stubber.py 的两级匹配链路与 backend_index.py 的自动生成机制开发者可以在几分钟内定位并修正任意服务的 URL 拦截问题为后续在responses.py/models.py中实现具体 API 打好基础。赞分享Mock测试【免费下载链接】motoA library that allows you to easily mock out tests based on AWS infrastructure.项目地址https://gitcode.com/gh_mirrors/mo/moto点击查看免费下载相关推荐Moto Proxy Mode 实战指南用 HTTPS 代理透明拦截并 Mock 所有 AWS SDK 请求Moto Proxy Mode 实战指南用 HTTPS 代理透明拦截并 Mock 所有 AWS SDK 请求 Moto 除了提供进程内的 mock 装饰器还Mock测试NocoBase 客户端请求开发指南APIClient、拦截器与自定义请求头全解析NocoBase 客户端请求开发指南APIClient、拦截器与自定义请求头全解析 NocoBase 提供了一套基于 Axios 封装的 APIClient低代码后端前端人工智能AI 应用工作流自动化Moto 使用 FAQ 深度解读测试数据生命周期、并发安全与自定义请求拦截实战Moto 使用 FAQ 深度解读测试数据生命周期、并发安全与自定义请求拦截实战 Moto 是一个基于 Python 的 AWS 基础设施模拟库让你可以在本地Mock测试上一篇3种导入方式详解vite-svg-loader让SVG在Vue项目中灵活应用下一篇Sentry Dart SDK 教程创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考