<rss xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title>Lombok - tag - 沐木</title><link>https://oldletter.cn/tags/lombok/</link><description>Lombok - tag - 沐木</description><generator>Hugo -- gohugo.io</generator><language>zh-cn</language><lastBuildDate>Tue, 10 Sep 2024 00:00:00 +0000</lastBuildDate><atom:link href="https://oldletter.cn/tags/lombok/" rel="self" type="application/rss+xml"/><item><title>Lombok 进阶指南：从注解原理到 Spring Boot 最佳实践</title><link>https://oldletter.cn/posts/java-01-lombok/</link><pubDate>Mon, 20 Mar 2023 00:00:00 +0000</pubDate><author>mumu</author><guid>https://oldletter.cn/posts/java-01-lombok/</guid><description><![CDATA[<blockquote>
<p>📅 2026-05-15 | 🏷️ Java, Lombok, Spring Boot | 📖 阅读约 15 分钟</p></blockquote>
<h2 id="前言">前言</h2>
<p>Lombok 大家都在用，但你真的用对了吗？</p>
<p>很多团队把 Lombok 当成&quot;少写 getter/setter 的工具&quot;，结果在生产环境踩了一堆坑：<code>@Data</code> 导致的 <code>StackOverflowError</code>、序列化失败、MapStruct 不兼容……</p>
<p>这篇文章并非入门教程，重点是<strong>进阶实战指南</strong>，我会从注解的底层原理讲起，结合 Spring Boot 3.x 工程实践，帮你避开那些&quot;写了半天 debug 两小时&quot;的坑。</p>
<p><strong>适合读者</strong>：有 Lombok 基础使用经验，想深入了解原理和成熟实践的 Java 开发者。</p>
<div class="details admonition note open">
    <div class="details-summary admonition-title">
        <i class="icon far fa-pen-to-square" aria-hidden="true"></i>版本说明<i class="details-icon fas fa-angle-right" aria-hidden="true"></i>
    </div>
    <div class="details-content">
        <div class="admonition-content">本文以 Lombok 1.18.x 的常见行为为基准。Spring Boot 3.x + JDK 17/21 用户请参考第五节的兼容性说明；如果使用更高版本 JDK，记得同步升级 Lombok，否则很容易在编译期踩坑。</div>
    </div>
</div>
<hr>
<h2 id="一基础核心注解的隐藏陷阱">一、基础核心注解的&quot;隐藏陷阱&quot;</h2>
<h3 id="11-data方便但危险">1.1 @Data：方便但危险</h3>
<p><code>@Data</code> 是 Lombok 更常用的注解，它等价于 <code>@Getter + @Setter + @ToString + @EqualsAndHashCode + @RequiredArgsConstructor</code>。听起来很美好，但问题恰恰出在这个&quot;全家桶&quot;上。</p>]]></description></item><item><title>API 鉴权实战（一）：AK/SK、API Key、RBAC 与统一认证授权架构设计</title><link>https://oldletter.cn/posts/api-auth-01-aksk-rbac/</link><pubDate>Tue, 10 Sep 2024 00:00:00 +0000</pubDate><author>mumu</author><guid>https://oldletter.cn/posts/api-auth-01-aksk-rbac/</guid><description><![CDATA[<blockquote>
<p>作者：林 | 系列：API 鉴权实战 | 适合读者：Java 后端/架构师</p></blockquote>
<blockquote>
<p>本文代码使用 Lombok 简化 POJO，所有 getter/setter/builder 均由 Lombok 自动生成。</p></blockquote>
<div class="code-block code-line-numbers open" style="counter-reset: code-block 0">
    <div class="code-header language-xml">
        <span class="code-title"><i class="arrow fas fa-angle-right" aria-hidden="true"></i></span>
        <span class="ellipses"><i class="fas fa-ellipsis-h" aria-hidden="true"></i></span>
        <span class="copy" title=""><i class="far fa-copy" aria-hidden="true"></i></span>
    </div><div class="highlight"><pre tabindex="0" class="chroma"><code class="language-xml" data-lang="xml"><span class="line"><span class="cl"><span class="c">&lt;!-- pom.xml --&gt;</span>
</span></span><span class="line"><span class="cl"><span class="nt">&lt;dependency&gt;</span>
</span></span><span class="line"><span class="cl">    <span class="nt">&lt;groupId&gt;</span>org.projectlombok<span class="nt">&lt;/groupId&gt;</span>
</span></span><span class="line"><span class="cl">    <span class="nt">&lt;artifactId&gt;</span>lombok<span class="nt">&lt;/artifactId&gt;</span>
</span></span><span class="line"><span class="cl">    <span class="nt">&lt;scope&gt;</span>provided<span class="nt">&lt;/scope&gt;</span>
</span></span><span class="line"><span class="cl"><span class="nt">&lt;/dependency&gt;</span></span></span></code></pre></div></div>
<hr>
<h2 id="一背景为什么要做-api-鉴权">一、背景：为什么要做 API 鉴权</h2>
<p>对外暴露 API 时，两个核心问题绕不开：</p>
<ol>
<li><strong>调用方是谁？</strong>（认证，Authentication）</li>
<li><strong>他能做什么？</strong>（授权，Authorization）</li>
</ol>
<p>简单的内部系统可能用一个 API Key 就够了。但当系统开始支持多租户、第三方接入、AI 开放平台、文件上传、额度控制时，单一的鉴权方式撑不住。你需要一套完整的体系：从密钥管理到权限判断，从缓存设计到上下文传递。</p>
<p>本文从更基础的 API Key 讲起，逐步构建到 PDP 策略决策点，把认证授权的全链路打通。</p>
<hr>
<h2 id="二五种鉴权方式详解">二、五种鉴权方式详解</h2>
<h3 id="21-api-key">2.1 API Key</h3>
<p><strong>原理：</strong> 给每个调用方分配一个唯一的密钥字符串，请求时放在 Header 里，服务端查库校验。</p>
<p><strong>适用场景：</strong> 内部服务间调用、快速原型、低安全要求的公开 API。</p>
<p><strong>不适用场景：</strong> 对外开放的 API，API Key 是静态的，明文传输，一旦被截获攻击者就能冒充调用方。</p>]]></description></item></channel></rss>