Spring整合Kafka（十七）----处理异常_defaulterrorhandler

先自我介绍一下，小编浙江大学毕业，去过华为、字节跳动等大厂，目前阿里P7

深知大多数程序员，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年最新大数据全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上大数据知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

如果你需要这些资料，可以添加V获取：vip204888 （备注大数据）

正文

二、容器错误处理程序Container Error Handlers

从2.8版本开始，遗留的ErrorHandler和BatchErrorHandler接口已被新的CommonErrorHandler所取代。这些错误处理程序可以处理record 和batch监听器的错误，允许单个监听器容器工厂为这两种类型的监听器创建容器。现在，可以使用CommonErrorHandler的实现来取代大多数遗留框架错误处理程序。遗留接口仍然由监听器容器和监听器容器工厂支持；它们将在将来的版本中被弃用。
有关将自定义错误处理程序迁移到CommonErrorHandler的信息，请参阅将自定义遗留错误处理程序实现迁移到CommonErrorHandler。
在使用事务时，默认情况下不配置错误处理程序，因此异常将回滚事务。事务容器的错误处理由AfterRollbackProcessor处理。如果你在使用事务时提供了自定义错误处理程序，那么它必须抛出异常才能回滚事务。
CommonErrorHandler接口有一个默认的方法isAckAfterHandle()，容器调用它来确定如果错误处理程序返回而没有抛出异常，是否应该提交偏移量；默认情况下返回true。
通常，当错误未被“处理”时（例如，在执行seek操作之后），框架提供的错误处理程序将抛出异常。默认情况下，容器会以ERROR级别记录此类异常。所有的框架错误处理程序都继承了KafkaExceptionLogLevelAware，它允许你控制这些异常的日志级别。

/\*\*
 \* Set the level at which the exception thrown by this handler is logged.
 \* @param logLevel the level (default ERROR).
 \*/
public void setLogLevel(KafkaException.Level logLevel) {
    ...
}

你可以为容器工厂中的所有监听器指定一个全局错误处理程序。下面的例子展示了如何这样做:

@Bean
public KafkaListenerContainerFactory<ConcurrentMessageListenerContainer<Integer, String>>
        kafkaListenerContainerFactory() {
    ConcurrentKafkaListenerContainerFactory<Integer, String> factory =
            new ConcurrentKafkaListenerContainerFactory<>();
    ...
    factory.setCommonErrorHandler(myErrorHandler);
    ...
    return factory;
}

默认情况下，如果带注解的监听器方法抛出异常，它会被抛出到容器，消息会根据容器配置被处理。
容器在调用错误处理程序之前将提交任何pending的偏移量。
如果你使用的是Spring Boot，只需将错误处理程序添加为@Bean，Boot就会将其添加到自动配置的工厂中。

三、重试等待处理程序Back Off Handlers

错误处理程序（如DefaultErrorHandler）使用BackOff来确定重试传递之前等待的时间。你可以配置自定义的BackOffHandler。默认处理程序只是挂起线程，直到回退时间过去（或者容器停止）。框架还提供ContainerPausingBackOffHandler，它暂停监听器容器，直到回退时间过去，然后恢复容器。当延迟长于consumer属性max.poll.interval.ms时，这很有用。注意，实际回退时间将受到pollTimeout容器属性的影响。

四、默认错误处理程序DefaultErrorHandler

这个DefaultErrorHandler取代了SeekToCurrentErrorHandler和RecoveringBatchErrorHandler。注意，batch监听器的回退行为（当抛出BatchListenerFailedException以外的异常时）等效于重试完整批。
DefaultErrorHandler可以被配置为提供与seek未处理的记录偏移量相同的语义，但不需要实际seek。相反，记录由监听器容器保留，并在错误处理程序退出后（以及在执行单个暂停的poll()后）重新提交给监听器，以保持consumer alive；如果正在使用非阻塞重试(Non-Blocking Retries)或ContainerPausingBackOffHandler，则暂停可以扩展到多个polls）。错误处理程序向容器返回一个结果，该结果指示当前失败的记录是否可以重新提交，或者，它是否已恢复，然后它将不会被再次发送到监听器。要启用此模式，请将seekAfterError属性设置为false。
错误处理程序可以恢复（跳过）一直失败的记录。默认情况下，在十次失败后，会在ERROR级别记录失败的record。你可以使用自定义恢复器(BiConsumer)和BackOff来配置处理程序，BackOff控制delivery尝试和每次尝试之间的延迟。将FixedBackOff与FixedBackOff.UNLIMITED_ATTEMPTS一起使用会导致无限次重试。以下示例配置三次尝试后的恢复：

DefaultErrorHandler errorHandler =
    new DefaultErrorHandler((record, exception) -> {
        // recover after 3 failures, with no back off - e.g. send to a dead-letter topic
    }, new FixedBackOff(0L, 2L));

要使用此处理程序的自定义实例配置监听器容器，需要将其添加到容器工厂。例如，使用@KafkaListener容器工厂，你可以像下面这样添加DefaultErrorHandler:

@Bean
public ConcurrentKafkaListenerContainerFactory<String, String> kafkaListenerContainerFactory() {
    ConcurrentKafkaListenerContainerFactory<String, String> factory = new ConcurrentKafkaListenerContainerFactory();
    factory.setConsumerFactory(consumerFactory());
    factory.getContainerProperties().setAckMode(AckMode.RECORD);
    factory.setCommonErrorHandler(new DefaultErrorHandler(new FixedBackOff(1000L, 2L)));
    return factory;
}

对于record监听器，它将重试最多2次delivery（共3次delivery），以1秒的时间间隔，而不是默认配置（FixedBackOff(0L, 9)）。在重试次数用完后会记录失败。
作为一个例子；如果poll返回六条记录（在分区0、1、2中各有两条），并且监听器在第四条记录上抛出异常，则容器通过提交前三条的偏移量来acknowledge消息。DefaultErrorHandler为分区1 seek偏移量1，为分区2 seek偏移量0。下一个poll()返回三个未处理的记录。
如果AckMode是BATCH，则容器在调用错误处理程序之前提交前两个分区的偏移量。
对于batch监听器，它必须抛出BatchListenerFailedException，提示batch中的哪些记录失败。
事件顺序为：

• 在索引之前提交记录的偏移量。
• 如果重试次数未用完，执行seek，以便重新deliver所有剩余记录（包括失败的记录）。
• 如果重试次数已用完，尝试恢复失败的记录（默认仅记录日志）并执行seek，以便重新传递剩余的记录（不包括失败的记录）。恢复记录的偏移量会被提交。
• 如果重试次数已用完且恢复失败，则将执行seek，如同重试次数未用完一样。
  DefaultErrorHandler可以被配置为提供与seek未处理的记录偏移量相同的语义，但不需要实际seek。相反，错误处理程序会创建一个新的ConsumerRecords<?, ?>只包含未处理的记录，然后这些记录将被提交给监听器（在执行单个暂停的poll()之后，以保持consumer alive）。要启用此模式，请将seekAfterError属性设置为false。
  在重试次数用完后，默认的恢复器（recoverer）会记录失败的record。你可以使用自定义恢复器，也可以使用框架提供的恢复器，如DeadLetterPublishingRecoverer。
  当使用POJO batch监听器（例如List）时，并且你没有完整的consumer记录要添加到异常中，你可以只添加失败记录的索引：

@KafkaListener(id = "recovering", topics = "someTopic")
public void listen(List<Thing> things) {
    for (int i = 0; i < records.size(); i++) {
        try {
            process(things.get(i));
        }
        catch (Exception e) {
            throw new BatchListenerFailedException("Failed to process", i);
        }
    }
}

当容器配置为“AckMode.MMANUAL_IMMEDIATE”时，可以配置错误处理程序来提交已恢复记录的偏移量；将commitRecovered属性设置为true。
另请参见发布死信记录。
使用事务时，DefaultAfterRollbackProcessor也提供类似的功能。请参阅回滚后处理器。
DefaultErrorHandler认为某些异常是fatal的，并跳过对此类异常的重试；在第一次失败时调用恢复器。默认情况下，被视为fatal的异常有：

• DeserializationException
• MessageConversionException
• ConversionException
• MethodArgumentResolutionException
• NoSuchMethodException
• ClassCastException
  因为这些异常不太可能在重试delivery时得到解决。
  你可以将更多异常类型添加到不可重试类别，或者完全替换已分类异常的映射。有关更多信息，请参阅DefaultErrorHandler.addNotRetryableException()和DefaultErrorHandler.setClassifications()的Javadocs，以及spring-retry BinaryExceptionClassifier的那些文档。
  以下是一个将IllegalArgumentException添加到不可重试异常中的示例：

@Bean
public DefaultErrorHandler errorHandler(ConsumerRecordRecoverer recoverer) {
    DefaultErrorHandler handler = new DefaultErrorHandler(recoverer);
    handler.addNotRetryableExceptions(IllegalArgumentException.class);
    return handler;
}

错误处理程序可以配置一个或多个RetryListener，接收重试和恢复进度的通知。

@FunctionalInterface
public interface RetryListener {

    void failedDelivery(ConsumerRecord<?, ?> record, Exception ex, int deliveryAttempt);

    default void recovered(ConsumerRecord<?, ?> record, Exception ex) {
    }

    default void recoveryFailed(ConsumerRecord<?, ?> record, Exception original, Exception failure) {
    }

	default void failedDelivery(ConsumerRecords<?, ?> records, Exception ex, int deliveryAttempt) {
	}

	default void recovered(ConsumerRecords<?, ?> records, Exception ex) {
	}

	default void recoveryFailed(ConsumerRecords<?, ?> records, Exception original, Exception failure) {
	}

}

如果恢复器失败（引发异常），则失败的记录将包含在seek中。如果恢复器失败，默认情况下将重置BackOff，并且在再次尝试恢复之前，重新deliver将再次执行。若要在恢复失败后跳过重试，请将错误处理程序的resetStateOnRecoveryFailure设置为false。
你可以为错误处理程序提供BiFunction<ConsumerRecord<?, ?>, Exception, BackOff>，根据失败的记录或异常来确定要使用的BackOff：

handler.setBackOffFunction((record, ex) -> { ... });

如果函数返回null，则将使用处理程序的默认BackOff。
将resetStateOnExceptionChange设置为true，如果异常类型在每次失败中发生变化，则重试序列将重新启动（包括选择新的BackOff，如果已配置）。如果为false，则不考虑异常类型。
另请参阅投递尝试头Delivery Attempts Header。

五、使用batch错误处理程序的转换错误Conversion Errors with Batch Error Handlers

将MessageConverter与ByteArrayDeserializer、BytesDeserializer或StringDeserializer以及DefaultErrorHandler一起使用时，batch监听器现在可以正确处理转换错误。当发生转换错误时，payload被设置为null，并且反序列化异常被添加到record header中，类似于ErrorHandlingDeserializer。监听器中有ConversionException的列表，因此监听器可以抛出BatchListenerFailedException，指出发生转换异常的第一个索引。

@KafkaListener(id = "test", topics = "topic")
void listen(List<Thing> in, @Header(KafkaHeaders.CONVERSION\_FAILURES) List<ConversionException> exceptions) {
    for (int i = 0; i < in.size(); i++) {
        Foo foo = in.get(i);
        if (foo == null && exceptions.get(i) != null) {
            throw new BatchListenerFailedException("Conversion error", exceptions.get(i), i);
        }
        process(foo);
    }
}

六、重试完整批Retrying Complete Batches

Retrying Complete Batches是batch监听器的DefaultErrorHandler的fallback行为，其中监听器抛出了除BatchListenerFailedException以外的异常。
在重新deliver batch时，无法保证该批次具有相同数量的记录和重新deliver的记录的顺序相同。因此，不可能轻松地维护batch的重试状态。FallbackBatchErrorHandler采用以下方法。如果batch 监听器抛出的异常不是BatchListenerFailedException，则会从内存中的batch记录中执行重试。为了避免在扩展的重试序列中发生rebalance，错误处理程序暂停consumer，在每次重试时，在睡眠前对其进行poll以获取back off，然后再次调用监听器。当重试次数用完时，会为batch中的每个记录调用ConsumerRecordRecoverer。如果恢复器抛出异常，或者线程在睡眠期间中断，那么该批记录将在下一次poll时重新deliver。在退出之前，无论结果如何，都会恢复consumer。
此机制不能用于事务。
在BackOff的间隔等待时，错误处理程序将以短暂的睡眠循环，直到达到所需的延迟，同时检查容器是否已停止，从而允许睡眠在stop（）之后很快退出，而不导致延迟。

七、容器停止错误处理程序Container Stopping Error Handlers

如果监听器抛出异常，CommonContainerStoppingErrorHandler会停止容器。对于record 监听器，当AckMode为RECORD时，将提交已处理记录的偏移量。对于record 监听器，当AckMode为任何手动值时，将提交已acknowledge记录的偏移量。对于batch监听器，当AckMode为BATCH时，在容器重新启动时会replay整个batch。
容器停止后，将引发一个包装了ListenerExecutionFailedException的异常。这是为了使事务回滚（如果启用了事务）。

八、委托错误处理程序Delegating Error Handler

CommonDelegatingErrorHandler可以根据异常类型委托给不同的错误处理程序。例如，你可能希望为大多数异常调用DefaultErrorHandler，然后为其他异常调用CommonContainerStoppingErrorHandler。

九、日志错误处理程序Logging Error Handler

CommonLoggingErrorHandler只是在日志记录异常;当使用record监听器，先前轮询的剩余记录会被传递给监听器。对于batch监听器，batch中的所有records将被记录。

十、为record和batch监听器使用不同的常见错误处理程序Using Different Common Error Handlers for Record and Batch Listeners

如果希望对record和batch监听器使用不同的错误处理策略，框架提供了CommonMixedErrorHandler，允许为每种监听器类型配置特定的错误处理程序。

十一、常见错误处理程序摘要Common Error Handler Summary

• DefaultErrorHandler
• CommonContainerStoppingErrorHandler
• CommonDelegatingErrorHandler
• CommonLoggingErrorHandler
• CommonMixedErrorHandler

十二、遗留错误处理程序及其替代Legacy Error Handlers and Their Replacements

遗留错误处理程序	替代
LoggingErrorHandler	CommonLoggingErrorHandler
BatchLoggingErrorHandler	CommonLoggingErrorHandler
ConditionalDelegatingErrorHandler	DelegatingErrorHandler
ConditionalDelegatingBatchErrorHandler	DelegatingErrorHandler
ContainerStoppingErrorHandler	CommonContainerStoppingErrorHandler
ContainerStoppingBatchErrorHandler	CommonContainerStoppingErrorHandler
SeekToCurrentErrorHandler	DefaultErrorHandler
SeekToCurrentBatchErrorHandler	没有替换，使用带有无限BackOff的DefaultErrorHandler。
RecoveringBatchErrorHandler	DefaultErrorHandler
RetryingBatchErrorHandler	没有替换，使用DefaultErrorHandler并抛出BatchListenerFailedException以外的异常。

12.1 将自定义遗留错误处理程序实现迁移到CommonErrorHandler Migrating Custom Legacy Error Handler Implementations to CommonErrorHandler

请参阅CommonErrorHandler中的javadocs。
要替换ErrorHandler或ConsumerAwareErrorHandler实现，你应该实现handleOne()，并让seeksAfterHandle()返回false（默认值）。你还应该实现handleOtherException()，以处理发生在记录处理范围之外的异常（例如consumer错误）。
要替换RemainingRecordsErrorHandler实现，应实现handleRemaining()并重写seeksAfterHandle()以返回true（错误处理程序必须执行必要的seek）。你还应该实现handleOtherException()，以处理发生在记录处理范围之外的异常（例如consumer错误）。
要替换任何BatchErrorHandler实现，你应该实现handleBatch()。你还应该实现handleOtherException()，以处理发生在记录处理范围之外的异常（例如consumer错误）。

十三、rollback之后处理器After-rollback Processor

在使用事务时，如果监听器抛出异常（如果存在错误处理程序，则抛出异常），则事务将回滚。默认情况下，任何未处理的记录（包括失败的记录）都会在下一次轮询中重新提取。这是通过在DefaultAfterRollbackProcessor中执行seek操作来实现的。使用batch监听器，将重新处理整批记录（容器不知道batch中的哪条记录失败）。要修改此行为，可以使用自定义的AfterRollbackProcessor配置监听器容器。例如，对于record-based的监听器，你可能希望跟踪失败的记录，并在多次尝试后放弃，也许可以将其发布到一个死信（dead-letter）主题。
DefaultAfterRollbackProcessor现在可以恢复（跳过）不断失败的记录。默认情况下，在十次失败后，会记录失败的记录（ERROR 级别）。你可以使用自定义恢复程序（BiConsumer）和最大失败数来配置processor。将maxFailures属性设置为负数会导致无限次重试。以下示例配置三次尝试后的恢复：

AfterRollbackProcessor<String, String> processor =
    new DefaultAfterRollbackProcessor((record, exception) -> {
        // recover after 3 failures, with no back off - e.g. send to a dead-letter topic
    }, new FixedBackOff(0L, 2L));

当你不使用事务时，你可以通过配置DefaultErrorHandler来实现类似的功能。请参阅容器错误处理程序。
使用batch监听器无法进行恢复（Recovery ），因为框架不知道batch中的哪条记录一直在失败。在这种情况下，应用程序监听器必须处理不断失败的记录。
另请参见发布死信记录。
DefaultAfterRollbackProcessor可以在新事务中调用（在失败事务回滚后启动）。然后，如果你使用DeadLetterPublishingRecoverer发布失败的记录，则processor会将恢复的记录在原始主题/分区中的偏移量发送到事务。要启用此功能，请在DefaultAfterRollbackProcessor上设置commitRecovered和kafkaTemplate属性。
如果恢复器失败（引发异常），则失败的记录将包含在seek中。如果恢复器失败，默认情况下将重置BackOff，并且在再次尝试恢复之前，redeliveries将再次经历back offs。在早期版本中，BackOff并未重置，在下一次失败时会重新尝试恢复。要恢复到以前的行为，请将processor的resetStateOnRecoveryFailure属性设置为false。
你现在可以为processor提供BiFunction<ConsumerRecord<?, ?>, Exception, BackOff>，根据失败的记录或异常来确定要使用的BackOff：

handler.setBackOffFunction((record, ex) -> { ... }

如果函数返回null，则将使用processor的默认BackOff。
将resetStateOnExceptionChange设置为true，如果异常类型在各失败之间发生变化，则重试序列将重新启动（包括选择新的BackOff，如果配置了此选项）。默认情况下，不考虑异常类型。

从2.3.1版本开始，类似于DefaultErrorHandler，DefaultAfterRollbackProcessor认为某些异常是fatal的，并跳过对此类异常的重试；在第一次失败时调用恢复器。默认情况下，被视为fatal的异常有：

• DeserializationException
• MessageConversionException
• ConversionException
• MethodArgumentResolutionException
• NoSuchMethodException
• ClassCastException

因为这些异常不太可能在重试delivery时得到解决。
你可以将更多异常类型添加到不可重试类别，或者完全替换已分类异常的映射。有关更多信息，请参阅DefaultAfterRollbackProcessor.setClassifications()的Javadocs，以及spring-retry BinaryExceptionClassifier的Javadocs。
以下是一个将IllegalArgumentException添加到不可重试异常中的示例：

@Bean
public DefaultAfterRollbackProcessor errorHandler(BiConsumer<ConsumerRecord<?, ?>, Exception> recoverer) {
    DefaultAfterRollbackProcessor processor = new DefaultAfterRollbackProcessor(recoverer);
    processor.addNotRetryableException(IllegalArgumentException.class);
    return processor;
}

另请参阅投递尝试头。
对于当前kafka-clients，容器无法检测ProducerFencedException是由再平衡（rebalance）引起的，还是生产者的transactional.id因超时或过期而被吊销。因为在大多数情况下，它是由再平衡引起的，所以容器不会调用AfterRollbackProcessor（因为我们不再被分配分区，所以不适合seek分区）。如果你确保超时足够大，可以处理每个事务，并定期执行“空”事务（例如通过ListenerContainerIdleEvent），则可以避免由于超时和过期而设置围栏（fencing）。或者，你可以将stopContainerWhenFenced容器属性设置为true，容器将停止，从而避免记录丢失。你可以使用ConsumerStoppedEvent并检查Reason的属性FENCED来检测此情况。由于该事件还引用了容器，因此可以使用此事件重新启动容器。
在等待BackOff间隔时，错误处理程序将以短暂的睡眠循环，直到达到所需的延迟，同时检查容器是否已停止，从而允许睡眠在stop()之后很快退出，而不是导致延迟。
processor可以配置一个或多个RetryListener，接收重试和恢复进度的通知。

@FunctionalInterface
public interface RetryListener {

    void failedDelivery(ConsumerRecord<?, ?> record, Exception ex, int deliveryAttempt);

    default void recovered(ConsumerRecord<?, ?> record, Exception ex) {
    }

    default void recoveryFailed(ConsumerRecord<?, ?> record, Exception original, Exception failure) {
    }

}

十四、投递尝试头Delivery Attempts Header

以下内容仅适用于record监听器，不适用于batch监听器。
当使用实现DeliveryAttemptAware的ErrorHandler或AfterRollbackProcessor时，可以启用向记录添加“KafkaHeaders.DELIVERY_ATTEMPT” 的header（kafka_deliveryAttempt）。此header的值是一个从1开始的递增整数。收到原始ConsumerRecord<?, ?>时整数在byte[4]中。

int delivery = ByteBuffer.wrap(record.headers()
    .lastHeader(KafkaHeaders.DELIVERY\_ATTEMPT).value())
    .getInt()

当将@KafkaListener与DefaultKafkaHeaderMapper或SimpleKafkaHeaderMapper一起使用时，可以通过在listener方法中添加@Header（KafkaHeads.DELIVERY_ATTEMPT）int DELIVERY作为参数来获得。
若要启用此header的填充，请将容器属性deliveryAttemptHeader设置为true。默认情况下，它是禁用的，以避免查找每条记录的状态和添加header的开销。
DefaultErrorHandler和DefaultAfterRollbackProcessor支持此功能。

十五、监听信息头Listener Info Header

在某些情况下，能够知道监听器在哪个容器中运行是很有用的。
你现在可以在监听器容器上设置listenerInfo属性，或者在@KafkaListener注解上设置info属性。然后，容器会将其添加到所有传入消息的“KafkaListener.LISTENER_INFO”头中；然后，它可以用于record拦截器、过滤器等，也可以用于监听器本身。

@KafkaListener(id = "something", topic = "topic", filter = "someFilter",
        info = "this is the something listener")
public void listen2(@Payload Thing thing,
        @Header(KafkaHeaders.LISTENER\_INFO) String listenerInfo) {
...

在RecordInterceptor或RecordFilterStrategy实现中使用时，header在consumer 记录中作为字节数组，使用KafkaListenerAnnotationBeanPostProcessor的charSet属性进行转换。
当从consumer记录创建MessageHeaders时，header映射器也会转换为String，并且从不将此header映射到出站(outbound)记录上。
对于POJO batch监听器，header被复制到batch的每个成员中，并且在转换后也可以作为单个String参数使用。

@KafkaListener(id = "list2", topics = "someTopic", containerFactory = "batchFactory",
        info = "info for batch")
public void listen(List<Thing> list,
        @Header(KafkaHeaders.RECEIVED\_KEY) List<Integer> keys,


**网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。**

**需要这份系统化的资料的朋友，可以添加V获取：vip204888 （备注大数据）**
![img](https://img-blog.csdnimg.cn/img_convert/dec0d7b75299c6d92ee11d357941290b.png)

**一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！**

Topic", containerFactory = "batchFactory",
        info = "info for batch")
public void listen(List<Thing> list,
        @Header(KafkaHeaders.RECEIVED\_KEY) List<Integer> keys,


**网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。**

**需要这份系统化的资料的朋友，可以添加V获取：vip204888 （备注大数据）**
[外链图片转存中...(img-p8PauTNY-1713326661863)]

**一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！**