小丁的博客

Spring Boot启动失败：Address already in use问题排查指南 当Spring Boot应用启动失败并提示Address already in use，通常是由于端口被占用。本文通过分析典型错误日志，揭示了问题的根源——旧应用进程未完全退出。解决方案包括： 对于macOS/Linux： 使用lsof -i :端口号查找占用进程的PID 执行kill -9 PID强制终止进程 对于Windows： 运行netstat -ano | findstr :端口号定位PID 执行taskki

本文介绍了在Spring Boot中基于Guava实现自定义内存缓存的设计方案。通过分析默认缓存的三大局限性（无过期时间、无限容量、缺乏灵活性），作者提出了一个由MyConcurrentMapCacheManager（缓存引擎）、MyCache（配置器）和CacheChecker（诊断工具）组成的解决方案。核心亮点包括：1）集成Guava的CacheBuilder实现过期和容量控制；2）通过命名约定（如findAdminById#3600）实现动态TTL配置。该方案相比默认缓存更强大，相比Redis更轻量，

摘要：Swagger 配置的最佳实践 本文通过一个真实的调试案例，揭示了 Spring Boot 项目中 Swagger 配置的常见陷阱。当项目结构复杂时，精确指定多个 Controller 包路径会导致版本兼容性和语法复杂性问题。最终解决方案是采用"扫描根包"策略：直接配置 basePackage("com.your.root")。这种方法具有简单性、面向未来和版本无关性等优势，能自动发现所有子包中的 Controller，实现"一次配置，终身有效&quo

本文探讨了业务流程与数据关系模型之间的联系与区别，通过“福利方案”项目案例，分析可选关联场景下的多对多关系设计。核心观点包括： 业务流程（动态时序）与数据关系（静态本质）需区分看待 判断多对多关系的标准是两个"可以对应多个"的条件 通过中间表实体实现灵活的多对多关系，用零关联表达可选性 JPA最佳实践是创建明确的中间表实体类 关键结论：多对多关系设计应基于数据本质，而非业务流程表现。中间表实体方案既能满足强制关联场景，也能优雅处理可选关联情况。开发者在设计时应先分析实体间的潜在关联规则，

本文以Spring Boot开发createSolution接口为例，详细阐述了构建生产级API的关键技术要点。通过分层设计实现数据校验、安全隔离和模型转换：将基础校验交给Controller层，业务校验由Service层处理；使用JPA方法命名查询确保数据归属安全；通过VO模型转换实现前后端解耦。文章展示了如何通过职责分离构建安全健壮的接口，包括实体引用优化、原子化查询校验等技术细节，最终形成清晰分层的架构设计，为开发高质量后端API提供了实践指导。

嘿，各位开发者！👋 在信息安全的宏伟殿堂里，Authentication 和 Authorization 是两根最重要的顶梁柱。然而，对于许多人来说，这两个拼写相近、发音相似的单词，就像一对难以分辨的双胞胎，常常让我们在技术交流和文档写作中陷入尴尬。

本文深入探讨了JWT（JSON Web Token）在现代Web应用中的双重角色：认证（Authentication）和授权（Authorization）。JWT验证过程本身属于认证范畴，包括验证签名、有效期和用户身份，确保Token的真实性和有效性。同时，JWT载荷中携带的权限信息（如roles和permissions）为授权决策提供了依据。文章通过流程图和表格清晰展示了JWT如何同时服务于认证和授权两个安全环节，帮助开发者理解其核心机制。这种"认证载体+授权信息"的双重身份使JWT成

摘要 本文详细介绍了如何利用Spring Boot和Spring Data JPA构建一个安全高效的详情查询接口。文章通过一个需要聚合5张表数据的getProductDetail接口开发案例，展示了三层架构的最佳实践：Controller层负责身份验证和结果返回；Service层封装业务逻辑并处理异常；Repository层通过命名查询实现数据隔离和高效检索。重点探讨了DTO投影、自定义异常处理等关键技术，解决了数据聚合、性能优化、安全隔离等核心问题，最终实现了一个符合RESTful规范、高性能且安全的详情

今天，我将带你完整回顾一次 Spring Boot addCollection (添加收藏) 接口的开发全过程。从 API (应用程序编程接口) 设计到代码实现，我们将深入探讨认证、数据校验、分层架构和幂等性处理等核心概念，为你展示一个“教科书式”的接口是如何诞生的。

摘要：前后端分离开发中，JSON字段命名不一致是常见问题。本文介绍了使用Jackson的@JsonProperty和Fastjson的@JSONField注解解决这一问题的方案。通过为Java字段指定JSON别名，实现前后端命名解耦，同时提升代码可读性和可维护性。文章还通过对比表和流程图，详细解析了两种注解的使用方法及JSON反序列化过程，为开发者提供了优雅的字段映射解决方案。

摘要： Java中boolean字段序列化时出现“幽灵字段”问题的根源在于JavaBean规范、Lombok和Jackson的规则冲突。当字段以is开头（如isPhoneBound）时，Lombok生成的getter方法（isPhoneBound()）会被Jackson解析为phoneBound属性，而@JsonProperty注解又强制输出isPhoneBound字段，导致JSON中出现重复数据。解决方案包括：1）直接修改字段名（推荐）；2）统一使用@JsonProperty；3）通过@JsonIgnor

摘要：本文深入剖析了Java中boolean类型字段在JSON序列化过程中的命名"变形"现象。通过一个典型场景（isPhoneBound字段在前端接收时变为phoneBound），揭示了背后的三大机制：JavaBean规范对boolean类型getter方法的特殊命名规则（isXxx()）、Lombok自动生成getter的实现方式，以及Jackson等序列化框架通过反射获取getter方法名的处理逻辑。文章提供了两种解决方案（修改字段名或使用@JsonProperty注解），并推荐遵循

本文将分享一个前后端协作中的经典案例：因Token传递规范不一致导致的认证失败问题。当用户登录后调用接口时，前端将Token放在自定义的token请求头中，而后端拦截器却在标准Authorization头中寻找以Bearer为前缀的Token，导致401错误。通过将前端代码修改为遵循OAuth 2.0 Bearer Token规范（header.Authorization = 'Bearer ' + token），问题得以解决。这个案例凸显了前后端统一标准和清晰沟通的重要性，提醒开发团队要遵循行业规范并保持

本文提出了一种"双通道认证模式"的Spring Boot实现方案，旨在解决老系统从有状态Session认证向无状态JWT认证平滑过渡的问题。该方案通过创建两条并行的认证通道：保留原有基于Session的认证通道处理旧接口，同时新增纯无状态的JWT认证通道处理新接口。核心实现包括：1）新建StatelessJwtInterceptor拦截器，仅通过request.setAttribute传递用户信息；2）配置JwtInterceptorConfig作为"交通枢纽"，将不

文章摘要： 本文剖析了JWT与Session混合认证模式的潜在问题。通过真实代码案例，揭示了这种"既要无状态又要会话"的设计矛盾：调用request.getSession()会隐式创建服务器端Session，导致系统同时维护两套认证机制。这种混合模式会引发逻辑混乱（双重认证标准）、丧失无状态扩展优势（内存压力、分布式问题），并带来安全隐患（生命周期不一致、CSRF风险）。作者建议明确选择单一认证模式，避免混合方案带来的技术债务。

摘要： 现代Web应用的认证机制主要分为**有状态登录（Session-Cookie）和无状态登录（JWT Token）**两种模式。有状态登录依赖服务器存储Session信息，扩展性较差但便于管理用户状态；无状态登录通过客户端携带的Token验证身份，天然支持分布式系统但无法主动失效Token。两种方式各具优势：Session适合传统单体应用，JWT更适配前后端分离和微服务架构。技术选型需结合业务场景，权衡扩展性、性能和安全需求。

JWT工具类设计对比分析 本文对比了JWT工具类的两种设计模式：传统静态工具类与现代Spring Bean方式。静态工具类通过static方法直接调用，简单但存在硬编码配置、难以测试等缺点；Spring Bean方式则利用依赖注入和配置管理，将密钥、有效期等参数外置到application.yml，提高了灵活性和可测试性。通过流程对比图和时序图，直观展示了两种设计的工作原理，建议在现代Spring项目中使用第二种方式，以获得更好的可维护性和扩展性。

文章摘要： 本文通过一个典型的Spring Boot登录Bug——"token为空"异常，剖析了拦截器与登录接口的冲突问题。当JWT拦截器强制校验所有请求（包括获取Token的登录接口）时，形成了"先有Token还是先有登录"的死循环。通过分析错误堆栈和请求流程，作者定位到拦截器配置问题，最终将登录接口/wx/auth/login加入白名单解决问题。文章还解释了为何无需修改Spring Security配置（因其已配置为permitAll），完整呈现了从报错到修复的全

本文分享了一种优雅复用后台API适配小程序的技术方案。通过重构实现了"一个Service方法服务两种调用方式"的设计目标，将核心业务逻辑与认证方式解耦。文章详细展示了从分离到统一的重构过程，包括责任划分、状态演进和类关系设计，并通过时序图、状态图和ER图清晰呈现系统架构。最终实现了代码复用率提升、维护成本降低的目标，同时保持了业务逻辑的清晰性。这种"一鱼两吃"的方案为多端API复用提供了可借鉴的实践模式。

本文介绍了一种基于Spring Boot的"配置驱动"多租户识别方案，通过外部化配置和自定义请求头实现优雅的多小程序支持。核心设计包括：在application.yml中定义小程序到管理员的映射关系；通过自定义请求头X-App-ID识别小程序身份；使用@ConfigurationProperties加载配置；控制器根据请求头动态查询对应管理员ID。该方案遵循配置与代码分离原则，具有高扩展性和低耦合性，新增小程序只需修改配置无需更改代码，完美支持业务快速扩展需求。

摘要 本文针对 @PassToken 注解在方法上生效但在类上失效的问题展开分析，指出拦截器仅检查方法级别注解而忽略类级别注解是导致问题的根源。通过解析 JwtAuthenticationInterceptor 源代码，发现 method.isAnnotationPresent(PassToken.class) 仅检查方法，未覆盖类注解。解决方案是增加对类级别注解的检查，使用 handlerMethod.getBeanType().isAnnotationPresent(PassToken.class) 完

摘要： 本文深入对比了Spring Boot中两种实现拦截器白名单的方案：excludePathPatterns集中配置式与@PassToken注解式。通过流程图、时序图等可视化方式展示其工作原理，分析两种方案在可维护性、耦合度和可读性上的差异。结果表明，声明式注解方案在解耦、维护和代码可读性方面更具优势，是更推荐的架构选择。文章还提供了状态图和类图，帮助开发者从多维度理解设计差异。（148字）

本文介绍了Spring Boot中的拦截器机制，重点解析了JwtInterceptorConfig配置类的功能和实现方式。通过类比机场安检系统，文章说明了拦截器如何管理请求路径的访问控制，包括配置拦截范围和白名单。文中包含多个可视化图表：流程图展示请求处理流程，时序图说明组件间交互，状态图描述请求认证状态变化。JwtInterceptorConfig通过实现WebMvcConfigurer接口，使用InterceptorRegistry以流式API方式定义拦截规则，为Web应用提供了一种优雅的横切关注点处理

摘要：带有额外属性的多对多关系设计实践 本文以"用户收藏产品"场景为例，深入解析多对多关系设计中如何处理关联属性问题。通过创建中间表实体SolutionUserCollection，将多对多关系转换为两个一对多关系，完美解决了收藏时间等关联属性的存储需求。文章详细介绍了从需求分析、数据库设计到代码实现的完整流程，包括ER图、类图展示和操作时序说明。关键点在于识别出关联本身的属性（如收藏时间），并通过中间实体实现关系降级，这种设计既能保持数据规范性，又能灵活查询关联属性。该模式适用于电商、

摘要：本文深入解析Java中BigDecimal的setScale()方法在金融领域的应用。通过库存×团购价的计算案例，演示如何使用RoundingMode.HALF_UP实现四舍五入到整数。文章对比了8种舍入模式，强调setScale()在精度控制中的关键作用，并附流程图和时序图说明其内部处理机制。针对金额计算场景，本文提供了避免精度损失的完整解决方案，帮助开发者掌握高精度数值处理的核心技术。（149字）

本文探讨了在VO层保持BigDecimal类型并配合Service层处理精度控制的最佳实践。通过四舍五入"货盘总值"的业务场景，对比分析了两种实现方案：VO中使用Integer类型（易丢失信息）与保持BigDecimal类型（推荐）。文章以流程图和时序图展示了后端精确计算、舍入但不改变类型的技术实现，并通过类图说明保持BigDecimal的四大优势：保留语义完整性、避免信息丢失、提升展示灵活性、防止数值溢出。这种设计既满足当前需求，又为未来变更预留空间，体现了专业的技术前瞻性。

后端计算派生值的优势解析 在前后端分离架构中，将"派生值"计算放在后端Service层是最佳实践。以"货盘总值=最大库存×团购价"为例，后端计算方案相比前端计算具有显著优势： 1️⃣ 统一业务逻辑：避免多端重复实现，确保计算结果一致 2️⃣ 精确计算：后端使用BigDecimal等精确计算类型，规避前端浮点精度问题 3️⃣ 接口语义清晰：提供即用型数据，降低前端复杂度 4️⃣ 性能优化：减少客户端计算负担，特别适合复杂运算场景 5️⃣ 维护便利：业务变更只需修改一处，

Spring Boot多实体并发控制指南 在电商、金融等涉及用户资产(优惠券/积分/余额)的场景中，并发控制至关重要。当热门活动引发大量请求时，不当处理可能导致优惠券重复使用或积分超额扣除等严重问题。 本文以TransactionProcessingService为例，解析在多实体(用户、优惠券、积分)更新场景下实现优雅并发控制的方案。主要内容包括： 典型并发风险场景分析 数据一致性解决方案 实战代码示例 通过合理的并发控制机制，可以有效避免数据不一致问题，保障用户体验和系统安全。

这篇技术博客介绍了使用SQL查询多个ID数据的完整流程。文章通过表格总结了关键步骤（查询语句编写、数据库连接、执行验证和优化扩展），并配以Mermaid绘制的流程图、时序图和状态图，直观展示了查询过程。同时还提供了Product实体类图和思维导图，全面解析了技术实现。最后建议通过添加索引和选择InnoDB引擎来优化性能，为开发者提供了实用的SQL查询指导。文章结构清晰，图文并茂，便于技术人员快速理解并应用。

API 设计中的 Save/Update 合并与分离策略需要根据业务场景灵活选择。本文通过 SystemConfig 和 PointRule 两个案例，对比分析了两种设计方式的适用场景：针对上下文唯一性的配置类资源（如 SystemConfig）更适合采用统一的 saveOrUpdate 操作，因其业务语义更自然且能利用 JPA 的 Upsert 特性；而对于可多实例的独立资源（如 PointRule），则应保持创建和更新操作的分离，以确保 RESTful 风格清晰和操作意图明确。设计决策应综合考虑资源特性

摘要：分页中的size参数决定了每页显示的数据量，它从全局排序后的结果集中切割出指定数量的记录。合理的size设置能平衡用户体验（加载速度与翻页次数）和系统性能（数据库查询负载和网络传输）。size不影响全局排序范围，仅控制最终展现的数据切片，常见默认值为10、20或50，需根据实际场景优化选择。

本文深入解析了Spring Boot项目中常用的自定义分页参数类BasePage的核心方法toPageable()。该方法将前端传入的分页和排序参数转换为Spring Data JPA兼容的Pageable对象，实现了分页查询的优雅处理。 关键特性包括： 1️⃣ 页码和每页大小处理（默认值设置和参数校验） 2️⃣ 排序方向转换（支持ASC/DESC，默认降序） 3️⃣ 排序字段处理（支持多字段排序，默认createdDate） 4️⃣ 最终生成PageRequest对象用于Spring Data JPA查询

摘要：本文介绍了如何使用DTO模式解决Spring Boot API中JSON序列化时的无限递归问题。当JPA实体存在双向关联时，Jackson序列化会导致StackOverflowError。通过创建专门的MiniProgramConfigDto和CurrencyBriefDto，仅暴露必要字段并切断循环引用，Service层负责实体与DTO的转换。这种方案比@JsonIgnore等注解更灵活，能清晰定义API契约并提升安全性。关键步骤包括定义DTO类、改造Service层转换逻辑，最终实现结构清晰的AP

摘要： 积分配置重构实战总结：将原本基于键值对的分散存储升级为结构化的实体字段存储，实现前后端协同优化。后端实体SystemConfig新增exchangeRate和maxDeductionLimit字段，使用DTO进行类型化传输，简化服务层逻辑；前端调整表单提交逻辑，构造单一Payload对象并完成数据转换。重构后数据结构更清晰、类型更安全，API接口更符合单一职责，同时保持用户体验不变。关键改进包括：数据模型实体化、后端逻辑集中化、API接口简化、数据校验规范化，实现了从底层存储到业务逻辑的全面升级。

后端唯一约束Bug修复之旅 问题表现：系统配置保存时出现 Duplicate entry 错误，根源在于数据库唯一约束与业务逻辑不一致。 问题分析： 业务逻辑要求 (config_key, mini_program_id) 组合唯一 数据库实际仅对 config_key 设置了唯一约束 导致服务层试图保存合理数据时被数据库拒绝 解决方案： 备份数据 删除原有错误约束 新增正确的复合唯一约束 (config_key, mini_program_id) 成果验证：修改后系统能够正确区分全局和特定小程序配置，

积分配置管理接口解析 该接口负责保存或更新积分系统的全局/小程序配置，主要特点： 功能设计 支持批量处理多条配置项 区分全局配置和小程序专属配置 包含币种关联的积分兑换功能 安全机制 管理员会话验证 权限分级控制（全局配置/小程序配置权限） 数据完整性校验（DTO验证、币种校验） 技术实现 使用事务管理确保数据一致性 分步骤处理：权限验证→数据校验→持久化操作 采用分层架构（Controller→Service） 扩展性 预留币种关联扩展点 支持国际化配置 模块化设计便于功能扩展 接口通过严格的权限控制和数

摘要： 本文深入解析了后台与小程序用户身份统一管理的核心代码逻辑adminId = adminApiService.initAdminId(adminId, userId)。该方法通过一个条件判断流程决定最终管理员身份：当小程序用户ID(userId)存在时，会先查找对应的用户信息，再通过微信OpenID关联后台管理员账号；若未找到关联则保持原始adminId。流程图清晰地展示了三种处理路径：直接返回原始adminId、成功关联新adminId，以及用户不存在时的异常情况。时序图则演示了不同输入场景下的服务

摘要 本文探讨了API开发中常见的参数传递问题：前端在JSON请求体中发送的参数（如consignmentType）无法被后端@RequestParam正确接收的现象。通过分析发现，@RequestBody和@RequestParam的作用域不同，前者处理整个请求体，后者读取URL查询参数。解决方案建议：1）分离参数类型，将可选过滤参数通过URL查询参数发送；2）保持通用DTO的纯粹性；3）前端对可选参数进行有效性判断。

摘要：文章探讨了API返回空列表但数据库有数据的常见分页问题排查方法。通过流程图和表格详细梳理了排查步骤，包括检查前端页码参数、后端分页处理、日志级别、数据库连接和JPA查询等关键点。重点分析了前端初始加载时传递的1-indexed页码与后端0-indexed机制不匹配的典型问题，并提供了开启DEBUG日志、调整后端分页处理等解决方案。帮助开发者快速定位和解决分页查询中的数据不一致问题。

本文介绍了使用Spring Boot和JPA实现订单产品查询与批量更新备注的API设计。主要内容包括： 两个核心API接口： GET分页查询接口：根据订单号查询产品记录，支持分页和筛选 PUT批量更新接口：按订单号更新产品备注 技术架构： 采用Spring Boot + JPA(Hibernate)技术栈 使用Lombok简化代码，Swagger生成API文档 查询功能实现： 使用JPA Specification构建动态查询条件 实现分页和排序功能 设计了完整的请求处理流程 系统特点：