Spring Cloud Sleuth作为微服务架构中的核心监控组件，通过轻量级的无侵入式跟踪机制，解决了分布式系统中请求路径复杂、问题定位困难的痛点。它自动为每个服务请求创建唯一的Trace ID，并为每个服务间调用生成Span ID，形成完整的调用链路图，使开发人员能够清晰地看到请求在各个服务间的流转过程。Sleuth的核心价值在于提供了一种简单高效的方式来实现分布式系统的可观测性，帮助开发团队快速定位性能瓶颈和故障根源。

一、什么是Spring Cloud Sleuth？

Spring Cloud Sleuth是一个专为Spring Boot和Spring Cloud应用设计的分布式追踪解决方案。它通过在请求的Header中自动添加跟踪信息（如Trace ID、Span ID等），实现了跨服务调用的链路追踪。当一个请求从客户端传入微服务系统时，Sleuth会为该请求创建一个唯一的Trace ID，并为系统内每个服务的处理过程创建对应的Span ID，通过父子关系将整个调用链路串联起来 。

Sleuth的设计理念是"无侵入式跟踪"，这意味着开发者不需要在业务代码中添加任何跟踪逻辑，框架会自动处理所有跨服务调用的跟踪工作。这种设计使得Sleuth能够无缝集成到Spring Cloud生态中，与Feign、Ribbon、Hystrix等组件协同工作，提供完整的微服务监控能力 。

二、诞生背景

1. 微服务架构的挑战

随着微服务架构的普及，系统复杂度急剧上升。一个简单的用户请求可能需要经过多个微服务的协同处理，形成复杂的调用链路 。这种架构带来了以下挑战：

  • 问题定位困难：当链路上的某个服务出现故障时，难以快速定位问题所在。
  • 性能分析复杂：请求的总耗时由多个服务的处理时间和网络传输时间共同决定，难以精确分析各环节的性能表现。
  • 依赖关系不透明：服务间的依赖关系随着业务发展变得越来越复杂，缺乏可视化工具来展示这种依赖关系。
2. 分布式追踪的出现

为了解决上述问题，分布式追踪技术应运而生。Spring Cloud Sleuth正是基于这种需求，为Spring生态提供了专业的链路追踪解决方案。

在Spring Cloud生态中，Sleuth与Zipkin结合使用，形成了完整的分布式追踪系统：Sleuth负责在服务端收集跟踪数据，Zipkin负责存储和可视化这些数据。这种组合为微服务架构提供了从请求入口到出口的全链路追踪能力，使开发者能够直观地看到请求在各个服务间的流转过程。

三、架构设计

1. 核心组件

Spring Cloud Sleuth的架构主要包括以下几个核心组件：

组件功能描述
Tracer跟踪器，负责创建和管理Trace和Span
span tags标签，用于记录Span的元数据信息
span context上下文，用于在服务间传递跟踪信息
span使者负责将跟踪数据发送到Zipkin等收集器

2. 数据模型

Sleuth基于OpenTracing标准实现，其数据模型主要包括以下概念：

Trace（追踪）：表示一个完整的请求链路，由多个Span组成，通过Trace ID唯一标识 。

Span（跨度）：表示请求链路中的一个工作单元，如一次HTTP请求或RPC调用，通过Span ID唯一标识 。

Parent ID（父ID）：用于表示Span之间的父子关系，将整个调用链路串联成树状结构 。

时间戳和注解：记录Span的开始时间、结束时间以及关键事件（如客户端发送请求、服务端接收请求等） 。

标签（Tags）：记录Span的元数据信息，如服务名称、方法名、IP地址等 。

举个例子：用户下单请求的链路结构

Trace ID: a1b2c3d4（整个链路唯一）
├─ Span 1（网关接收请求）：Span ID=x5y6z7，父Span ID=null（根Span）
│  ├─ Annotation: cs（网关接收请求时间）
│  └─ Annotation: sr（网关转发前时间）
├─ Span 2（订单服务接收请求）：Span ID=p8q9r0，父Span ID=x5y6z7
│  ├─ Annotation: cs（订单服务接收时间）
│  └─ Annotation: sr（订单服务处理前时间）
└─ Span 3（库存服务接收请求）：Span ID=m2n3o4，父Span ID=p8q9r0├─ Annotation: cs（库存服务接收时间）└─ Annotation: sr（库存服务处理前时间）
3. 工作原理

Sleuth的工作原理可以分为以下几个关键步骤：

请求入口跟踪：当请求进入微服务系统时，Sleuth会自动创建一个Trace，并为入口服务生成第一个Span 。

跨服务调用跟踪：在服务间调用时（如通过Feign或Ribbon），Sleuth会自动将当前Span的上下文信息（如Trace ID、Span ID等）通过HTTP Header传递给被调用服务，使被调用服务能够创建关联的Span 。

Span生命周期管理：每个Span都有明确的开始和结束，Sleuth会自动记录这些时间点，并计算处理时间 。

数据收集与发送：Sleuth会将生成的Span数据收集起来，并通过配置的发送器（如HTTP或Kafka）发送到Zipkin等收集器 。

上下文传播机制：Sleuth通过字节码增强技术，在HTTP请求、消息队列等通信通道中自动传播跟踪上下文，无需开发者手动处理 。

+---------------------+       +---------------------+       +---------------------+
|   微服务A           |       |   微服务B           |       |   微服务C           |
| (订单服务)          |       | (支付服务)          |       | (库存服务)          |
+----------+----------+       +----------+----------+       +----------+----------+|                            |                            || 1. 生成Trace/Span          |                            |                            ||---------------------------->                            |                            || 2. 传递TraceContext (HTTP头) |                            |                            ||<-----------------------------|                            |                            ||                            | 3. 生成子Span              |                            ||                            |---------------------------->                            ||                            |                            | 4. 传递TraceContext        ||                            |                            |---------------------------->                            ||                            |                            |                            | 5. 生成最终Span|                            |                            |                            |<-----------------------------|                            |                            |                            ||                            |                            | 6. 上报Zipkin            ||                            |                            |---------------------------->                            ||                            |                            |                            | 7. 存储到Elasticsearch|                            |                            |                            |<-----------------------------|                            |                            |                            ||                            |                            |                            | 8. 可视化展示|                            |                            |                            |------------------------------>
+----------+----------+       +----------+----------+       +----------+----------+|                            |                            |                            || 9. 日志关联Trace ID        |                            |                            ||---------------------------->                            |                            ||                            | 10. 日志聚合分析           |                            ||                            |---------------------------->                            ||                            |                            | 11. 监控告警              |
+----------+----------+       +----------+----------+       +----------+----------+

四、解决的问题

1. 链路复杂性问题

在微服务架构中，一个请求可能经过多个服务的处理，形成复杂的调用链路。Sleuth通过Trace和Span的树状结构，将这些复杂的调用关系清晰地呈现出来，使开发者能够直观地理解请求的处理流程。

2. 问题定位困难

当系统出现故障时，传统日志方法难以快速定位问题所在服务。Sleuth通过将请求与Trace ID关联，使开发者能够根据Trace ID快速定位到完整的调用链路，进而找到故障发生的具体服务和位置。

3. 性能分析困难

请求的总耗时由多个服务的处理时间和网络传输时间共同决定。Sleuth通过记录各个Span的时间戳，能够精确分析每个服务的处理时间和网络延迟，帮助开发者找出性能瓶颈 。

4. 服务依赖关系不透明

微服务架构下，服务间的依赖关系随着业务发展变得越来越复杂。Sleuth通过可视化调用链路，使开发者能够清晰地看到服务间的依赖关系，进而优化系统架构 。

五、关键特性

1. 无侵入式跟踪

Sleuth的核心优势是无侵入式跟踪，开发者无需在业务代码中添加任何跟踪逻辑，框架会自动处理所有跨服务调用的跟踪工作 。这种设计使得Sleuth能够无缝集成到Spring Cloud生态中，与Feign、Ribbon、Hystrix等组件协同工作。

2. 自动上下文传播

Sleuth通过字节码增强技术，在HTTP请求、消息队列等通信通道中自动传播跟踪上下文，无需开发者手动处理 。这种机制确保了跨服务调用的链路完整性，使开发者能够看到完整的请求处理流程。

3. 多种采样策略

Sleuth支持多种采样策略，包括百分比采样（PercentageBasedSampler）和边界采样（BoundarySampler）等 。通过调整采样率，开发者可以在数据采集的完整性和系统性能之间找到平衡点，避免在高并发场景下因全量采集导致的性能问题。

4. 灵活的数据发送机制

Sleuth支持多种数据发送机制，包括HTTP直接发送（默认）和通过消息队列（如Kafka或RabbitMQ）发送等。这种灵活性使得Sleuth能够适应不同的系统环境和性能需求。

5. 与多种存储后端集成

Sleuth生成的跟踪数据可以发送到多种存储后端，包括Zipkin、Elasticsearch、MySQL等。这种集成能力使得开发者可以根据实际需求选择最适合的存储方案，平衡数据存储的性能和成本。

6. 与OpenTelemetry兼容

随着OpenTelemetry成为行业标准，Spring Cloud Sleuth也提供了与OpenTelemetry的兼容方案。通过排除默认的Brave实现，引入OpenTelemetry的SDK和出口器，Sleuth可以与更广泛的可观测性生态系统集成。

六、同类产品对比

1. 与CAT对比
特性Spring Cloud SleuthCAT
埋点方式自动（无侵入式）需要手动代码埋点
配置复杂度简单，通过YAML/Properties配置需要额外配置文件和目录
存储选型灵活，支持多种现代存储选型较老旧，扩展性差
功能专注性专注于链路追踪功能综合性强，但链路追踪功能较弱
适用场景Spring Cloud生态，轻量级跟踪大型系统，需要综合监控

CAT是一个更综合性的监控平台，提供了日志、性能、业务等多方面的监控功能，但其链路追踪功能相对弱，且需要侵入式代码埋点，增加了业务开发的复杂度。Spring Cloud Sleuth专注于链路追踪，与CAT相比，它在Spring生态中的集成更加紧密，配置更加简单，适合需要快速实现链路追踪的微服务系统。

2. 与SkyWalking对比
特性Spring Cloud SleuthSkyWalking
埋点方式自动（无侵入式）需要Agent注入
配置复杂度简单，通过YAML/Properties配置复杂，需要Agent部署
存储选型支持多种存储，但功能相对简单功能全面，支持多种存储
可视化能力依赖Zipkin等外部工具自带强大的可视化界面
适用场景Spring Cloud生态，轻量级跟踪复杂系统，需要全面监控

SkyWalking是一个功能全面的APM（应用性能管理）系统，提供了从链路追踪到性能监控的全方位解决方案。与Sleuth相比，SkyWalking的配置和部署更加复杂，需要Agent注入，而Sleuth则通过Spring Boot的自动配置机制简化了部署流程。在Spring Cloud生态中，Sleuth提供了更轻量级的链路追踪解决方案，而SkyWalking则提供了更全面的性能监控能力。

3. 与Jaeger对比
特性Spring Cloud SleuthJaeger
埋点方式自动（无侵入式）需要手动配置或自动检测
配置复杂度简单，通过YAML/Properties配置复杂，需要独立部署
存储选型支持多种存储，但功能相对简单支持Elasticsearch、Cassandra等
可视化能力依赖Zipkin等外部工具自带强大的可视化界面
云原生支持支持，但需要额外配置原生支持Kubernetes等云环境
适用场景Spring Cloud生态，轻量级跟踪复杂云环境，需要全面监控

Jaeger是一个专注于分布式追踪的开源工具，由Uber开源，支持多种存储后端和云环境。与Sleuth相比，Jaeger的配置和部署更加复杂，需要独立部署，而Sleuth则通过与Spring Boot的紧密集成简化了部署流程。在云原生环境中，Jaeger提供了更好的支持，而Sleuth则在Spring Cloud生态中表现更佳。

七、使用方法

1. 基础配置

步骤1：启动Zipkin服务端

使用Docker快速启动Zipkin服务端：

docker run -d -p 9411:9411 openzipkin/zipkin

访问Zipkin UI：http://localhost:9411/zipkin/

步骤2：在微服务中添加依赖

在pom.xml中添加Sleuth和Zipkin依赖：

<dependency><groupId>org.springframework.cloud</groupId><artifactId>spring-cloud-starter-sleuth</artifactId>
</dependency>
<dependency><groupId>org.springframework.cloud</groupId><artifactId>spring-cloud-starter-zipkin</artifactId>
</dependency>

步骤3：配置应用属性

在application.yml中配置Zipkin地址和采样率：

spring:application:name: your-service-namesleuth:sampler:probability: 1.0  # 采样率，1.0表示全量采集zipkin:sender:type: web  # 数据发送方式，web表示HTTP直接发送base-url: http://localhost:9411  # Zipkin服务地址
2. 高级配置

使用MySQL存储跟踪数据

步骤1：初始化Zipkin数据库

CREATE TABLE zipkin_spans (trace_id_high BIGINT NOT NULL DEFAULT 0,trace_id BIGINT NOT NULL,id BIGINT NOT NULL,name VARCHAR(255) NOT NULL,remote_service_name VARCHAR(255),parent_id BIGINT,debug BIT(1),start_ts BIGINT,duration BIGINT,PRIMARY KEY (trace_id_high, trace_id, id),INDEX (trace_id_high, trace_id),INDEX (name),INDEX (remote_service_name),INDEX (start_ts)
) ENGINE=InnoDB ROW_FORMAT=COMPRESSED CHARACTER SET=utf8 COLLATE=utf8_general_ci;-- 创建其他必要的表（略）

步骤2：配置Zipkin服务端使用MySQL

java -jar zipkin-server-2.20.1-exec.jar \--STORAGE_TYPE=mysql \--MYSQL_HOST=localhost \--MYSQL_PORT=3306 \--MYSQL_USER=root \--MYSQL_PASSWORD=root \--MYSQL_DB=zipkin

步骤3：在微服务中添加MySQL驱动依赖

<dependency><groupId>mysql</groupId><artifactId>mysql-connector-java</artifactId>
</dependency>

使用Kafka作为消息中间件

步骤1：添加Kafka依赖

<dependency><groupId>org.springframework.cloud</groupId><artifactId>spring-cloud-stream-binder-kafka</artifactId>
</dependency>

步骤2：配置Kafka和Zipkin

spring:zipkin:sender:type: kafka  # 使用Kafka发送数据cloud:stream:binders:zipkin:type: kafka# 当项目同时使用kafka和rabbit时，需要指定zipkin:目的地: zipkin  # Kafka主题名称
kafka:bootstrap-servers: 192.168.1.36:9092,192.168.1.33:9092,192.168.1.47:9092

使用OpenTelemetry

步骤1：排除默认的Brave实现，添加OpenTelemetry依赖

<dependency><groupId>org.springframework.cloud</groupId><artifactId>spring-cloud-starter-sleuth</artifactId><exclusions><exclusion><groupId>org.springframework.cloud</groupId><artifactId>spring-cloud-sleuth-brave</artifactId></exclusion></exclusions>
</dependency>
<dependency><groupId>org.springframework.cloud</groupId><artifactId>spring-cloud-sleuth-otel-autoconfigure</artifactId>
</dependency>
<dependency><groupId>io.opentelemetry</groupId><artifactId>opentelemetry-exporter-otlp-trace</artifactId>
</dependency>

步骤2：配置OpenTelemetry

spring:sleuth:otel:config:trace-id-ratio-based: 1.0  # 采样率exporter:otlp:endpoint: http://otel-collector:4317  # OpenTelemetry收集器地址protocol: http/1.1
3. 使用示例

通过Feign调用生成Span

@Service
public class PaymentService {@Autowiredprivate RestTemplate restTemplate;@GetMapping("/payment/zipkin")public String paymentZipkin() {// 通过RestTemplate调用其他服务，自动生成Spanreturn restTemplate.getForObject("http://CLOUD-PAYMENT-SERVICE/payment/zipkin", String.class);}
}

自定义Span标签

@RestController
public class OrderController {@Autowiredprivate Tracer tracer;@GetMapping("/order")public String createOrder() {Span span = tracer.currentSpan();spantag("order-type", "standard");  // 添加自定义标签spantag("priority", "high");          // 添加自定义标签return "Order created successfully";}
}

在日志中关联Trace ID

@RestController
public class UserController {@Autowiredprivate Tracer tracer;@GetMapping("/user")public String getUser() {Span span = tracer.currentSpan();MDC.put("X-B3-TraceId", spancontext().traceIdString());  // 将Trace ID注入日志框架MDC.put("X-B3-SpanId", spancontext().spanIdString());    // 将Span ID注入日志框架// 业务逻辑MDC.remove("X-B3-TraceId");  // 清除Trace IDMDC.remove("X-B3-SpanId");    // 清除Span IDreturn "User information";}
}
4. 最佳实践

采样率优化：在生产环境中，应根据系统负载和性能需求合理设置采样率。对于QPS较高的系统，建议将采样率设置为5%-10%，关键业务场景可动态提升采样率。

跨语言支持：对于多语言微服务系统，需确保各服务正确透传跟踪Header。例如，对于Python服务，可通过中间件自动注入和转发X-B3-* Header。

性能监控：Sleuth本身对系统性能有一定影响，特别是在高并发场景下。可通过以下方式优化性能：

  • 使用异步发送机制
  • 设置合理的采样率
  • 避免在循环或高频调用中生成Span

数据存储扩展：对于大规模微服务系统，建议使用Elasticsearch或Cassandra等分布式存储后端，并设置合理的索引生命周期管理策略（如设置索引TTL为7天）。

与监控系统集成：将Sleuth的跟踪数据与Prometheus、Grafana等监控系统集成，实现更全面的系统可观测性。

八、Azure云环境下的配置

对于部署在Azure云环境中的微服务，Sleuth提供了专门的配置方案：

步骤1：添加Azure依赖

<dependency><groupId>com.azure.spring</groupId><artifactId>spring-cloud-azure-starter-appconfiguration-config</artifactId>
</dependency>

步骤2：配置Azure应用配置

spring:cloud:azure:appconfiguration:stores[0]:connection-string: ${CONFIGSTORE_CONNECTIONSTRING}credential:managed-identity-enabled: true  # 使用托管标识client:http:logging:level: HEADERS  # 记录HTTP请求和响应的头部信息pretty-print-body: false

步骤3：配置Sleuth与Azure集成

spring:sleuth:otel:config:trace-id-ratio-based: 0.1  # 默认采样率exporter:otlp:endpoint: https://你的收集器地址headers:Azure-Function-Id: your-function-id

九、未来发展趋势

随着云原生和可观测性技术的发展，Spring Cloud Sleuth也在不断演进：

OpenTelemetry集成：Spring Cloud Sleuth正在逐步与OpenTelemetry集成，提供更标准、更全面的跟踪能力。

云原生支持：Spring Cloud Sleuth正在加强对Kubernetes、Service Mesh等云原生环境的支持，提供更灵活的部署方案 。

AI驱动的分析：未来Sleuth可能会结合AI技术，对跟踪数据进行更智能的分析，帮助开发者更快地发现潜在问题。

与监控系统的深度集成：Sleuth可能会与Prometheus、Grafana等监控系统进行更深度的集成，提供更全面的系统可观测性。

十、文末

Spring Cloud Sleuth作为微服务架构中的链路追踪工具，通过轻量级的无侵入式跟踪机制，解决了分布式系统中请求路径复杂、问题定位困难的痛点。它通过自动创建和管理Trace和Span，形成完整的调用链路图，帮助开发人员快速定位性能瓶颈和故障根源。

与同类产品相比，Sleuth在Spring Cloud生态中的集成更加紧密，配置更加简单，适合需要快速实现链路追踪的微服务系统。对于复杂系统，可以考虑与SkyWalking、Jaeger等更全面的监控系统结合使用，实现更全面的系统可观测性。

在实际应用中，应根据系统规模和性能需求合理配置Sleuth，包括采样率、数据存储后端和发送机制等。对于大规模系统，建议使用Elasticsearch或Cassandra等分布式存储后端，并结合OpenTelemetry实现更标准的跟踪能力。

Spring Cloud Sleuth的核心价值在于提供了一种简单高效的方式来实现分布式系统的可观测性，帮助开发团队快速定位问题，优化系统性能，提升系统稳定性。随着云原生和可观测性技术的发展，Sleuth将继续演进，为微服务架构提供更强大的链路追踪能力。

 参考资料：
  • Spring Cloud Sleuth 文档

 本博客专注于分享开源技术、微服务架构、职场晋升以及个人生活随笔，这里有：

📌 技术决策深度文（从选型到落地的全链路分析）

💭 开发者成长思考（职业规划/团队管理/认知升级）

🎯 行业趋势观察（AI对开发的影响/云原生下一站）

关注我，每周日与你聊“技术内外的那些事”，让你的代码之外，更有“技术眼光”。

日更专刊：

🥇 《Thinking in Java》 🌀 java、spring、微服务的序列晋升之路！
🏆 《Technology and Architecture》 🌀 大数据相关技术原理与架构，帮你构建完整知识体系！

关于博主：

🌟博主GitHub

🌞博主知识星球

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如若转载，请注明出处：http://www.pswp.cn/pingmian/95302.shtml
繁体地址，请注明出处：http://hk.pswp.cn/pingmian/95302.shtml
英文地址，请注明出处：http://en.pswp.cn/pingmian/95302.shtml

如若内容造成侵权/违法违规/事实不符，请联系英文站点网进行投诉反馈email:809451989@qq.com，一经查实，立即删除！

相关文章

Linux(2)|入门的开始：Linux基本指令(2)

Linux(2)|入门的开始：Linux基本指令(2)

一、基本指令介绍 回顾上篇博客Linux(1)|入门的开始&#xff1a;Linux基本指令-CSDN博客&#xff0c;我们已经学习了mkdir目录的创建&#xff0c;touch普通文件的创建&#xff0c;光有创建肯定是不行的&#xff0c;接下来就介绍我们的删除指令 1、rmdir指令&&rm指令 …
阅读更多...
sv中forever如何结束

sv中forever如何结束

在 SystemVerilog 中&#xff0c;forever 循环本身无法自我结束。它的设计初衷就是创建一个永不终止的循环。 因此&#xff0c;要结束一个 forever 循环&#xff0c;必须从外部强制中断它。主要有以下两种方法&#xff1a;1. 使用 disable 语句&#xff08;最常用和推荐的方法&…
阅读更多...
关于熵减 - 从法拉第圆盘到SEG

关于熵减 - 从法拉第圆盘到SEG

我们清楚的知道法拉第圆盘发电机的原理。当导线切割磁感线的时候&#xff0c;会产生电流&#xff0c;当然电流产生需要的是电动势&#xff0c;也就是&#xff0c;这里写 不写 &#xff0c;避免和电场强度混淆。根据上面的分析&#xff0c;我们知道磁场强度特斯拉 的单位&#x…
阅读更多...
【机器学习】实战：市场增长点分析挖掘项目

【机器学习】实战：市场增长点分析挖掘项目

在电商行业激烈竞争的背景下&#xff0c;精准挖掘市场增长点是企业保持竞争力的关键。本文基于拜耳官方旗舰店驱虫剂市场分析项目&#xff0c;先对原文核心内容进行梳理与解读&#xff0c;再续写关键的竞争分析模块&#xff0c;形成完整的市场增长点挖掘闭环&#xff0c;为企业…
阅读更多...
【Day 18】21.合并两个有序链表 2.两数相加

【Day 18】21.合并两个有序链表 2.两数相加

文章目录21.合并两个有序链表题目&#xff1a;思路&#xff1a;迭代代码实现&#xff08;Go&#xff09;&#xff1a;2.两数相加题目&#xff1a;思路&#xff1a;代码实现&#xff08;Go&#xff09;&#xff1a;21.合并两个有序链表 题目&#xff1a; 将两个升序链表合并为…
阅读更多...
Vue 3 WebSocket通信方案：从原理到实践

Vue 3 WebSocket通信方案：从原理到实践

Vue 3 WebSocket通信方案&#xff1a;从原理到实践 在现代Web应用开发中&#xff0c;实时通信已成为许多应用的核心需求。从即时聊天到实时数据更新&#xff0c;用户对应用响应速度的期望越来越高。本文将深入剖析一个Vue 3环境下的WebSocket通信方案&#xff0c;包括基础封装与…
阅读更多...
Windows 电源管理和 Shutdown 命令详解

Windows 电源管理和 Shutdown 命令详解

一、Windows 电源管理概述 Windows 操作系统通过其内置的电源管理框架&#xff0c;为用户提供了多种电源状态和配置选项&#xff0c;以在性能、能耗和数据安全之间找到最佳平衡点。以下是 Windows 系统中常见的电源状态及其特点&#xff1a; 1. 睡眠&#xff08;Sleep&#xff…
阅读更多...
Selenium WebUI 自动化“避坑”指南——从常用 API 到 10 大高频问题

Selenium WebUI 自动化“避坑”指南——从常用 API 到 10 大高频问题

目录 一、为什么 90% 的 UI 自动化脚本活不过 3 个月&#xff1f; 二、Selenium必会 API 速查 三、实践 四、10 大高频异常“症状 → 病因 → 处方” 五、可复用的工具函数 六、面试高频追问&#xff08;附标准答案&#xff09; 一、为什么 90% 的 UI 自动化脚本活不过 …
阅读更多...
【微信小程序】微信小程序基于双token的API请求封装与无感刷新实现方案

【微信小程序】微信小程序基于双token的API请求封装与无感刷新实现方案

文章目录前言一、设计思路二、执行流程三、核心模块3.1 全局配置3.2 request封装3.2.1 request方法配置参数3.2.2 请求预处理3.2.3 核心请求流程3.3 刷新accessToken3.4 辅助方法四、api封装示例总结前言 现代前后端分离的模式中&#xff0c;一般都是采用token的方式实现API的…
阅读更多...
基于单片机醉酒驾驶检测系统/酒精检测/防疲劳驾驶设计

基于单片机醉酒驾驶检测系统/酒精检测/防疲劳驾驶设计

传送门 &#x1f449;&#x1f449;&#x1f449;&#x1f449;其他作品题目速选一览表 &#x1f449;&#x1f449;&#x1f449;&#x1f449;其他作品题目功能速览 概述 该设计基于单片机开发&#xff0c;旨在通过实时检测驾驶员酒精浓度&#xff0c;预防酒后驾驶行为…
阅读更多...
第6章：垃圾回收分析与调优

第6章：垃圾回收分析与调优

1. 垃圾回收基础 1.1 Java 垃圾回收概述 垃圾回收&#xff08;Garbage Collection&#xff0c;GC&#xff09;是 Java 虚拟机自动内存管理的核心机制。理解 GC 的工作原理对于 Java 应用性能调优至关重要。 1.1.1 垃圾回收的目标 自动内存管理&#xff1a;无需手动释放内存防止…
阅读更多...
ROS2核心模块-动作通信、参数服务

ROS2核心模块-动作通信、参数服务

动作通信 机器人导航到某个目标点,此过程需要一个节点A发布目标信息&#xff0c;然后一个节点B接收到请求并控制移动&#xff0c;最终响应目标达成状态信息。 乍一看&#xff0c;这好像是服务通信实现&#xff0c;因为需求中要A发送目标&#xff0c;B执行并返回结果&#xff0c…
阅读更多...
word文档封面中文件编号等标题和内容无法对齐

word文档封面中文件编号等标题和内容无法对齐

问题 word文档封面中文件编号等标题和内容无法对齐&#xff0c;因为标题使用的是底纹不是文件内容。 解决办法 字体大小、行距两者配合就可以解决。
阅读更多...
163起融资，梅卡曼德融资额夺冠，钉钉、百度智能云10周年，汉桑科技IPO| 2025年8月人工智能投融资观察 · 极新月报

163起融资，梅卡曼德融资额夺冠，钉钉、百度智能云10周年，汉桑科技IPO| 2025年8月人工智能投融资观察 · 极新月报

“ 二级的活跃会传导到一级吗&#xff1f;”文&#xff5c;云舒&小鱼编辑 | 小白出品&#xff5c;极新8月重点关注&#xff1a;1、八月人工智能领域投融资事件163起&#xff0c;披露金额76.8亿人民币。2、亿级人民币以上金额的投资事件共20起 。3、八月人工智能领域发生一起…
阅读更多...
微信小程序预览和分享文件

微信小程序预览和分享文件

预览文档previewFile(val) { let item val.currentTarget.dataset.item wx.downloadFile({url: item.filePath, // 替换为实际的文件地址success: function (res) {let filePath ${wx.env.USER_DATA_PATH}/${item.fileName}|| res.tempFilePath //查看的文件名wx.openDocumen…
阅读更多...
开源 C++ QT Widget 开发（十二）图表--环境监测表盘

开源 C++ QT Widget 开发（十二）图表--环境监测表盘

文章的目的为了记录使用C 进行QT Widget 开发学习的经历。临时学习&#xff0c;完成app的开发。开发流程和要点有些记忆模糊&#xff0c;赶紧记录&#xff0c;防止忘记。 相关链接&#xff1a; 开源 C QT Widget 开发&#xff08;一&#xff09;工程文件结构-CSDN博客 开源…
阅读更多...
ARMv8架构01 - ARM64架构寄存器基础

ARMv8架构01 - ARM64架构寄存器基础

一 、ARM64架构基础 1 ARMv8 A 架构介绍 ARMv8 - A是ARM公司发布的第一代支持64位处理器的指令集和架构。它在扩充64位寄存器的同时提供对上一代架构指令集的兼容&#xff0c;因而能同时提供运行 32位 和 64位应用程序的执行环境。 超大物理地址空间&#xff08;large Physical…
阅读更多...
flutter专栏--深入剖析你的第一个flutter应用

flutter专栏--深入剖析你的第一个flutter应用

使用fvm管理flutter版本 如果你有使用多版本flutter的需求&#xff0c;那么fvm将会给你提供较大的帮助。下面我列举一下mac flutter3.35.2的版本的操作命令&#xff0c;完成之后&#xff0c;你将可以随意切换flutter版本 # 下载fvm相关的依赖 brew tap leoafarias/fvm brew …
阅读更多...
MongoDB 聚合查询超时：索引优化与分片策略的踩坑记录

MongoDB 聚合查询超时：索引优化与分片策略的踩坑记录

人们眼中的天才之所以卓越非凡&#xff0c;并非天资超人一等而是付出了持续不断的努力。1万小时的锤炼是任何人从平凡变成超凡的必要条件。———— 马尔科姆格拉德威尔 &#x1f31f; Hello&#xff0c;我是Xxtaoaooo&#xff01; &#x1f308; “代码是逻辑的诗篇&#xff…
阅读更多...
Augmentcode免费额度AI开发WordPress商城实战

Augmentcode免费额度AI开发WordPress商城实战

Augment AI开发WordPress商城实战&#xff1a;从零构建到免费额度续杯完整指南 前言 在AI编程工具日益普及的今天&#xff0c;如何高效利用这些工具来开发实际项目成为了开发者关注的焦点。本文将详细介绍如何使用Augment AI从零开始构建一个功能完整的WordPress商城系统&#…
阅读更多...
最新文章

Copyright @ 2022~2023