https://github.com/Jul1en-Lin

OSS（Object Storage Service）是一款海量、安全、低成本、高可靠的云存储服务，多种存储类型供选择，全面优化存储成本。优先使用 OSS 提供的 SDK 发起请求，因为 SDK 已集成复杂的 V4 签名算法。只有在无法使用 SDK 时，才需要参考本文自行实现 V4 签名算法。此实例代码在完成上传功能后都会尝试关闭 OSSClient，不符合此脚手架的业务逻辑，需保持开启。由于官方 SDK 已集成复杂的 V4 签名鉴权，只需传入必要的 sk 与 region 字段即可。

考虑到文件服务是单独存在的，所以应该有一个启动类，那么。我当时的 OSS 文件配置模块既没有启动类，也没有 imports 文件，光存在。这次在文件服务里照抄 bite 项目的 OSS 配置时撞到了这个问题。脚手架里的 Redis、Caffeine、统一异常处理都是后者，所以要用。是 starter 的推荐写法，不做 CGLIB 代理，启动更快。，防止 starter 里的自动配置类被消费方的包扫描误扫进去。文件服务这种独立启动的模块，其实用。，所以他能被启动类扫描到。起到了作用， 普通的。

所以引入了本地缓存 [[Caffeine 介绍|Caffeine]]，在脚手架里做成了三层缓存结构：L1 是 Caffeine（本地内存），L2 是 Redis，L3 是 DB。因为我会注册很多的 Bean，有给 Redis 的，有 RabbitMQ 的，还有 Caffeine 的，但是都是怎么将合适的 Bean 来装配到对应的 Template 的呢？业务没跑完锁先过期，另一个线程把锁拿走了，原线程 finally 里直接 DEL，删的就是别人的锁。设长了，服务宕机后锁迟迟不释放，后面的请求全堵着；

在 Postman 能看到是被正常捕获的，但是返回的 msg 丢失了，与预期返回的字符串不符合。，因为本身脚手架是 Spring 项目，且 Spring 封装的线程池类能够更方便的对线程池的一些配置进行修改，且设计初衷需要满足 nacos 动态配置的要求，所以用。做成了一个 starter，其他微服务引入依赖，异常处理器就自动生效了。通过 debug 可以看出 retMsg 在经过 ex.getMessage() 后得到的是空值，原本的默认值也被覆盖了。这个文件，里面写了要加载的配置类。

记录我在学习制作 Java 脚手架项目时遇到的问题和知识点，以便后续复盘学习～