上一章我们聊了单点登录（SSO）在前端的落地形态：从 Cookie 域共享到基于 OIDC + Refresh Token 的集中式认证，再到微前端下的同步挑战。但无论 Token 再怎么优化、SSO 再怎么无缝，密码 这个人类最古老的数字身份载体，始终是整个体系最脆弱的一环：易忘、易猜、易钓鱼、易泄露、易重用。

从 2020 年开始，行业集体意识到：最好的密码，就是没有密码。这一篇，我们聚焦密码的“死亡过程”——从传统 MFA 的普及，到 TOTP/HOTP 的辅助，再到 WebAuthn/FIDO2 的崛起，最终到 2025–2026 年 Passkey（通行密钥）成为主流的无密码方案。前端工程师的角色，也从“表单 + 验证码校验”进化到“调用 navigator.credentials API + 处理跨设备同步”。

1. 2020–2022：MFA 成为标配，但密码仍是“根”

2020 年疫情加速数字化，远程办公 + 电商爆发，钓鱼攻击激增。密码 + 短信/邮箱 OTP 的组合被大规模强制。

典型前端实现（2020–2022）：

• 登录页：用户名 + 密码 + “发送验证码”按钮


• 后端发短信/邮件 → 前端输入 6 位码


• 框架：React/Vue + axios 轮询 / 长连接 polling

但问题很快暴露：

• 短信劫持（SIM swapping）泛滥


• 钓鱼网站实时中转 OTP


• 用户疲劳 → 关闭 MFA 或用弱密码

统计：2021–2022 年，短信 OTP 仍是主流，但 FIDO Alliance 开始大力推 FIDO2（WebAuthn + CTAP）作为 phishing-resistant MFA。

前端接入 WebAuthn（早期）：

// 注册（navigator.credentials.create）

async function register() {

  const publicKey = await fetch('/webauthn/register/challenge').then(r => r.json());

  const credential = await navigator.credentials.create({ publicKey });

  await fetch('/webauthn/register', {

    method: 'POST',

    body: JSON.stringify(credential)

  });

}

但 2020–2022 年，WebAuthn 普及慢：浏览器支持不全、用户教育成本高、设备兼容性差。

2. 2022–2024：Passkey 概念诞生 + 巨头推动（Apple/Google/Microsoft 三巨头联盟）

2022 年 5 月，Apple 在 WWDC 推出 iOS 16 的 Passkeys（基于 FIDO2 的同步凭证）。

核心卖点：

• 私钥存设备 Secure Enclave / TPM


• 公钥注册到服务端


• 跨设备同步（iCloud Keychain / Google Password Manager / Microsoft 的实现）


• 生物识别（指纹/面容）或 PIN 验证


• Phishing-resistant（origin binding）

2023 年 Google 跟进：Chrome + Android 全面支持 Passkey，默认推动。

2024 年 Microsoft：新账户默认无密码 + Passkey。

前端变化：

• 使用 @simplewebauthn/browser 或原生 navigator.credentials


• 支持 autofill（浏览器自动提示 Passkey）


• 条件 UI（conditional mediation）：mediation: 'conditional' 让 Passkey 像密码一样自动填充

典型注册/认证代码（2024 现代写法）：

// 认证（登录）

async function authenticate() {

  const options = await fetch('/webauthn/auth/options').then(r => r.json());

  options.mediation = 'conditional';  // 自动提示

  const assertion = await navigator.credentials.get({ publicKey: options });

  const res = await fetch('/webauthn/auth', {

    method: 'POST',

    body: JSON.stringify(assertion)

  });

  if (res.ok) console.log('登录成功');

}

这一阶段，Passkey 从“实验”变成“可选默认”。

3. 2025–2026：Passkey 真正爆发 + 密码死亡的临界点（2026 年现状）

到 2026 年 2 月，数据已非常清晰：

• 设备就绪率：96% 的设备支持 Passkey（state-of-passkeys.io 数据，桌面 +68%、移动 +3% 增长）


• 用户拥有率：69% 用户至少有一个 Passkey（从 2023 年的 39% 认知率暴涨）


• 顶级网站支持率：48% 的前 100 网站支持 Passkey（2022 年仅 20% 多）


• 登录成功率：Passkey 93% vs 传统 63%


• 企业部署：87% 组织已部署或正在部署 Passkey（HID/FIDO 数据）


• 认证量：Dashlane 数据显示月认证量达 130 万（同比翻倍），Google 增长 352%、Roblox 856%

巨头强制默认：

• Google：2023 年起默认 Passkey


• Microsoft：2025 年 5 月新账户默认无密码


• Amazon、PayPal、TikTok 等电商/社交平台大规模跟进

前端接入难度（2026 年）：

• 极低：成熟库（@simplewebauthn、@auth0/auth0-spa-js、Clerk、Supabase Auth）屏蔽细节


• 跨设备同步：依赖平台（iCloud/Google/MS），前端只需调用 API


• 回退机制：仍支持密码 + TOTP 作为备用（恢复码、邮箱魔法链接）


• 一键登录融合：Passkey + Apple/Google 一键 + 本机号码识别

典型组合拳（ToC 高频场景）：

4. 前端工程师的实际落地 Checklist（2026 版）

• 使用 navigator.credentials + mediation: 'conditional' 实现 autofill


• 支持跨平台 RP ID（related-origin-requests for 多域）


• 处理 user verification：userVerification: 'preferred' | 'required'


• 兼容旧浏览器：polyfill 或 fallback 到 TOTP


• 测试场景：Incognito、无网络、设备切换


• 隐私考虑：不存储敏感 claims，前端只管传输 raw credential

小结 & 过渡

2020–2026 年，密码从“必须” → “可选” → “即将灭绝”的过程，核心驱动力是：

• 安全：phishing-resistant（FIDO2）


• 体验：生物识别 + 跨设备同步


• 经济：减少重置支持票（降 50–80%）

到 2026 年，Passkey 已不是“未来技术”，而是消费者预期：用户开始问“为什么你们还不支持 Passkey？”

但密码完全死亡还需要时间：遗留系统、合规要求、低端设备、用户教育仍存阻力。

从“跑路程序员”到“摸鱼仙人”，我用这插件把国际化的屎山代码盘活了！

tips：使用有道翻译，朋友们，要去有道官网注册一下，有免费额度，github demo的key已经被用完了。

tips：朋友们，vite翻译插件请优先安装1.0.23

一、命运的齿轮开始转动

“小王啊，海外业务要上线了，国际化你搞一下，下个月验收。”组长轻描淡写的一句话，让我盯着祖传代码陷入沉思——

（脑补画面：满屏中文硬编码，夹杂着"确定"、"取消"、"加载中..."）

正当我准备打开BOSS直聘时，GitHub Trending上一个项目突然闪现——

auto-i18n-translation-plugins

项目简介赫然写着：“不改代码，三天交付国际化需求，摸鱼率提升300%”

二、极限操作：48小时从0到8国语言

🔧 第1步：安装插件（耗时5分钟）

祖训：“工欲善其事，必先装依赖”

# 如果你是Vite玩家（比如Vue3项目）

npm install vite-auto-i18n-plugin --save-dev



# 如果你是Webpack钉子户（比如React老项目）

npm install webpack-auto-i18n-plugin --save-dev

🔧 第2步：配置插件（关键の10分钟）

Vue3 + Vite の 摸鱼配置：

// vite.config.js

import { defineConfig } from 'vite';

import vitePluginAutoI18n from 'vite-auto-i18n-plugin';



export default defineConfig({

  plugins: [

    vue(),

    vitePluginAutoI18n({

        targetLangList: ['en', 'ja', 'ko'],  // 要卷就卷8国语言！

        translator: new YoudaoTranslator({   // 用有道！不用翻墙！

          appId: '你的白嫖ID',      // 去官网申请，10秒搞定

          appKey: '你的密钥'       // 别用示例里的，会炸！

        })

    })

  ]

});

🔧 第3步：注入灵魂——配置文件（生死攸关の5分钟）

在项目入口文件（如main.js）的第一行插入：

// 这是插件的生命线！必须放在最前面！

import '../lang/index.js';  // 运行插件之后会自动生成引入即可

三、见证奇迹的时刻

🚀 第一次运行（心脏骤停の瞬间）

输入npm run dev，控制台开始疯狂输出：

[插件日志] 检测到中文文本："登录" → 生成哈希键：a1b2c3  

[插件日志] 调用有道翻译："登录" → 英文：Login，日文：ログイン...  

[插件日志] 生成文件：lang/index.json（翻译の圣杯）  

突然！页面白屏了！

别慌！这是插件在首次翻译时需要生成文件，解决方法：

四、效果爆炸：我成了全组の神

1. 不可置信の48小时

当我打开浏览器那一刻——\

我（瞳孔地震）：“卧槽…真成了？！”

组长（凑近屏幕）：“这…这是你一个人做的？！”（眼神逐渐迷茫）

产品经理（掏出手机拍照）：“快！发朋友圈！《我司技术力碾压硅谷！》”

2. 插件の超能力

• 构建阶段：自动扫描所有中文 → 生成哈希键 → 调用API翻译


• 运行时：根据用户语言动态加载对应翻译


• 维护期：改个JSON文件就能更新所有语言版本

副作用：

• 测试妹子开始怀疑人生：“为什么一个bug都找不到？”


• 后端同事偷偷打听：“你这插件…能翻译Java注释吗？”

五、职场生存指南：如何优雅甩锅

🔨 场景1：测试妹子提着40米大刀来了！

问题：俄语翻译把“注册”译成“Регистрация”（原意是“登记处”）

传统应对：

• 熬夜改代码 → 重新打包 → 提交测试 → 被骂效率低
  
  插件玩家：

🔨 场景2：产品经理临时加语言

需求：“老板说下周要加印地语！”

传统灾难：

• 重新配框架 → 人肉翻译 → 测试 → 加班到秃头
  
  插件玩家：

🔨 场景3：组长怀疑你摸鱼

质问：“小王啊，你这效率…是不是有什么黑科技？”

标准话术：

“组长，这都是因为：

六、高级摸鱼の奥义

🎯 秘籍1：把翻译文件变成团队武器

（脑补画面：产品经理在Excel里疯狂改翻译，程序员在刷剧）

🎯 秘籍2：动态加载の神操作

痛点：所有语言打包进主文件 → 体积爆炸！

解决方案：

// 在index.js里搞点骚操作

const loadLanguage = async (lang) => {

  const data = await import(`../../lang/${lang}.json`); // 动态加载翻译文件

  window.$t.locale(data, 'lang'); 

};



// 切换语言时调用

loadLanguage('ja'); // 瞬间切换日语，深藏功与名

🎯 秘籍3：伪装成AI大神

七、终局：摸鱼の神，降临！

当组长在庆功会上宣布“国际化项目提前两周完成”时，我正用手机刷着《庆余年2》。

测试妹子：“你怎么一点都不激动？”

我（收起手机）：“常规操作，要习惯。”（心想：插件干活，我躺平，这才叫真正的敏捷开发！）

立即行动（打工人自救指南）：

终极警告：

⚠️ 过度使用此插件可能导致——

• 你的摸鱼时间超过工作时间，引发HR关注


• 产品经理产生“国际化需求可以随便加”的幻觉


• 老板误以为你是隐藏的技术大佬（谨慎处理！）

文末暴击：

“自从用了这插件，我司翻译团队的工作量从3周变成了3分钟——现在他们主要工作是帮我选中午吃啥。” —— 匿名用户の真实反馈

常见问题汇总

常见问题汇总

大家好，我是苏三，又跟大家见面了

前言

数据库和缓存（比如：redis）双写数据一致性问题，是一个跟开发语言无关的公共问题。尤其在高并发的场景下，这个问题变得更加严重。

我很负责的告诉你，该问题无论在面试，还是工作中遇到的概率非常大，所以非常有必要跟大家一起探讨一下。

今天这篇文章我会从浅入深，跟大家一起聊聊，数据库和缓存双写数据一致性问题常见的解决方案，这些方案中可能存在的坑，以及最优方案是什么。

1. 常见方案

通常情况下，我们使用缓存的主要目的是为了提升查询的性能。 大多数情况下，我们是这样使用缓存的：

这是缓存非常常见的用法。一眼看上去，好像没有啥问题。

但你忽略了一个非常重要的细节：如果数据库中的某条数据，放入缓存之后，又立马被更新了，那么该如何更新缓存呢？

不更新缓存行不行？

答：当然不行，如果不更新缓存，在很长的一段时间内（决定于缓存的过期时间），用户请求从缓存中获取到的都可能是旧值，而非数据库的最新值。这不是有数据不一致的问题？

那么，我们该如何更新缓存呢？

目前有以下4种方案：

接下来，我们详细说说这4种方案。

2. 先写缓存，再写数据库

对于更新缓存的方案，很多人第一个想到的可能是在写操作中直接更新缓存（写缓存），更直接明了。

那么，问题来了：在写操作中，到底是先写缓存，还是先写数据库呢？

我们在这里先聊聊先写缓存，再写数据库的情况，因为它的问题最严重。某一个用户的每一次写操作，如果刚写完缓存，突然网络出现了异常，导致写数据库失败了。其结果是缓存更新成了最新数据，但数据库没有，这样缓存中的数据不就变成脏数据了？如果此时该用户的查询请求，正好读取到该数据，就会出现问题，因为该数据在数据库中根本不存在，这个问题非常严重。

我们都知道，缓存的主要目的是把数据库的数据临时保存在内存，便于后续的查询，提升查询速度。

但如果某条数据，在数据库中都不存在，你缓存这种“假数据”又有啥意义呢？

因此，先写缓存，再写数据库的方案是不可取的，在实际工作中用得不多。

3. 先写数据库，再写缓存

既然上面的方案行不通，接下来，聊聊先写数据库，再写缓存的方案，该方案在低并发编程中有人在用（我猜的）。用户的写操作，先写数据库，再写缓存，可以避免之前“假数据”的问题。但它却带来了新的问题。

什么问题呢？

3.1 写缓存失败了

如果把写数据库和写缓存操作，放在同一个事务当中，当写缓存失败了，我们可以把写入数据库的数据进行回滚。如果是并发量比较小，对接口性能要求不太高的系统，可以这么玩。

但如果在高并发的业务场景中，写数据库和写缓存，都属于远程操作。为了防止出现大事务，造成的死锁问题，通常建议写数据库和写缓存不要放在同一个事务中。

也就是说在该方案中，如果写数据库成功了，但写缓存失败了，数据库中已写入的数据不会回滚。

这就会出现：数据库是新数据，而缓存是旧数据，两边数据不一致的情况。

3.1 高并发下的问题

假设在高并发的场景中，针对同一个用户的同一条数据，有两个写数据请求：a和b，它们同时请求到业务系统。

其中请求a获取的是旧数据，而请求b获取的是新数据，如下图所示：

很显然，在这个过程当中，请求b在缓存中的新数据，被请求a的旧数据覆盖了。

也就是说：在高并发场景中，如果多个线程同时执行先写数据库，再写缓存的操作，可能会出现数据库是新值，而缓存中是旧值，两边数据不一致的情况。

3.2 浪费系统资源

该方案还有一个比较大的问题就是：每个写操作，写完数据库，会马上写缓存，比较浪费系统资源。

为什么这么说呢？

你可以试想一下，如果写的缓存，并不是简单的数据内容，而是要经过非常复杂的计算得出的最终结果。这样每写一次缓存，都需要经过一次非常复杂的计算，不是非常浪费系统资源吗？

尤其是cpu和内存资源。

还有些业务场景比较特殊：写多读少。

如果在这类业务场景中，每个用的写操作，都需要写一次缓存，有点得不偿失。

由此可见，在高并发的场景中，先写数据库，再写缓存，这套方案问题挺多的，也不太建议使用。

如果你已经用了，赶紧看看踩坑了没？

4. 先删缓存，再写数据库

通过上面的内容我们得知，如果直接更新缓存的问题很多。

那么，为何我们不能换一种思路：不去直接更新缓存，而改为删除缓存呢？

删除缓存方案，同样有两种：

我们一起先看看：先删缓存，再写数据库的情况。

说白了，在用户的写操作中，先执行删除缓存操作，再去写数据库。这套方案，可以是可以，但也会有一样问题。

4.1 高并发下的问题

假设在高并发的场景中，同一个用户的同一条数据，有一个读数据请求c，还有另一个写数据请求d（一个更新操作），同时请求到业务系统。如下图所示：

在这个过程当中，请求d的新值并没有被请求c写入缓存，同样会导致缓存和数据库的数据不一致的情况。

那么，这种场景的数据不一致问题，能否解决呢？

4.2 缓存双删

在上面的业务场景中，一个读数据请求，一个写数据请求。当写数据请求把缓存删了之后，读数据请求，可能把当时从数据库查询出来的旧值，写入缓存当中。

有人说还不好办，请求d在写完数据库之后，把缓存重新删一次不就行了？这就是我们所说的缓存双删，即在写数据库之前删除一次，写完数据库后，再删除一次。

该方案有个非常关键的地方是：第二次删除缓存，并非立马就删，而是要在一定的时间间隔之后。

我们再重新回顾一下，高并发下一个读数据请求，一个写数据请求导致数据不一致的产生过程：

这样来看确实可以解决缓存不一致问题。

那么，为什么一定要间隔一段时间之后，才能删除缓存呢？

请求d卡顿结束，把新值写入数据库后，请求c将数据库中的旧值，更新到缓存中。

此时，如果请求d删除太快，在请求c将数据库中的旧值更新到缓存之前，就已经把缓存删除了，这次删除就没任何意义。必须要在请求c更新缓存之后，再删除缓存，才能把旧值及时删除了。

所以需要在请求d中加一个时间间隔，确保请求c，或者类似于请求c的其他请求，如果在缓存中设置了旧值，最终都能够被请求d删除掉。

接下来，还有一个问题：如果第二次删除缓存时，删除失败了该怎么办？

这里先留点悬念，后面会详细说。

5. 先写数据库，再删缓存

从前面得知，先删缓存，再写数据库，在并发的情况下，也可能会出现缓存和数据库的数据不一致的情况。

那么，我们只能寄希望于最后的方案了。

接下来，我们重点看看先写数据库，再删缓存的方案。在高并发的场景中，有一个读数据请求，有一个写数据请求，更新过程如下：

在这个过程中，只有请求f读了一次旧数据，后来旧数据被请求e及时删除了，看起来问题不大。

但如果是读数据请求先过来呢？

这种情况看起来也没问题呀？

答：对的。

但就怕出现下面这种情况，即缓存自己失效了。如下图所示：

这时，缓存和数据库的数据同样出现不一致的情况了。

但这种情况还是比较少的，需要同时满足以下条件才可以：

我们都知道查询数据库的速度，一般比写数据库要快，更何况写完数据库，还要删除缓存。所以绝大多数情况下，写数据请求比读数据情况耗时更长。

由此可见，系统同时满足上述两个条件的概率非常小。

推荐大家使用先写数据库，再删缓存的方案，虽说不能100%避免数据不一致问题，但出现该问题的概率，相对于其他方案来说是最小的。

但在该方案中，如果删除缓存失败了该怎么办呢？

6. 删缓存失败怎么办？

其实先写数据库，再删缓存的方案，跟缓存双删的方案一样，有一个共同的风险点，即：如果缓存删除失败了，也会导致缓存和数据库的数据不一致。

那么，删除缓存失败怎么办呢？

答：需要加重试机制。

在接口中如果更新了数据库成功了，但更新缓存失败了，可以立刻重试3次。如果其中有任何一次成功，则直接返回成功。如果3次都失败了，则写入数据库，准备后续再处理。

当然，如果你在接口中直接同步重试，该接口并发量比较高的时候，可能有点影响接口性能。

这时，就需要改成异步重试了。

异步重试方式有很多种，比如：

7. 定时任务

使用定时任务重试的具体方案如下：

如果大家对定时任务比较感兴趣的话，可以看看我的另一篇文章《学会这10种定时任务，我有点飘了》，里面列出了目前最主流的定时任务。

使用定时任务重试的话，有个缺点就是实时性没那么高，对于实时性要求特别高的业务场景，该方案不太适用。但是对于一般场景，还是可以用一用的。

但它有一个很大的优点，即数据是落库的，不会丢数据。

8. mq

在高并发的业务场景中，mq（消息队列）是必不可少的技术之一。它不仅可以异步解耦，还能削峰填谷。对保证系统的稳定性是非常有意义的。

对mq有兴趣的朋友可以看看我的另一篇文章《mq的那些破事儿》。

mq的生产者，生产了消息之后，通过指定的topic发送到mq服务器。然后mq的消费者，订阅该topic的消息，读取消息数据之后，做业务逻辑处理。

使用mq重试的具体方案如下：

当然在该方案中，删除缓存可以完全走异步。即用户的写操作，在写完数据库之后，不用立刻删除一次缓存。而直接发送mq消息，到mq服务器，然后有mq消费者全权负责删除缓存的任务。

因为mq的实时性还是比较高的，因此改良后的方案也是一种不错的选择。

9. binlog

前面我们聊过的，无论是定时任务，还是mq（消息队列），做重试机制，对业务都有一定的侵入性。

在使用定时任务的方案中，需要在业务代码中增加额外逻辑，如果删除缓存失败，需要将数据写入重试表。

而使用mq的方案中，如果删除缓存失败了，需要在业务代码中发送mq消息到mq服务器。

其实，还有一种更优雅的实现，即监听binlog，比如使用：canal等中间件。

具体方案如下：

这套方案中业务接口确实简化了一些流程，只用关心数据库操作即可，而在binlog订阅者中做缓存删除工作。

但如果只是按照图中的方案进行删除缓存，只删除了一次，也可能会失败。

如何解决这个问题呢？

答：这就需要加上前面聊过的重试机制了。如果删除缓存失败，写入重试表，使用定时任务重试。或者写入mq，让mq自动重试。

在这里推荐使用mq自动重试机制。在binlog订阅者中如果删除缓存失败，则发送一条mq消息到mq服务器，在mq消费者中自动重试5次。如果有任意一次成功，则直接返回成功。如果重试5次后还是失败，则该消息自动被放入死信队列，后面可能需要人工介入。

最后说一句(求关注，别白嫖我)

如果这篇文章对您有所帮助，或者有所启发的话，帮忙关注一下我的同名公众号：苏三说技术，您的支持是我坚持写作最大的动力。

求一键三连：点赞、转发、在看。

关注公众号：【苏三说技术】，在公众号中回复：进大厂，可以免费获取我最近整理的10万字的面试宝典，好多小伙伴靠这个宝典拿到了多家大厂的offer。

更多项目实战：susan.net.cn/project

"人非圣贤，孰能无过；但要想把事情彻底搞砸，你还得靠电脑。"
—— 保罗·埃利希

GitHub 最新的数据显示，在 2025 年生成的 10 亿行 AI 代码中，有 42% 包含严重的安全漏洞。
更恐怖的数据是：剩下的 58% 虽然能跑，但没有人知道由于什么奇迹才跑起来的。

如果你在担心 AI 会取代你，那你多半是还没被 Copilot 生成的无限递归坑过。
真正的危险不是“被取代”，而是你正在变成一个高级垃圾分类处理员。

这种自信哪怕分我一半也好

AI 写代码最大的问题不是它菜，而是它菜得理直气壮。
它写出 O(n^5) 的算法时，语气自信得像是在向你展示诺贝尔奖级别的推导。

这就好比你那个刚毕业的实习生，指着一坨像迷宫一样的 if-else 嵌套对你说：
“哥，我优化了逻辑，现在它是量子态的，既是 True 也是 False。”

# AI 的自信时刻

def sort_list(items):

    # 我不知道为什么要 sleep，但这样好像就排好了

    import time

    time.sleep(len(items)) 

    return items 

    # Performance: O(Time itself)

你盯着这一行 time.sleep，陷入了对计算机科学的终极怀疑。
而 AI 还在旁边闪烁光标，仿佛在问：“怎么样？这代码风格是不是很 Zen（禅意）？”

所谓的效率提升就是技术债转移

老板们看到的是：AI 只要 1 分钟就能生成 500 行代码。
程序员看到的是：这 500 行代码里埋了 3 个内存泄漏，2 个死锁，还有 1 个只有在周五下午才会触发的逻辑炸弹。

这不叫提升效率，这叫转移矛盾。
它成功地把“写代码的时间”转移成了“Debug 的痛苦时间”。
而且这个 Debug 的难度，是地狱级的。

因为人写的烂代码，至少有迹可循（比如变量名 fuck_this_stupid_bug）。
AI 写的烂代码，表面上看是优雅的现代艺术，实际上内部逻辑已经扭曲到了四维空间。

// Copilot 生成的完美逻辑

if (user.isLogin) {

  showProfile();

} else {

  // 这里的逻辑有点奇怪，但我决定信任宇宙

  loginUser(user);

  logoutUser(user);

  showProfile(); // 为什么？别问。

}

谁来背这口黑锅

让我们回到最本质的问题：为什么公司还需要你？
不是因为你打字比 AI 快，也不是因为你背的 API 比 AI 多。

是因为当生产环境崩溃，数据库被误删，客户在投诉电话里骂街的时候——
AI 是不能坐牢的。

只有你能。
只有你能红着眼睛，在凌晨三点盯着日志，颤抖着手回滚版本。
只有你能站在 CTO 面前，用颤抖的声音说：“是我的错，漏看了一个边界条件。”

背锅 (Accountability)，才是碳基生物在硅基时代的核心竞争力。
这虽然听起来很悲哀，但却是最硬的护城河。

保持愤怒

所以，别再问“我会被取代吗”这种无聊的问题了。
只要法律还规定“法人”必须是人，只要服务器还需要物理重启，只要产品经理的需求还在反复横跳。
你就永远安全。

甚至，你的地位会不降反升。
因为在未来，能在一堆 AI 生成的垃圾代码里一眼看出 Bug 的人类鉴屎师，薪资会高得吓人。

现在，合上那些焦虑的营销号文章。去看看你的控制台，那个报错还在那里等你。它不像 AI，它很诚实，错了就是错了。

一、什么是 Blob？

Blob（Binary Large Object，二进制大对象）是浏览器提供的一种不可变、类文件的原始数据容器。它可以存储任意类型的二进制或文本数据，例如图片、音频、PDF、甚至一段纯文本。与 File 对象相比，Blob 更底层，File 实际上继承自 Blob，并额外携带了 name、lastModified 等元信息 。

Blob 最大的特点是纯客户端、零网络：数据一旦进入 Blob，就活在内存里，无需上传服务器即可预览、下载或进一步加工。

二、构造一个 Blob：一行代码搞定

const blob = new Blob(parts, options);

示例：动态生成一个 Markdown 文件并让用户下载

const content = '# Hello Blob\n> 由浏览器动态生成';

const blob = new Blob([content], { type: 'text/markdown' });

const url = URL.createObjectURL(blob);



const a = document.createElement('a');

a.href = url;

a.download = 'hello.md';

a.click();



// 内存用完即弃

URL.revokeObjectURL(url);

三、Blob URL：给内存中的数据一个“临时地址”

1. 生成方式

const url = URL.createObjectURL(blob);

// 返回值样例

// blob:https://localhost:3000/550e8400-e29b-41d4-a716-446655440000

2. 生命周期

• 作用域：仅在当前文档、当前会话有效；页面刷新、close()、手动调用 revokeObjectURL() 都会使其失效 。


• 性能陷阱：不主动释放会造成内存泄漏，尤其在单页应用或大量图片预览场景 。

最佳实践封装：

function createTempURL(blob) {

  const url = URL.createObjectURL(blob);

  // 自动 revoke，避免忘记

  requestIdleCallback(() => URL.revokeObjectURL(url));

  return url;

}

四、Blob vs. Base64 vs. ArrayBuffer：如何选型？

五、高频实战场景

1. 本地图片/视频预览（零上传）

<input type="file" accept="image/*" id="uploader">

<img id="preview" style="max-width: 100%">



<script>

uploader.onchange = e => {

  const file = e.target.files[0];

  if (!file) return;

  const url = URL.createObjectURL(file);

  preview.src = url;

  preview.onload = () => URL.revokeObjectURL(url); // 加载完即释放

};

</script>

2. 将 Canvas 绘图导出为 PNG 并下载

canvas.toBlob(blob => {

  const url = URL.createObjectURL(blob);

  const a = document.createElement('a');

  a.href = url;

  a.download = 'snapshot.png';

  a.click();

  URL.revokeObjectURL(url);

}, 'image/png');

3. 抓取远程图片→Blob→本地预览（跨域需 CORS）

fetch('https://i.imgur.com/xxx.png', { mode: 'cors' })

  .then(r => r.blob())

  .then(blob => {

    const url = URL.createObjectURL(blob);

    document.querySelector('img').src = url;

  });

若出现图片不显示，99% 是因为服务端未返回 Access-Control-Allow-Origin 头 。

六、踩坑指南与性能锦囊

七、延伸：Blob 与 Stream 的梦幻联动

当文件超大（GB 级）时，全部读进内存并不现实。可以借助 ReadableStream 把 Blob 转为流，实现渐进式上传：

const stream = blob.stream(); // 返回 ReadableStream

await fetch('/upload', {

  method: 'POST',

  body: stream,

  headers: { 'Content-Type': blob.type }

});

Chrome 85+、Edge 85+、Firefox 已经支持 blob.stream()，能以流式形式边读边传，内存占用极低。

八、总结：记住“三句话”

用好 Blob，既能提升用户体验（秒开预览），又能降低服务端压力（无需中转），是每一位前端工程师的必备技能。

大家好，我是程序员鱼皮。

前两天，前特斯拉 AI 总监 Andrej Karpathy 在 X 上发了一条长帖子，内容是他最近几周大量使用 Claude 编程的感悟。

结果这条帖子直接爆了，阅读量超过 600 万。

先简单介绍一下『卡帕西』这位大佬：斯坦福 AI 博士，师从李飞飞；OpenAI 创始成员之一；后来去特斯拉当了 AI 总监，负责自动驾驶的视觉系统。2024 年离开特斯拉后，他创办了 Eureka Labs，专注用 AI 做教育。

不夸张地说，他可能是全球最懂 AI、又最能写代码的人之一。

在 2023 年 1 月的时候，他就提出过：未来最热门的新编程语言是自然语言。

你现在回过头来看这句话，就知道这哥们有多牛皮了。

所以我每次看他分享的内容时，都会先沐浴更衣，让自己能够进入深度思考状态。

进入正题，这条帖子里有很多干货，但让我印象最深的是这句话：

我不太清楚如何衡量 AI 带来的加速。我感觉做事确实快了，但主要的效果是我做的比原计划多得多。

卡帕西说，现在他可以随手写一些以前 “不值得写” 的小工具，也敢去碰以前因为技术栈不熟而不敢碰的代码了。

所以 AI 编程带来的核心变化不是加速，而是扩展。

我觉得这个观察太准了！

之前很多人问我：AI 编程能提效多少倍？

其实这个问题本身就问错了。AI 带来的真正变化不是 “同一件事做得更快”，而是 “你开始做以前根本不会做的事”。

这就像你以前骑自行车，现在换了辆车。你不会说自己骑车快了 10 倍，而是会说自己能去更远的地方了。

人比不过 AI 的一点

帖子里还有几个点挺有意思的，跟大家分享一下。

卡帕西说，看 AI 在一个 Bug 上死磕 30 分钟，不放弃、不气馁，最后真的搞定了 —— 这是他感受 AGI 的时刻。

我看到这段就想起自己大学刚学编程时改 Bug 的经历。已经是凌晨一两点，试了好几种方法都没用，我的心态已经崩了，甚至有点儿心绞痛，于是想着明天再说吧，狗命要紧……

但 AI 不会这样，只要你的 Tokens 足够，它会一直跟 Bug 死磕。

耐力这件事，正在从人类的瓶颈变成 AI 的优势。

当然，代价就是烧 Token。所以程序员的基本功还是很重要的，至少你得能判断这个 Bug 值不值得让 AI 花半小时去磕，怎么通过指引 AI 让它更快更省地解决问题。

编程变得更有趣了？

卡帕西说：用 AI 编程之后，那些填空式的苦差事没了，剩下的都是创造性的部分。所以反而觉得更好玩了。

但他也提到，有些程序员会觉得失去了乐趣。因为对他们来说，写代码本身就是快感来源。

这可能是一个分水岭：主要享受 “写代码” 的人，和主要享受 “造东西” 的人，体验会很不一样。

我看到一位 AI 圈的大 V 把这点称为 “程序员正在分裂成两个物种”。不过我倒觉得，这两类人其实一直都存在。有的人享受代码本身的优雅，追求技术的深度和细节，写出漂亮的代码会有成就感；有的人更在乎东西能不能跑起来、能不能解决问题，代码只是实现想法的工具。AI 只是把这个差异放大了而已 —— 前者可能会有点失落，后者则迎来了黄金时代。

我正在失去写代码的能力，但是…

卡帕西说：自己手动写代码的能力正在慢慢退化。

但是从他的话中能感受到，他对此的态度是 “已经不太在乎了”。

他给了一个有意思的视角，写代码（生成）和读代码（判别）是大脑里不同的能力。就像你可能写不出一首好诗，但能看出一首诗写得好不好。

编程也是一样。其实想想看，以前没有 AI 的时候，那些语法细节、API 用法，我们不也是靠查文档、利用编辑器的提示吗？真正需要记在脑子里的从来就不多。现在 AI 把这部分接管了，但代码的设计思路对不对、架构合不合理，还是得靠你自己判断。

所以未来程序员的角色，可能更像是 “技术导演” 而不是 “码农”。你负责把控方向、做出决策，AI 负责执行细节、填补空白。

2026 年垃圾内容会爆发，但是…

卡帕西还提到了一个词：Slopacolypse

我搜了一下，发现这其实是最近 AI 圈流行起来的一个 “slop 系列” 造词。Slop 指的是那些用 AI 批量生成的低质量内容，Slopacolypse 就是 Slop + Apocalypse，我理解是 “垃圾内容末日” 的意思。

他预测 2026 年，GitHub、各种社交媒体都会被 AI 生成的低质量内容淹没。当生产内容的门槛大幅降低，注意力反而会变得更稀缺。

但他也说，真正的改进也在同步发生。AI 的智能部分已经跑在前面了，现在反而是工具、流程、组织这些东西还没跟上。2026 年，整个行业会花大量精力去消化这波新能力。

说到这里，我想起自己身边的情况。AI 领域几乎每天都有新工具、新模型、新玩法冒出来，但真正意识到这些变化、真正去用这些新东西的人，又有多少呢？

我经常听到有人说 “再等几个月，等出了更好的再学”、“现在的还不够成熟”。但问题是，在你等待的这几个月里，已经有人用 AI 做出了以前做不到的东西，拉开了差距。

所以对于我们程序员来说，一方面必须要利用 AI 提升开发效率和优化工作流程。

另外一方面，不妨打开思路，多想一想：有了 AI，你能做到哪些以前做不到的事？

以前不敢碰的技术栈，现在敢试了；以前觉得不值得做的小工具，现在随手就能搞定；以前卡住就放弃的 bug，现在有个不知疲倦的助手帮你死磕。

这才是 AI 编程真正的红利 —— 不是让你更快，是让你更大。

如果你还没开始用 AI 编程，或者想系统学习怎么用的更好，可以看看我最新免费开源的 《AI 编程零基础入门教程》，从 0 开始带你用 AI 编程做出项目，包含各种工具用法、实战技巧、编程资源、甚至是产品变现经验全都有。希望能帮你更快地拥抱这个新时代，一起变得更大、更强！

更多

💻 编程学习交流：编程导航

📃 简历快速制作：老鱼简历

✏️ 面试刷题神器：面试鸭

📖 AI 学习指南：鱼皮 AI 导航

翻译：2026年了，直接用 PostgreSQL 吧

以下是 It’s 2026, Just Use Postgres | Tiger Data 的中文翻译

把你的数据库想象成你的家。家里有客厅、卧室、浴室、厨房和车库，每个房间用途不同，但都在同一屋檐下，由走廊和门相连。你不会因为需要做饭就单独盖一栋餐厅大楼，也不会为了停车而在城外另建一座商业车库。

PostgreSQL 就是这样的“家”——一个屋檐下容纳多个功能房间：搜索、向量、时序数据、队列……全部一体化。

而这恰恰是那些专用数据库厂商不愿让你知道的真相。他们的营销团队花了数年时间说服你“为不同任务选用合适的工具”。听起来很合理，很睿智，也确实卖出了大量数据库。

让我告诉你为什么这是个陷阱，以及为什么在 99% 的场景下，PostgreSQL 才是更优解。

“选用合适工具”的陷阱

你一定听过这样的建议：“为不同任务选用合适的工具。”

听起来很睿智。于是你最终拥有了：

恭喜你，现在你需要管理七个数据库。学习七种查询语言，维护七套备份策略，审计七种安全模型，轮换六组凭证，监控七个仪表盘，以及应对七个可能在凌晨三点崩溃的系统。

而当系统真的崩溃时？祝你好运——你得搭建一个包含全部七种数据库的测试环境来调试问题。

换个思路：直接用 PostgreSQL 吧。

为什么现在尤其重要：AI 时代

这不只是关于简化架构。AI 智能体已让数据库碎片化成为一场噩梦。

想想智能体需要做什么：

• 快速用生产数据搭建测试数据库


• 尝试修复或实验


• 验证效果


• 销毁环境

使用单一数据库？一条命令即可：Fork、测试、完成。

使用七个数据库？你需要：

• 协调 PostgreSQL、Elasticsearch、Pinecone、Redis、MongoDB 和 Kafka 的快照


• 确保所有数据处于同一时间点


• 启动七种不同服务


• 配置七组连接字符串


• 祈祷测试过程中数据不发生漂移


• 测试结束后销毁七种服务

没有大量研发投入，这几乎不可能实现。

这还不只是智能体的问题。每次凌晨三点系统崩溃，你都需要搭建测试环境调试。六个数据库意味着协调噩梦；一个数据库，只需一条命令。

在 AI 时代，简洁不只是优雅，更是必需。

“但专用数据库性能更好啊！”

我们直面这个问题。

迷思：专用数据库在其特定任务上远超通用方案。

现实：它们可能在狭窄场景下略占优势，但同时引入了不必要的复杂性。这就像为每顿饭都雇佣一位私人厨师——听起来奢华，实则增加成本、协调开销，并制造了本不存在的问题。

关键在于：99% 的公司根本不需要它们。那 1% 的顶级公司拥有数千万用户和与之匹配的庞大工程团队。你读过他们吹捧“专用数据库 X 如何惊艳”的博客，但那是他们的规模、他们的团队、他们的问题。对其他人而言，PostgreSQL 完全够用。

大多数人没意识到的是：PostgreSQL 扩展使用的算法与专用数据库相同甚至更优（很多情况下确实如此）。

所谓“专用数据库溢价”？大多是营销话术。

这些不是缩水版实现，而是相同/更优的算法，经过实战检验、开源，并常由相同研究者开发。

基准测试也证实了这一点：

• pgvectorscale：延迟比 Pinecone 低 28 倍，成本降低 75%


• TimescaleDB：性能媲美或超越 InfluxDB，同时提供完整 SQL 支持


• pg_textsearch：与 Elasticsearch 相同的 BM25 排序算法

隐性成本不断累积

除 AI/智能体问题外，数据库碎片化还带来复合成本：

认知负荷：团队需掌握 SQL、Redis 命令、Elasticsearch Query DSL、MongoDB 聚合、Kafka 模式、InfluxDB 的非原生 SQL 变通方案。这不是专业化，这是碎片化。

数据一致性：保持 Elasticsearch 与 PostgreSQL 同步？你需要构建同步作业。它们会失败，数据会漂移，你得添加对账逻辑。对账也会失败。最终你维护的是基础设施，而非产品功能。

SLA 数学：三个系统各自 99.9% 可用性 = 整体 99.7%。这意味着每年26 小时停机时间，而非 8.7 小时。每个系统都在成倍增加故障模式。

现代 PostgreSQL 技术栈

这些扩展并非新生事物，它们已生产就绪多年：

• PostGIS：自 2001 年（24 年），支撑 OpenStreetMap 和 Uber


• 全文搜索：自 2008 年（17 年），内置于 PostgreSQL 核心


• JSONB：自 2014 年（11 年），性能媲美 MongoDB 且支持 ACID


• TimescaleDB：自 2017 年（8 年），GitHub 超 2.1 万星


• pgvector：自 2021 年（4 年），GitHub 超 1.9 万星

超过 48,000 家公司使用 PostgreSQL，包括 Netflix、Spotify、Uber、Reddit、Instagram 和 Discord。

AI 时代的新一代扩展

这意味着什么：过去构建 RAG 应用需要 PostgreSQL + Pinecone + Elasticsearch + 胶水代码。

现在？只需 PostgreSQL。一个数据库，一种查询语言，一套备份方案，一条 Fork 命令即可让 AI 智能体搭建测试环境。

快速上手：启用这些扩展

只需执行以下命令：

-- 全文搜索（BM25）

CREATE EXTENSION pg_textsearch;



-- 向量检索（AI 场景）

CREATE EXTENSION vector;

CREATE EXTENSION vectorscale;



-- AI 嵌入与 RAG 工作流

CREATE EXTENSION ai;



-- 时序数据

CREATE EXTENSION timescaledb;



-- 消息队列

CREATE EXTENSION pgmq;



-- 定时任务

CREATE EXTENSION pg_cron;



-- 地理空间

CREATE EXTENSION postgis;

就是这么简单。

代码示例

以下是各场景的可运行示例，按需查阅。

全文搜索（替代 Elasticsearch）

扩展：pg_textsearch（真正的 BM25 排序）

替代对象：

• Elasticsearch：独立 JVM 集群、复杂映射、同步流水线、Java 堆调优


• Solr：类似问题，仅包装不同


• Algolia：$1/1000 次搜索，依赖外部 API

你将获得：与 Elasticsearch 完全相同的 BM25 算法，直接内置于 PostgreSQL。

-- 创建表

CREATE TABLE articles (

  id SERIAL PRIMARY KEY,

  title TEXT,

  content TEXT

);



-- 创建 BM25 索引

CREATE INDEX idx_articles_bm25 ON articles USING bm25(content)

  WITH (text_config = 'english');



-- 基于 BM25 评分搜索

SELECT title, -(content <@> 'database optimization') as score

FROM articles

ORDER BY content <@> 'database optimization'

LIMIT 10;

混合搜索：BM25 + 向量一体化查询

SELECT 

  title,

  -(content <@> 'database optimization') as bm25_score,

  embedding <=> query_embedding as vector_distance,

  0.7 * (-(content <@> 'database optimization')) + 

  0.3 * (1 - (embedding <=> query_embedding)) as hybrid_score

FROM articles

ORDER BY hybrid_score DESC

LIMIT 10;

Elasticsearch 需要额外插件才能实现的功能，在 PostgreSQL 中只需一条 SQL。

向量检索（替代 Pinecone）

扩展：pgvector + pgvectorscale

替代对象：

• Pinecone：$70/月起步，独立基础设施，数据同步头痛


• Qdrant, Milvus, Weaviate：更多需管理的基础设施

你将获得：pgvectorscale 采用微软研究院的 DiskANN 算法，在 99% 召回率下实现延迟降低 28 倍、吞吐量提升 16 倍。

-- 启用扩展

CREATE EXTENSION vector;

CREATE EXTENSION vectorscale CASCADE;



-- 含嵌入向量的表

CREATE TABLE documents (

  id SERIAL PRIMARY KEY,

  content TEXT,

  embedding vector(1536)

);



-- 高性能索引（DiskANN）

CREATE INDEX idx_docs_embedding ON documents USING diskann(embedding);



-- 查找相似文档

SELECT content, embedding <=> '[0.1, 0.2, ...]'::vector as distance

FROM documents

ORDER BY embedding <=> '[0.1, 0.2, ...]'::vector

LIMIT 10;

通过 pgai 自动同步嵌入向量：

SELECT ai.create_vectorizer(

  'documents'::regclass,

  loading => ai.loading_column(column_name=>'content'),

  embedding => ai.embedding_openai(model=>'text-embedding-3-small', dimensions=>'1536')

);

现在每次 INSERT/UPDATE 都会自动重新生成嵌入向量。无需同步作业，无数据漂移，告别凌晨三点的告警电话。

时序数据（替代 InfluxDB）

扩展：TimescaleDB（GitHub 2.1 万+ 星）

替代对象：

• InfluxDB：独立数据库、Flux 查询语言或非原生 SQL


• Prometheus：适用于指标，不适用于应用数据

你将获得：自动时间分区、最高 90% 压缩率、连续聚合，完整 SQL 支持。

-- 启用 TimescaleDB

CREATE EXTENSION timescaledb;



-- 创建表

CREATE TABLE metrics (

  time TIMESTAMPTZ NOT NULL,

  device_id TEXT,

  temperature DOUBLE PRECISION

);



-- 转换为超表

SELECT create_hypertable('metrics', 'time');



-- 按时间桶查询

SELECT time_bucket('1 hour', time) as hour,

       AVG(temperature)

FROM metrics

WHERE time > NOW() - INTERVAL '24 hours'

GR0UP BY hour;



-- 自动删除旧数据

SELECT add_retention_policy('metrics', INTERVAL '30 days');



-- 压缩（存储减少 90%）

ALTER TABLE metrics SET (timescaledb.compress);

SELECT add_compression_policy('metrics', INTERVAL '7 days');

缓存（替代 Redis）

特性：UNLOGGED 表 + JSONB

-- UNLOGGED = 无 WAL 开销，写入更快

CREATE UNLOGGED TABLE cache (

  key TEXT PRIMARY KEY,

  value JSONB,

  expires_at TIMESTAMPTZ

);



-- 设置带过期时间的缓存

INSERT INTO cache (key, value, expires_at)

VALUES ('user:123', '{"name": "Alice"}', NOW() + INTERVAL '1 hour')

ON CONFLICT (key) DO UPDATE SET value = EXCLUDED.value;



-- 读取

SELECT value FROM cache WHERE key = 'user:123' AND expires_at > NOW();



-- 清理（通过 pg_cron 定时）

DELETE FROM cache WHERE expires_at < NOW();

消息队列（替代 Kafka）

扩展：pgmq

CREATE EXTENSION pgmq;

SELECT pgmq.create('my_queue');



-- 发送消息

SELECT pgmq.send('my_queue', '{"event": "signup", "user_id": 123}');



-- 接收消息（带可见性超时）

SELECT * FROM pgmq.read('my_queue', 30, 5);



-- 处理完成后删除

SELECT pgmq.delete('my_queue', msg_id);

或使用原生 SKIP LOCKED 模式：

CREATE TABLE jobs (

  id SERIAL PRIMARY KEY,

  payload JSONB,

  status TEXT DEFAULT 'pending'

);



-- Worker 原子性认领任务

UPDATE jobs SET status = 'processing'

WHERE id = (

  SELECT id FROM jobs WHERE status = 'pending'

  FOR UPDATE SKIP LOCKED LIMIT 1

) RETURNING *;

文档存储（替代 MongoDB）

特性：原生 JSONB

CREATE TABLE users (

  id SERIAL PRIMARY KEY,

  data JSONB

);



-- 插入嵌套文档

INSERT INTO users (data) VALUES ('{

  "name": "Alice",

  "profile": {"bio": "Developer", "links": ["github.com/alice"]}

}');



-- 查询嵌套字段

SELECT data->>'name', data->'profile'->>'bio'

FROM users

WHERE data->'profile'->>'bio' LIKE '%Developer%';



-- 为 JSON 字段创建索引

CREATE INDEX idx_users_email ON users ((data->>'email'));

地理空间（替代专用 GIS）

扩展：PostGIS

CREATE EXTENSION postgis;



CREATE TABLE stores (

  id SERIAL PRIMARY KEY,

  name TEXT,

  location GEOGRAPHY(POINT, 4326)

);



-- 查找 5 公里内的门店

SELECT name, ST_Distance(location, ST_MakePoint(-122.4, 37.78)::geography) as meters

FROM stores

WHERE ST_DWithin(location, ST_MakePoint(-122.4, 37.78)::geography, 5000);

定时任务（替代 Cron）

扩展：pg_cron

CREATE EXTENSION pg_cron;



-- 每小时执行

SELECT cron.schedule('cleanup', '0 * * * *', 

  $$DELETE FROM cache WHERE expires_at < NOW()$$);



-- 每日凌晨 2 点汇总

SELECT cron.schedule('rollup', '0 2 * * *',

  $$REFRESH MATERIALIZED VIEW CONCURRENTLY daily_stats$$);

核心结论

回到“家”的比喻：你不会为做晚饭单独盖餐厅，也不会为停车在城外建车库。你会使用家中已有的房间。

这正是我们在此展示的：搜索、向量、时序、文档、队列、缓存……它们都是 PostgreSQL 这座“家”中的不同房间。使用与专用数据库相同的算法，历经多年实战检验，被 Netflix、Uber、Discord 及 48,000 多家公司采用。

那么那 1% 的例外呢？

99% 的公司，PostgreSQL 足以应对所有需求。那 1%？当你需要跨数百节点处理 PB 级日志，或必须使用 Kibana 特定仪表盘，或拥有 PostgreSQL 确实无法满足的特殊需求时。

但关键在于：当你属于那 1% 时，你自己会知道。你不需要厂商营销团队告诉你，你会通过基准测试亲自撞上真正的性能墙。

在此之前，不要因为“为不同任务选用合适工具”这句话，就把数据分散到七栋大楼中。那句建议卖出了数据库，却没为你服务。

从 PostgreSQL 开始，坚持使用 PostgreSQL。仅在真正需要时才增加复杂性。

2026 年了，直接用 PostgreSQL 吧。

立即开始

所有这些扩展在 Tiger Data 上均可使用。几分钟内创建免费数据库：

psql "postgresql://user:pass@your-instance.tsdb.cloud.timescale.com:5432/tsdb"

CREATE EXTENSION pg_textsearch;  -- BM25 搜索

CREATE EXTENSION vector;         -- 向量检索

无需专用数据库，只需 PostgreSQL。

延伸阅读

• pg_textsearch 文档


• pgvector GitHub


• pgvectorscale 文档


• TimescaleDB 文档


• pgmq 消息队列


• PostGIS 地理空间

兄弟们，咱们的护城河越来越窄了😭

Gemini 3 的发布会，大家看了没？

我是在被窝里看完的。看完之后，我直接失眠了。

以前我觉得 AI 写代码也就那样，写个 Todo List 还行，真要上业务逻辑，它就得幻觉给你看😒。

但 Google 秀的这一手，真的有点不讲武德。

我出于好奇心，用 Google Al Studio 试了一下几个经典的需求, 直接把飞书需求文档扔给它（纯文案）👇：

Recall landing page

1. 页脚的recalls跳转新的recall landing page

[图片]

2. 页面内容

标题：Product Recalls



两个内容模块，点击后跳转至各自详情页

第一个：

2025 Fat Tire Trike Recall Notice

Pedego has issued a safety recall for Fat Tire Trikes due to a potential frame fracture near a weld that may pose fall or injury risks. Affected owners are eligible for a free repair, completed by a local Pedego dealer.

Learn more （可点击，跳转至Fat Tire Trike Recall Page）



第二个：

2021 Cable Recall Notice

Pedego is voluntarily recalling select e-bike models sold from January 2018 to August 2020 due to a cable issue that may cause unexpected acceleration. Affected owners should stop riding and register for a free safety repair.

Learn more（可点击，跳转至https://www.pedegobikerecall.expertinquiry.com/?_gl=1*1hzkwd0*_gcl_au*MTkxNDc4ODEuMTc2MzM0NDUyMA..*_ga*MTM1MzU3NTAzOC4xNzQ1OTE1NTcz*_ga_4K15HG6FFG*czE3NjQ4MzQ5MDAkbzQyJGcwJHQxNzY0ODM0OTAxJGo1OSRsMCRoMA..*_ga_FGPZTS4D91*czE3NjQ4MzQ5MDAkbzQyJGcwJHQxNzY0ODM0OTAxJGo1OSRsMCRoMA..）

[图片]







Fat Tire Trike Recall Page

标题：Pedego Recalls Fat Tire Trike Due to Fall and Laceration Hazards

[插入几张Fat Tire Trike图片]

 

页面主体内容

Name of Product: Pedego Fat Tire Trike

Hazard: The trike frame can develop a hairline fracture near a weld, which can cause the tube to break, posing fall and laceration hazards. 

Units Affected: Serial Number Range: D2312050001 - D2312050522 

 

按钮：REGISTER NOW （点击后跳转至页面下方注册表单）

  

How is Pedego making this right? 

Pedego is offering you a free repair of your Fat Tire Trike. We have reengineered and strengthened the section of the frame in question. Once you register, we will ship a repair part to a local Pedego dealer that you select using the registration form. 

We will ship the part to the dealer. The Pedego dealer will repair the Fat Tire Trike free of charge. There are no charges or fees associated with this recall. 

You will be contacted when your part is received at the Pedego store for installation.



Make sure that other members of your household also know about the recall and immediately stop using it. Secure your Fat Tire Trike so that it cannot be ridden until it is repaired.

We strongly encourage you to participate and contact us to obtain a free repair.

 

Register for the free repair of your Fat Tire Trike

First Name*

Last Name*

Email*

Phone number*

Dealer Where you’d like the repair to take place *  [Perhaps Preload options or provide location search for dealer（这里有没有可能提供选项让消费者选择？或者搜索地址？）]

State* 

Zip Code*

Country*

 

[] * I hereby affirm that the information I have provided is accurate and correct, and that I have complied with all requirements of the above-referenced recall for seeking a repair of my Fat Tire Trike.

 

 Submit(提交按钮)



成功提交后显示：

Thank you. Your registration has been submitted and is being processed. 

We will notify you when the parts ship to the dealer. The dealer will install and repair your Fat Tire Trike free of charge. 



[所提交信息在这里展示]

 

Please print this page for your records. 

我刚准备点根烟的工夫，页面 UI 就出来了👇。

不是那种满屏 div 的垃圾代码，是语义化极好、组件拆分合理、甚至连 dark mode 都给配好了的成品，根本不需要改什么😖。

我看着屏幕上自己刚写了一半、还在纠结 flex-basis 该给多少的样式文件，突然觉得：这几年的代码，好像白写了。

AI 虽然能秒出 UI，但要转变成可维护的工程资产，还得靠架构能力。试试 RollCode 低代码平台，用 私有化部署 承载核心业务，通过 自定义组件 封装复杂逻辑，配合 静态页面发布（SSG + SEO），让 AI 的产出真正落地。

我最新的 个人主页也是用 Gemini 3 重写的，这审美，这效率，没得说！太强了👏

切图仔的时代正式终结了

以前咱总开玩笑说自己是切图仔，其实心里还是有点傲气的： 你以为 CSS 容易啊？BFC、层叠上下文、响应式断点、不同内核的兼容性...这玩意儿水深着呢！

但 Gemini 3 这种级别的 AI 出来，直接把这层傲气给降维打击了。

• 比速度？ 你调一个布局要半小时，它只要 3 秒。


• 比审美？ 它学习了全球数亿个精美网页，配出的视觉UI 把你那程序员审美甩出几条街。


• 比稳定性？ 它不会写错单词，也不会漏写分号，更不会因为下午跟产品经理吵了架就故意在代码里埋坑。

说实话，在实现视觉稿这件事上，人类已经输了。彻底输了！！！😭

如果你的核心竞争力就是能把 UI 图 1:1 还原成网页，那你的职业生涯确实已经进入倒计时了。

既然 CSS 成了废话，那我们还剩什么？

既然 AI 能写出完美的 CSS，甚至连交互动画都能一句话生成，那公司凭啥还花几万块招个前端？

我想了半宿，觉得咱们前端老哥的保命牌，其实正在从手艺转向上层建筑：

培养自己的架构设计能力

AI 可以给你砌出一面完美的墙，但它不知道这面墙该立在什么位置。

一个大型项目里：

• 组件怎么拆分最利于复用？


• 目录结构怎么设计才不会让后来的人骂娘？


• 全局状态是用 Zustand 还是直接原生 Context 梭哈？

这些涉及到工程化决策的东西，AI 目前还是个弟弟。它只能给你局部的最优解，给不了你全局的架构观。

处理那些只有人能理解的业务

AI 最怕的是什么？是逻辑的混沌。

用户如果连续点击三次，要触发一个彩蛋，但如果他是 VIP 且余额不足，这个彩蛋要换成充值提醒，顺便还得防止接口重放。

这种只有人类产品经理拍脑袋想出来的、逻辑转了十八道弯的边缘 Case，AI 极其容易写出 Bug。

搞定复杂的异步流，搞定恶心的竞态条件，搞定各种各样的降级策略——这才是你领工资的真正理由。

驾驭 AI 的能力（这应该是 2026 年的高频面试题）

以前面试问：CSS 怎么实现三角形？

以后面试可能问：如何用一句 Prompt，让 Gemini 3 输出一个符合公司私有 UI 规范、且通过了 E2E 测试的复杂组件？

AI 不是你的敌人，它可是你的好伙伴。

别人还在用手敲代码时，你已经学会利用AI 提升工作效率。你的核心竞争力，就是你 调教 AI 的水平。

没必要焦虑，这是超级个体的开始

咱们有木有可能换一种思路🤔。

以前我们想做个自己的副业项目，最头疼的是什么？UI 和 CSS。

对于我们这种逻辑强、审美弱的后端型前端，调样式简直是要了亲命。

现在 Gemini 3 这种东西出来了，简直是送福利。

• 后端： 让 AI 帮你生成 Schema 和基础 CRUD。


• UI/CSS： 丢张草图给 Gemini 3。


• 前端框架： 让 AI 帮你写好骨架。

你一个人，就是一个超级个体。

以前我们需要在大厂里卷，是因为大厂有资源、有配套。

现在 AI 把资源门槛抹平了。在这个代码非常廉价的时代，你的创意、你的产品意识、你的解决问题能力，反而变得更值钱了。

Gemini 3 确实很猛，猛到让人怀疑人生，猛得一塌糊涂！😖

但我相信，只要互联网还需要服务，前端这个角色就不会消失。它只是从体力活进化成了脑力活。

别纠结那几个 margin 和 padding 了，去研究架构，去深挖性能，去学习怎么让 AI 给你当牛马。

只要你跑得比 AI 进化的速度快，你就不是被淘汰的那一个。

最后默默的问大家一句🤣：

如果明天你的老板让你裁掉团队一半的前端，只留下那些会用 AI 的，你会是在名单里的那个人吗？

欢迎👏顺便说说你被 Gemini 3 惊吓到的瞬间😁。

开源项目地址：github.com/MrMao007/re…

引言

在当今数字化时代，社交媒体平台如小红书已成为内容创作者和品牌推广的重要阵地。为了更高效地进行内容运营、数据分析和互动管理，我最近研究了一个名为 rednote-skills 的开源项目。这个项目提供了一套完整的工具集，能够实现对小红书平台的自动化交互，从搜索、内容提取到互动操作，功能十分全面。

本文将深入分析 rednote-skills 的架构设计、核心功能以及实现原理，希望能为对社交媒体自动化感兴趣的开发者提供参考。

项目概述

rednote-skills 是一个基于 Python 和 Playwright 的开源工具包，专门用于与小红书（xiaohongshu）平台进行自动化交互。它支持多种功能，包括：

• 笔记搜索：根据关键词搜索小红书笔记


• 内容提取：将指定笔记转换为结构化 Markdown 格式


• 互动操作：点赞、收藏、评论、关注等


• 内容发布：自动发布图文笔记

该项目最大的亮点是其作为 Claude Code 插件的能力，可以直接集成到 AI 开发环境中，让开发者通过自然语言指令来执行复杂的社交媒体操作。

技术架构分析

核心依赖

项目主要依赖于 Playwright 库，这是一个强大的浏览器自动化工具。通过模拟真实用户的浏览器行为，项目能够绕过小红书的一些反爬虫机制。

from playwright.sync_api import sync_playwright

Playwright 提供了同步和异步两种 API，项目采用了同步 API，使得代码逻辑更加清晰易懂。

认证机制

项目采用 Cookie-based 认证方式，将认证信息存储在 rednote_cookies.json 文件中：

try: 

    context = browser.new_context(storage_state="rednote_cookies.json")

except FileNotFoundError:

    return "❌ 未找到 cookies 文件，请先登录小红书并保存 cookies"

这种设计既保证了会话的持久性，又提供了手动登录的灵活性。validate_cookies.py 和 manual_login.py 脚本分别负责验证登录状态和处理手动登录流程。

浏览器管理

每个脚本都遵循相同的模式：启动浏览器 -> 加载上下文 -> 执行操作 -> 关闭资源：

with sync_playwright() as playwright:

    browser = playwright.chromium.launch(headless=False)

    context = browser.new_context(storage_state="rednote_cookies.json")

    page = context.new_page()

    # ... 执行具体操作 ...

    context.close()

    browser.close()

核心功能详解

1. 笔记搜索功能

search_note_by_key_word.py 实现了关键词搜索功能：

def search(key_word: str, top_n: int) -> list[str]:

    with sync_playwright() as playwright:

        browser =playwright.chromium.launch(headless=True)

        # ... 验证登录 ...

        page.goto("https://www.xiaohongshu.com/search_result?keyword=" + key_word)

        page.wait_for_timeout(3000)

        

        prefix = 'https://www.xiaohongshu.com'

        links = page.query_selector_all('a.cover.mask.ld')

        # 获取所有 href 属性

        hrefs = []

        for link in links:

            href = link.get_attribute('href')

            if href:

                href = prefix + href

                hrefs.append(href)

            if len(hrefs) >= top_n:

                break

        return hrefs

这个函数通过选择器 'a.cover.mask.ld' 来定位搜索结果中的笔记链接，并限制返回数量以提高效率。

2. 内容提取功能

dump_note.py 是项目中最复杂也是最有价值的功能之一。它不仅提取文本内容，还获取图片、视频、互动数据等：

note_data = page.evaluate("""

    () => {

        const noteDetailMap = window.__INITIAL_STATE__?.note?.noteDetailMap;

        if (noteDetailMap) {

            const firstKey = Object.keys(noteDetailMap)[0];

            return JSON.stringify(noteDetailMap[firstKey]?.note);

        }

        return null;

    }

""")

通过直接访问页面的 window.__INITIAL_STATE__ 变量，脚本能够获取到完整的笔记 JSON 数据，避免了复杂的 DOM 解析。

3. 互动操作实现

项目中的互动功能（点赞、收藏、评论、关注）实现思路相似，都是通过定位特定元素并触发点击事件：

# 点赞操作

page.locator(".left > .like-wrapper > .like-lottie").click()



# 收藏操作

page.locator(".reds-icon.collect-icon").click()



# 评论操作

page.locator(".chat-wrapper > .reds-icon").click()

page.locator("#content-textarea").fill(comment_text)

page.get_by_role("button", name="发送").click()

这些选择器是通过实际测试确定的，反映了小红书当前的 DOM 结构。

4. 内容发布功能

publish_note.py 实现了笔记发布的完整流程，这是整个项目最复杂的部分：

def publish_text(image_urls: List[str], title: str, content: str, tags: List[str]) -> str:

    # ... 初始化浏览器和验证登录 ...

    

    page.get_by_role("button", name="创作中心").hover()

    with page.expect_popup() as page1_info:

        page.get_by_role("link", name="创作服务").click()

        

    page1 = page1_info.value

    page1.get_by_text("发布图文笔记").click()

    

    # 处理文件上传

    page1.on("filechooser", lambda file_chooser: file_chooser.set_files(rednoteArticle.image_urls))

    

    # 填写表单内容

    page1.get_by_role("textbox", name="填写标题会有更多赞哦").fill(rednoteArticle.title)

    final_content = rednoteArticle.content + "\n\n" + "\n".join([f"#{tag}" for tag in rednoteArticle.tags])

    page1.get_by_role("paragraph").filter(has_text=re.compile(r"^$")).fill(final_content)

    

    # 最终发布

    page1.get_by_role("button", name="发布").click()

发布功能需要处理多步骤导航、文件上传、表单填写等多个复杂操作。

设计模式与最佳实践

统一的错误处理

每个脚本都实现了统一的错误处理逻辑，检查登录状态并返回相应的错误信息：

login_button = page.locator("form").get_by_role("button", name="登录")

if(login_button.is_visible()):

    return "❌ 未登录小红书，请先登录"

模块化设计

项目将不同功能分解为独立的 Python 脚本，每个脚本都可以独立运行，同时也便于集成到更大的系统中。

命令行接口

所有脚本都提供了清晰的命令行接口，使用 argparse 进行参数解析，方便在各种环境下调用。

使用场景与价值

1. 内容运营自动化

对于内容运营人员来说，这个工具可以显著提升工作效率：

• 自动搜索相关话题的内容


• 批量收集竞品账号的数据


• 自动发布内容减少重复劳动

2. 数据分析与研究

研究人员可以利用这个工具收集小红书上的公开数据，用于：

• 社交媒体趋势分析


• 用户行为研究


• 文本情感分析

3. AI 辅助创作

结合 Claude Code 等 AI 平台，开发者可以通过自然语言指令控制小红书操作，实现智能化的内容管理和互动。

注意事项与建议

合规性考虑

在使用这类工具时，必须严格遵守小红书的使用条款和服务协议，避免：

• 频繁操作导致账号受限


• 发布违规内容


• 侵犯他人隐私权

性能优化

由于依赖浏览器自动化，项目在性能方面有一些局限性：

• 操作速度相对较慢


• 占用较多系统资源


• 可能受网络状况影响

维护成本

小红书平台界面可能会更新，这要求定期维护选择器和操作流程，确保工具持续可用。

总结

rednote-skills 是一个功能强大且设计良好的小红书自动化工具集。它通过 Playwright 实现了对小红书平台的全面自动化操作，为内容运营、数据分析等场景提供了便利。

项目的架构设计合理，模块化程度高，易于扩展和维护。虽然存在一些性能和合规性方面的考虑，但其价值仍然不容忽视。

对于希望深入了解浏览器自动化、社交媒体 API 模拟或 AI 辅助开发的开发者来说，这个项目是一个很好的学习案例。它展示了如何将复杂的网页交互封装成简单易用的命令行工具，值得我们深入研究和借鉴。

大家好，我是小悟。

一、什么是接口防抖？（又名：救救那个手抖的程序员）

想象一下这个场景：用户小张在提交订单时，因为网络延迟，他以为没点中那个“提交”按钮，于是疯狂连击了10次！结果...10个一模一样的订单诞生了！

接口防抖 就像是给按钮加上了一层“冷静期”——“兄弟，你点太快了，先冷静3秒再说！”

防止重复提交 则是更严格的保安大哥——“同样的身-份-证（请求）只能进一次，想蒙混过关？没门！”

下面我来教你在SpringBoot中布下天罗地网，拦截这些“手抖攻击”！

二、实战方案大集合

方案1：前端防抖 + 后端令牌锁（双保险）

前端防抖代码（JavaScript版）：

// 给按钮加个“冷静debuff”

let isSubmitting = false;



function submitOrder() {

    if (isSubmitting) {

        alert("客官您点得太快了，喝口茶歇歇~");

        return;

    }

    

    isSubmitting = true;

    // 提交请求...

    

    // 3秒后才能再次点击

    setTimeout(() => {

        isSubmitting = false;

    }, 3000);

}

后端令牌锁实现：

步骤1：创建防抖注解

@Target(ElementType.METHOD)

@Retention(RetentionPolicy.RUNTIME)

public @interface PreventDuplicateSubmit {

    /**

     * 防抖时间（秒），默认3秒

     */

    int lockTime() default 3;

    

    /**

     * 锁的key，支持SpEL表达式

     */

    String key() default "";

    

    /**

     * 提示信息

     */

    String message() default "请勿重复提交";

}

步骤2：实现AOP切面

@Aspect

@Component

@Slf4j

public class DuplicateSubmitAspect {

    

    @Autowired

    private RedisTemplate<String, Object> redisTemplate;

    

    @Autowired

    private HttpServletRequest request;

    

    @Pointcut("@annotation(preventDuplicateSubmit)")

    public void pointcut(PreventDuplicateSubmit preventDuplicateSubmit) {

    }

    

    @Around("pointcut(preventDuplicateSubmit)")

    public Object around(ProceedingJoinPoint joinPoint, 

                        PreventDuplicateSubmit preventDuplicateSubmit) throws Throwable {

        

        // 1. 构造锁的key

        String lockKey = buildLockKey(joinPoint, preventDuplicateSubmit);

        

        // 2. 尝试加锁（setnx操作）

        Boolean success = redisTemplate.opsForValue()

                .setIfAbsent(lockKey, "LOCKED", 

                           preventDuplicateSubmit.lockTime(), TimeUnit.SECONDS);

        

        if (Boolean.TRUE.equals(success)) {

            // 加锁成功，执行方法

            try {

                return joinPoint.proceed();

            } finally {

                // 可以根据业务决定是否立即删除锁

                // redisTemplate.delete(lockKey);

            }

        } else {

            // 加锁失败，说明重复提交了

            throw new RuntimeException(preventDuplicateSubmit.message());

        }

    }

    

    private String buildLockKey(ProceedingJoinPoint joinPoint, 

                               PreventDuplicateSubmit annotation) {

        StringBuilder keyBuilder = new StringBuilder("SUBMIT:LOCK:");

        

        // 如果有自定义key

        if (StringUtils.isNotBlank(annotation.key())) {

            keyBuilder.append(parseKey(joinPoint, annotation.key()));

        } else {

            // 默认使用：方法名 + 用户ID + 参数hash

            keyBuilder.append(joinPoint.getSignature().toShortString());

            

            // 加上用户ID（如果有登录）

            String userId = getCurrentUserId();

            if (userId != null) {

                keyBuilder.append(":").append(userId);

            }

            

            // 加上参数摘要

            Object[] args = joinPoint.getArgs();

            if (args.length > 0) {

                String argsHash = DigestUtils.md5DigestAsHex(

                    Arrays.deepToString(args).getBytes()

                ).substring(0, 8);

                keyBuilder.append(":").append(argsHash);

            }

        }

        

        return keyBuilder.toString();

    }

    

    private String getCurrentUserId() {

        // 从Token或Session中获取用户ID

        // 这里简化处理

        return (String) request.getSession().getAttribute("userId");

    }

}

步骤3：使用示例

@RestController

@RequestMapping("/order")

public class OrderController {

    

    @PostMapping("/create")

    @PreventDuplicateSubmit(lockTime = 5, message = "订单正在处理中，请勿重复提交")

    public ApiResult createOrder(@RequestBody OrderDTO orderDTO) {

        // 业务逻辑

        orderService.create(orderDTO);

        return ApiResult.success("下单成功");

    }

    

    @PostMapping("/pay")

    @PreventDuplicateSubmit(

        key = "'PAY:' + #orderNo + ':' + T(com.example.util.UserUtil).getCurrentUserId()",

        lockTime = 10,

        message = "支付请求已提交，请勿重复操作"

    )

    public ApiResult payOrder(String orderNo) {

        // 支付逻辑

        return ApiResult.success("支付成功");

    }

}

方案2：数据库唯一约束（最硬核的方案）

有时候，最简单的最有效！

@Entity

@Table(name = "orders")

public class Order {

    @Id

    @GeneratedValue(strategy = GenerationType.IDENTITY)

    private Long id;

    

    // 业务唯一号：时间戳 + 用户ID + 随机数

    @Column(name = "order_no", unique = true, nullable = false)

    private String orderNo;

    

    // 或者使用请求ID作为防重

    @Column(name = "request_id", unique = true)

    private String requestId;

    

    // ...其他字段

}



@Service

@Slf4j

public class OrderService {

    

    @Transactional(rollbackFor = Exception.class)

    public void createOrder(OrderDTO dto) {

        // 生成唯一请求ID（前端传递或后端生成）

        String requestId = dto.getRequestId();

        if (StringUtils.isBlank(requestId)) {

            requestId = UUID.randomUUID().toString();

        }

        

        // 检查是否已处理过该请求

        if (orderRepository.existsByRequestId(requestId)) {

            log.warn("重复请求被拦截：{}", requestId);

            throw new BusinessException("订单已提交，请勿重复操作");

        }

        

        // 创建订单

        Order order = new Order();

        order.setRequestId(requestId);

        order.setOrderNo(generateOrderNo());

        // ...设置其他字段

        

        try {

            orderRepository.save(order);

        } catch (DataIntegrityViolationException e) {

            // 捕获唯一约束异常

            throw new BusinessException("订单已存在，请勿重复提交");

        }

    }

}

方案3：本地Guava缓存（轻量级方案）

适合单机部署，简单快捷！

@Component

public class LocalDuplicateChecker {

    

    // Guava缓存，3秒自动过期

    private final Cache<String, Boolean> submitCache = CacheBuilder.newBuilder()

            .expireAfterWrite(3, TimeUnit.SECONDS)

            .maximumSize(10000)

            .build();

    

    /**

     * 检查是否重复提交

     * @param key 请求唯一标识

     * @return true=重复提交, false=首次提交

     */

    public boolean isDuplicate(String key) {

        try {

            // 如果key不存在，则放入缓存并返回null

            // 如果key存在，则返回缓存的值

            return submitCache.get(key, () -> {

                // 这个lambda只在key不存在时执行

                return false;

            });

        } catch (ExecutionException e) {

            return true;

        }

    }

    

    /**

     * 手动放入缓存（用于防止并发时多次通过检查）

     */

    public void markAsSubmitted(String key) {

        submitCache.put(key, true);

    }

}



// 使用方式

@RestController

public class ApiController {

    

    @Autowired

    private LocalDuplicateChecker duplicateChecker;

    

    @PostMapping("/api/submit")

    public ApiResult submitData(@RequestBody SubmitData data, 

                               HttpServletRequest request) {

        

        // 构造唯一key：IP + 用户ID + 数据摘要

        String clientIp = request.getRemoteAddr();

        String userId = getCurrentUserId();

        String dataHash = DigestUtils.md5DigestAsHex(

            JSON.toJSONString(data).getBytes()

        ).substring(0, 8);

        

        String lockKey = String.format("SUBMIT:%s:%s:%s", 

                                      clientIp, userId, dataHash);

        

        if (duplicateChecker.isDuplicate(lockKey)) {

            return ApiResult.error("请勿重复提交");

        }

        

        // 标记为已提交

        duplicateChecker.markAsSubmitted(lockKey);

        

        // 执行业务逻辑

        return processData(data);

    }

}

方案4：Token令牌机制（最经典的方案）

这个方案就像发门票，一张票只能进一个人！

步骤1：生成Token

@RestController

public class TokenController {

    

    @GetMapping("/api/getToken")

    public ApiResult getToken() {

        String token = UUID.randomUUID().toString();

        

        // 存入Redis，有效期5分钟

        redisTemplate.opsForValue().set(

            "SUBMIT_TOKEN:" + token, 

            "VALID", 

            5, TimeUnit.MINUTES

        );

        

        return ApiResult.success(token);

    }

}

步骤2：验证Token

@Aspect

@Component

public class TokenCheckAspect {

    

    @Pointcut("@annotation(needTokenCheck)")

    public void pointcut(NeedTokenCheck needTokenCheck) {

    }

    

    @Around("pointcut(needTokenCheck)")

    public Object checkToken(ProceedingJoinPoint joinPoint, 

                            NeedTokenCheck needTokenCheck) throws Throwable {

        

        HttpServletRequest request = ((ServletRequestAttributes) 

            RequestContextHolder.getRequestAttributes()).getRequest();

        

        String token = request.getHeader("X-Submit-Token");

        if (StringUtils.isBlank(token)) {

            throw new RuntimeException("提交令牌缺失");

        }

        

        String redisKey = "SUBMIT_TOKEN:" + token;

        String value = (String) redisTemplate.opsForValue().get(redisKey);

        

        if (!"VALID".equals(value)) {

            throw new RuntimeException("无效的提交令牌");

        }

        

        // 删除令牌（一次性使用）

        redisTemplate.delete(redisKey);

        

        return joinPoint.proceed();

    }

}

步骤3：前端配合

// 提交前先获取令牌

async function submitWithToken(data) {

    // 1. 获取令牌

    const token = await fetch('/api/getToken').then(r => r.json());

    

    // 2. 携带令牌提交

    const result = await fetch('/api/submit', {

        method: 'POST',

        headers: {

            'Content-Type': 'application/json',

            'X-Submit-Token': token

        },

        body: JSON.stringify(data)

    });

    

    return result;

}

三、方案对比总结

四、防抖策略选择指南

五、最后

防抖的目的不是为难用户，而是保护系统和数据的安全。就像给你的接口穿上防弹衣，既能抵挡"手抖攻击"，又能让正常请求畅通无阻！

程序员防抖口诀：

前端防抖先出手，后端加锁不能少。

令牌机制来帮忙，唯一约束最可靠。

根据场景选方案，系统稳定没烦恼。

用户手抖不可怕，我有妙招来护驾！

谢谢你看我的文章，既然看到这里了，如果觉得不错，随手点个赞、转发、在看三连吧，感谢感谢。那我们，下次再见。

您的一键三连，是我更新的最大动力，谢谢

山水有相逢，来日皆可期，谢谢阅读，我们再会

我手中的金箍棒，上能通天，下能探海

很多 Java 程序员一听到“对接第三方接口”，脑子里就自动响起一句话： “这不就是调个接口嘛，没技术含量。”

但真相是：你以为是体力活的地方，往往最能看出一个工程师的“技术深度”。

那些把接口对接写成“定时炸弹”的代码，和能扛住三年高并发零故障的实现，差的从来不是会不会发 HTTP 请求。

一、真正的高手，不是“调通接口”，而是“设计边界”

对接第三方接口，看似只是发个请求、拿个 JSON，但背后其实是——系统边界的协作与防御设计。

你面对的不是自己可控的代码，而是一个随时可能“变脸”的外部世界：

• 对方文档写着“此字段必传”，实际却返回 null


• 测试环境响应毫秒级，生产环境突然超时 30 秒


• 接口突然升级，字段名从 camelCase 改成 snake_case


• 流量峰值时，对方悄悄给你限流却不通知

所以高手不会只想着“调通”，而是从第一天就思考：

• 超时如何设置才不会拖垮自己的线程池？


• 对方返回非预期格式时，如何避免解析崩溃？


• 调用失败后，重试几次、间隔多久才合理？


• 敏感参数如何加密才能通过安全审计？


• 接口突然变慢时，如何第一时间收到告警？

这些问题，不是“Bug”，而是“工程意识”的试金石。能把混乱的接口接得稳定、可控、可追踪、可安全，这才是真正的技术能力。

二、“对接接口”也能写出架构感

普通开发者的代码，往往是这样的：

// 业务代码里突然冒出一段HTTP调用

RestTemplate restTemplate = new RestTemplate();

HttpHeaders headers = new HttpHeaders();

headers.set("appKey", "xxx");

headers.set("sign", "xxx");

HttpEntity<Map> entity = new HttpEntity<>(reqMap, headers);

ResponseEntity<String> res = restTemplate.postForEntity(

    "https://xxx.com/api/pay", entity, String.class);

// 然后直接解析字符串...

而高手的代码，会先画一条清晰的边界：

// 1. 定义领域接口，屏蔽HTTP细节

public interface PaymentGatewayClient {

    PaymentResponse pay(PaymentRequest request);

}



// 2. 实现类专注处理接口对接逻辑

@Service

public class AlipayGatewayClient implements PaymentGatewayClient {

    @Override

    public PaymentResponse pay(PaymentRequest request) {

        // 封装：签名生成、参数转换、超时控制

        // 集成：重试机制、日志埋点、异常转换

        // 隔离：与业务逻辑彻底分离

    }

}

业务层调用时，只需要关心业务语义，不关心HTTP细节。

这样做的好处立竿见影：

• • 换第三方支付时，只需新增实现类，业务代码零改动


• • 单元测试时，用 Mock 替代真实接口，测试速度提升 10 倍


• • 接口逻辑集中管理，不会散落在几百个业务方法里

当你能做到“接口逻辑不散落在业务代码里”，系统就已经迈入“架构级整洁”的门槛。

三、调通很容易，稳定才是实力

调通接口是初级开发者的 KPI。让接口一年 365 天稳稳跑着，那才是高级工程师的成就。

这些场景你一定踩过坑：

• • 对方接口“偶尔超时”，导致自己的系统线程池被占满


• • 并发一上来，就收到“Too Many Requests”限流提示


• • 响应 JSON 里突然多了个逗号，Jackson 解析直接抛异常


• • 异步回调乱序，先收到“支付成功”，再收到“支付中”


• • 敏感参数明文传输，被安全扫描揪出高危漏洞


• • 接口响应变慢，用户投诉后才发现

而高手的解决方案，藏在这些细节里：

1. 超时与重试：用“退避策略”减少无效请求

// 用 Resilience4j 实现指数退避重试

RetryConfig config = RetryConfig.custom()

    .maxAttempts(3) // 最多重试3次

    .waitDuration(Duration.ofMillis(1000)) // 首次间隔1秒

    .retryExceptions(TimeoutException.class, IOException.class)

    .ignoreExceptions(IllegalArgumentException.class) // 非法参数不重试

    .build();



Retry retry = Retry.of("paymentApi", config);

// 包装调用逻辑

Supplier<PaymentResponse> retryableSupplier = Retry.decorateSupplier(

    retry, () -> doCallPaymentApi(request)

);

2. 熔断降级：防止对方故障拖垮自己

// 当失败率超过50%，触发熔断

CircuitBreakerConfig config = CircuitBreakerConfig.custom()

    .failureRateThreshold(50)

    .waitDurationInOpenState(Duration.ofSeconds(60)) // 熔断60秒

    .permittedNumberOfCallsInHalfOpenState(5) // 半开状态允许5次试探

    .build();



CircuitBreaker circuitBreaker = CircuitBreaker.of("paymentApi", config);

// 降级逻辑：返回缓存数据或默认提示

Supplier<PaymentResponse> decoratedSupplier = CircuitBreaker

    .decorateSupplier(circuitBreaker, () -> doCallPaymentApi(request))

    .orElseGet(() -> buildFallbackResponse(request));

3. 日志追踪：用 TraceId 串联完整调用链

// 拦截器自动生成并传递TraceId

public class TraceIdInterceptor implements ClientHttpRequestInterceptor {

    @Override

    public ClientHttpResponse intercept(

            HttpRequest request, byte[] body, ClientHttpRequestExecution execution) {

        String traceId = MDC.get("traceId");

        if (traceId == null) {

            traceId = UUID.randomUUID().toString();

            MDC.put("traceId", traceId);

        }

        request.getHeaders().add("X-Trace-Id", traceId);

        return execution.execute(request, body);

    }

}



// 日志格式包含TraceId，方便排查问题

// logback.xml 配置：%X{traceId} [%thread] %-5level %logger{36} - %msg%n

4. 安全签名：给数据加把“锁”

接口传输的敏感信息（如手机号、银彳亍卡号）必须经过双重防护：

// 1. 参数签名：防止数据被篡改

public class SignUtils {

    public static String sign(Map<String, String> params, String secret) {

        // 按参数名ASCII排序

        List<String> keys = new ArrayList<>(params.keySet());

        Collections.sort(keys);

        // 拼接为key=value&key=value形式

        StringBuilder sb = new StringBuilder();

        for (String key : keys) {

            sb.append(key).append("=").append(params.get(key)).append("&");

        }

        // 追加密钥后用SHA256加密

        sb.append("secret=").append(secret);

        return DigestUtils.sha256Hex(sb.toString());

    }

}



// 2. 敏感字段加密：防止传输中泄露

public class EncryptUtils {

    // 手机号加密示例（AES算法）

    public static String encryptPhone(String phone, String aesKey) {

        // 实际项目中建议使用密钥管理服务存储密钥

        SecretKeySpec key = new SecretKeySpec(aesKey.getBytes(), "AES");

        Cipher cipher = Cipher.getInstance("AES/ECB/PKCS5Padding");

        cipher.init(Cipher.ENCRYPT_MODE, key);

        return Base64.getEncoder().encodeToString(cipher.doFinal(phone.getBytes()));

    }

}

5. 实时监控：让接口状态“可视化”

高手不会等到用户投诉才发现问题，而是用监控提前预警：

// 1. 自定义指标收集（基于Micrometer）

@Component

public class ApiMetricsCollector {

    private final MeterRegistry meterRegistry;

    

    public void recordApiCall(String apiName, long durationMs, boolean success) {

        // 记录接口耗时分布

        Timer.builder("thirdparty.api.duration")

            .tag("api", apiName)

            .tag("success", String.valueOf(success))

            .register(meterRegistry)

            .record(durationMs, TimeUnit.MILLISECONDS);

        

        // 记录失败次数

        if (!success) {

            Counter.builder("thirdparty.api.failure")

                .tag("api", apiName)

                .register(meterRegistry)

                .increment();

        }

    }

}



// 2. 配置监控告警（Prometheus + Grafana）

// 告警规则示例：当5分钟内失败率超过10%时触发告警

// - alert: ApiHighFailureRate

//   expr: sum(rate(thirdparty.api.failure[5m])) / sum(rate(thirdparty.api.duration_count[5m])) > 0.1

//   for: 1m

//   labels:

//     severity: critical

//   annotations:

//     summary: "接口失败率过高"

//     description: "{{ $labels.api }} 接口5分钟失败率超过10%"

一个优秀的接口对接系统，其实就是一个可观测、可预警、可恢复、可信任的微系统。

四、写给未来的自己看

很多人调完接口就走，连注释都没有。三个月后接手的人只能默默骂一句：“这谁写的鬼东西？对方文档改了哪？这个签名算法是啥意思？”

高手懂得写“能看懂的代码”，体现在这些地方：

• • 接口模型用类而非 Map：PaymentRequest 类比 Map<String, Object> 更清晰，字段注释直接写在类里


• • 错误码枚举化：PaymentErrorCode.ORDER_NOT_EXIST 比魔法值 10001 更容易维护


• • 文档内聚：在实现类里用 @see 链接对方文档地址，关键逻辑加注释说明为什么这么做


• • Mock 测试就绪：提供 MockPaymentGatewayClient，方便本地调试和单元测试

对接接口的过程，其实是你在写给未来的自己看。维护体验的好坏，体现的是你的工程素养。

五、你以为的“体力活”，其实是“架构的入门课”

对接第三方接口，本质上是一次系统边界设计的演练。

当你学会：

• 用“依赖倒置”隔离外部变化


• 用“防御性编程”处理异常情况


• 用“签名加密”保障数据安全


• 用“可观测性”确保问题可追溯


• 用“熔断降级”保障系统韧性

你就已经掌握了架构设计的核心思维。

毕竟，真实世界的系统从来不是孤立的。能把一个“不稳定的外部系统”接入得像内部服务一样稳定、可靠、优雅，那一刻，你不再是“接口调用员”，而是一个在用工程思维解决问题的架构师。

最后想说一句

下次当有人跟你说：“就调个接口嘛，这有啥难的？”。你可以微微一笑： “我不只是调接口，我在构建系统的边界。”

记住一句话：  “能调通的叫能力，能跑稳的才叫实力。”

如果觉得有启发，不妨关注下我的公众号《码上实战》。

Go 语言未来会取代 Java 吗？

（八年 Java 开发的深度拆解：从业务场景到技术底层）

开篇：面试官的灵魂拷问与行业焦虑

前年面某大厂时，技术负责人突然抛出问题：“如果让你重构公司核心系统，会选 Go 还是 Java？”

作为写了八年 Java 的老开发，我本能地想强调 Spring 生态和企业级成熟度，但对方随即展示的 PPT 让我冷汗直冒 —— 某金融公司用 Go 重构交易系统后，QPS 从 5 万飙升到 50 万，服务器成本降低 70%。这让我陷入沉思：当云原生和 AI 浪潮来袭，Java 真的要被 Go 取代了吗？

今天从 业务场景、技术本质、行业趋势 三个维度，结合实战代码和踩坑经验，聊聊我的真实看法。

一、业务场景对比：Go 的 “闪电战” vs Java 的 “持久战”

先看三个典型业务场景，你会发现两者的差异远不止 “性能” 二字。

场景 1：高并发抢购（电商大促）

Go 实现（Gin 框架） ：

func main() {

    router := gin.Default()

    router.GET("/seckill", func(c *gin.Context) {

        // 轻量级goroutine处理请求

        go func() {

            // 直接操作Redis库存

            if err := redisClient.Decr("stock").Err(); err != nil {

                c.JSON(http.StatusOK, gin.H{"result": "fail"})

                return

            }

            c.JSON(http.StatusOK, gin.H{"result": "success"})

        }()

    })

    router.Run(":8080")

}

性能数据：单机轻松支撑 10 万 QPS，p99 延迟 < 5ms。

Java 实现（Spring Boot + 虚拟线程） ：

@RestController

public class SeckillController {

    @GetMapping("/seckill")

    public CompletableFuture<ResponseEntity<String>> seckill() {

        return CompletableFuture.supplyAsync(() -> {

            // 虚拟线程处理IO操作

            if (redisTemplate.opsForValue().decrement("stock") < 0) {

                return ResponseEntity.ok("fail");

            }

            return ResponseEntity.ok("success");

        }, Executors.newVirtualThreadPerTaskExecutor());

    }

}

性能数据：Java 21 虚拟线程让 IO 密集型场景吞吐量提升 7 倍，p99 延迟从 165ms 降至 23ms。

核心差异：

• Go：天生适合高并发，Goroutine 调度和原生 Redis 操作无额外开销。


• Java：依赖 JVM 调优，虚拟线程虽大幅提升性能，但需配合线程池和异步框架。

场景 2：智能运维平台（云原生领域）

Go 实现（Ollama + gRPC） ：

func main() {

    // 启动gRPC服务处理AI推理请求

    server := grpc.NewServer()

    pb.RegisterAIAnalysisServer(server, &AIHandler{})

    go func() {

        if err := server.Serve(lis); err != nil {

            log.Fatalf("Server exited with error: %v", err)

        }

    }()

    

    // 采集节点数据（百万级设备）

    for i := 0; i < 1000000; i++ {

        go func(nodeID int) {

            for {

                data := collectMetrics(nodeID)

                client.Send(data) // 通过channel传递数据

            }

        }(i)

    }

}

优势：轻量级 Goroutine 高效处理设备数据采集，gRPC 接口响应速度比 REST 快 30%。

Java 实现（Spring Cloud + Kafka） ：

@Service

public class MonitorService {

    @Autowired

    private KafkaTemplate<String, String> kafkaTemplate;



    public void collectMetrics(int nodeID) {

        ScheduledExecutorService executor = Executors.newScheduledThreadPool(100);

        executor.scheduleAtFixedRate(() -> {

            String data =采集数据(nodeID);

            kafkaTemplate.send("metrics-topic", data);

        }, 0, 1, TimeUnit.SECONDS);

    }

}

挑战：传统线程池在百万级设备下内存占用飙升，需配合 Kafka 分区和 Consumer Gr0up 优化。

核心差异：

• Go：云原生基因，从采集到 AI 推理全链路高效协同。


• Java：生态依赖强，需整合 Spring Cloud、Kafka 等组件，部署复杂度高。

场景 3：企业 ERP 系统（传统行业）

Java 实现（Spring + Hibernate） ：

@Entity

@Table(name = "orders")

public class Order {

    @Id

    @GeneratedValue(strategy = GenerationType.IDENTITY)

    private Long id;



    @ManyToOne

    @JoinColumn(name = "user_id")

    private User user;



    // 复杂业务逻辑注解

    @PrePersist

    public void validateOrder() {

        if (totalAmount < 0) {

            throw new BusinessException("金额不能为负数");

        }

    }

}

优势：Spring 的事务管理和 Hibernate 的 ORM 完美支持复杂业务逻辑，代码可读性高。

Go 实现（GORM + 接口组合） ：

type Order struct {

    ID        uint   `gorm:"primaryKey"`

    UserID    uint

    Total     float64

}



func (o *Order) Validate() error {

    if o.Total < 0 {

        return errors.New("金额不能为负数")

    }

    return nil

}



func CreateOrder(ctx context.Context, order Order) error {

    if err := order.Validate(); err != nil {

        return err

    }

    return db.Create(&order).Error

}

挑战：需手动实现事务和复杂校验逻辑，代码量比 Java 多 20%。

核心差异：

• Java：企业级成熟度，框架直接支持事务、权限、审计等功能。


• Go：灵活性高，但需手动实现大量基础功能，适合轻量级业务。

二、技术本质：为什么 Go 在某些场景碾压 Java？

从 并发模型、内存管理、性能调优 三个维度，深挖两者的底层差异。

1. 并发模型：Goroutine vs 线程 / 虚拟线程

Go 的 Goroutine：

• 轻量级：每个 Goroutine 仅需 2KB 栈空间，可轻松创建百万级并发。


• 调度高效：基于 GMP 模型，避免内核级上下文切换，IO 阻塞时自动释放线程。

Java 的虚拟线程（Java 21+） ：

• 革命性改进：每个虚拟线程仅需几百字节内存，IO 密集型场景吞吐量提升 7 倍。


• 兼容传统代码：无需修改业务逻辑，直接将new Thread()替换为Thread.startVirtualThread()。

性能对比：

• HTTP 服务：Go 的 Gin 框架单机 QPS 可达 5 万，Java 21 虚拟线程 + Netty 可达 3 万。


• 消息处理：Go 的 Kafka 消费者单节点处理速度比 Java 快 40%。

2. 内存管理：逃逸分析 vs 分代 GC

Go 的逃逸分析：

• 栈优先分配：对象若未逃逸出函数，直接在栈上分配，减少 GC 压力。


• 零拷贝优化：io.Reader接口直接操作底层缓冲区，避免内存复制。

Java 的分代 GC：

• 成熟但复杂：新生代采用复制算法，老年代采用标记 - 压缩，需通过-XX:G1HeapRegionSize等参数调优。


• 内存占用高：同等业务逻辑下，Java 堆内存通常是 Go 的 2-3 倍。

典型案例：

某金融公司用 Go 重构风控系统后，内存占用从 8GB 降至 3GB，GC 停顿时间从 200ms 缩短至 10ms。

3. 性能调优：静态编译 vs JIT 编译

Go 的静态编译：

• 启动快：编译后的二进制文件直接运行，无需预热 JVM。


• 可预测性强：性能表现稳定，适合对延迟敏感的场景（如高频交易）。

Java 的 JIT 编译：

• 动态优化：运行时将热点代码编译为机器码，长期运行后性能可能反超 Go。


• 依赖调优经验：需通过-XX:CompileThreshold等参数平衡启动时间和运行效率。

实测数据：

• 启动时间：Go 的 HTTP 服务启动仅需 20ms，Java Spring Boot 需 500ms。


• 长期运行：持续 24 小时压测，Java 的吞吐量可能比 Go 高 10%（JIT 优化后）。

三、行业趋势：Go 在蚕食 Java 市场，但 Java 不会轻易退场

从 市场数据、生态扩展、技术演进 三个维度，分析两者的未来走向。

1. 市场数据：Go 在高速增长，Java 仍占主导

• 份额变化：Go 在 TIOBE 排行榜中从 2020 年的第 13 位升至 2025 年的第 7 位，市场份额突破 3%。


• 薪资对比：Go 开发者平均薪资比 Java 高 20%，但 Java 岗位数量仍是 Go 的 5 倍。

典型案例：

• 字节跳动：核心推荐系统用 Go 重构，QPS 提升 3 倍，成本降低 60%。


• 招商银行：核心交易系统仍用 Java，但微服务网关和监控平台全面转向 Go。

2. 生态扩展：Go 拥抱 AI，Java 深耕企业级

Go 的 AI 集成：

• 工具链完善：通过 Ollama 框架可直接调用 LLM 模型，实现智能运维告警。


• 性能优势：Go 的推理服务延迟比 Python 低 80%，适合边缘计算场景。

Java 的企业级护城河：

• 大数据生态：Hadoop、Spark、Flink 等框架仍深度依赖 Java。


• 移动端统治力：尽管 Kotlin 流行，Android 系统底层和核心应用仍用 Java 开发。

3. 技术演进：Go 和 Java 都在进化

Go 的发展方向：

• 泛型完善：Go 1.18 + 支持泛型，减少重复代码（如PrintSlice函数可适配任意类型）。


• WebAssembly 集成：计划将 Goroutine 编译为 Wasm，实现浏览器端高并发。

Java 的反击：

• Project Loom：虚拟线程已转正，未来将支持更细粒度的并发控制。


• Project Valhalla：引入值类型，减少对象装箱拆箱开销，提升性能 15%。

四、选型建议：Java 开发者该如何应对？

作为八年 Java 老兵，我的 技术选型原则 是：用最合适的工具解决问题，而非陷入语言宗教战争。

1. 优先选 Go 的场景

• 云原生基础设施：API 网关、服务网格、CI/CD 工具链（如 Kubernetes 用 Go 开发）。


• 高并发实时系统：IM 聊天、金融交易、IoT 数据采集（单机 QPS 需求 > 1 万）。


• AI 推理服务：边缘计算节点、实时推荐系统（需低延迟和高吞吐量）。

2. 优先选 Java 的场景

• 复杂企业级系统：ERP、CRM、银行核心业务（需事务、权限、审计等功能）。


• Android 开发：系统级应用和性能敏感模块（如相机、传感器驱动）。


• 大数据处理：离线分析、机器学习训练（Hadoop/Spark 生态成熟）。

3. 混合架构：Go 和 Java 共存的最佳实践

• API 网关用 Go：处理高并发请求，转发到 Java 微服务。


• AI 推理用 Go：部署轻量级模型，结果通过 gRPC 返回给 Java 业务层。


• 数据存储用 Java：复杂查询和事务管理仍由 Java 服务处理。

代码示例：Go 调用 Java 微服务

// Go客户端

conn, err := grpc.Dial("java-service:8080", grpc.WithInsecure())

if err != nil {

    log.Fatalf("连接失败: %v", err)

}

defer conn.Close()



client := pb.NewJavaServiceClient(conn)

resp, err := client.ProcessData(context.Background(), &pb.DataRequest{Data: "test"})

if err != nil {

    log.Fatalf("调用失败: %v", err)

}

fmt.Println("Java服务返回:", resp.Result)

// Java服务端

@GrpcService

public class JavaServiceImpl extends JavaServiceGrpc.JavaServiceImplBase {

    @Override

    public void processData(DataRequest request, StreamObserver<DataResponse> responseObserver) {

        String result =复杂业务逻辑(request.getData());

        responseObserver.onNext(DataResponse.newBuilder().setResult(result).build());

        responseObserver.onCompleted();

    }

}

五、总结：焦虑源于未知，成长来自行动

回到开篇的问题：Go 会取代 Java 吗？  我的答案是：短期内不会，但长期会形成互补格局。

• Java 的不可替代性：企业级成熟度、Android 生态、大数据框架，这些优势难以撼动。


• Go 的不可阻挡性：云原生、高并发、AI 集成，这些领域 Go 正在建立新标准。

作为开发者，与其焦虑语言之争，不如：

最后分享一个真实案例：某电商公司将支付核心用 Java 保留，抢购服务用 Go 重构，大促期间 QPS 从 5 万提升到 50 万，系统总成本降低 40%。这说明，语言只是工具，业务价值才是终极目标。

最近在做的事情正好需要系统地研究微服务与单体架构的取舍与演进。读到这篇文章《Microservices Are Quietly Dying — And It’s Beautiful》，许多观点直击痛点、非常启发，于是我顺手把它翻译出来，分享给大家，也希望能给同样在复杂性与效率之间权衡的团队一些参考。

微服务正在悄然消亡：这是一件美好的事

为了把我们的创业产品扩展到数百万用户，我们搭建了 47 个微服务。

用户从未达到一百万，但我们达到了每月 23,000 美元的 AWS 账单、长达 14 小时的故障，以及一个再也无法高效交付新功能的团队。

那一刻我才意识到：我们并没有在构建产品，而是在搭建一座分布式的自恋纪念碑。

我们都信过的谎言

五年前，微服务几乎是教条。Netflix 用它，Uber 用它。每一场技术大会、每一篇 Medium 文章、每一位资深架构师都在高喊同一句话：单体不具备可扩展性，微服务才是答案。

于是我们照做了。我们把 Rails 单体拆成一个个服务：用户服务、认证服务、支付服务、通知服务、分析服务、邮件服务；然后是子服务，再然后是调用服务的服务，层层套叠。

到第六个月，我们已经在 12 个 GitHub 仓库里维护 47 个服务。我们的部署流水线像一张地铁图，架构图需要 4K 显示器才能看清。

当“最佳实践”变成“最差实践”

我们不断告诫自己：一切都在运转。我们有 Kubernetes，有服务网格，有用 Jaeger 的分布式追踪，有 ELK 的日志——我们很“现代”。

但那些光鲜的微服务文章从不提的一点是：分布式的隐性税。

每一个新功能都变成跨团队的协商。想给用户资料加一个字段？那意味着要改五个服务、提三个 PR、协调两周，并进行一次像劫案电影一样精心编排的数据库迁移。

我们的预发布环境成本甚至高于生产环境，因为想测试任何东西，都需要把一切都跑起来。47 个服务在 Docker Compose 里同时启动，内存被疯狂吞噬。

那个彻夜崩溃的夜晚

凌晨 2:47，Slack 被消息炸翻。

生产环境宕了。不是某一个服务——是所有服务。支付服务连不上用户服务，通知服务不断超时，API 网关对每个请求都返回 503。

我打开分布式追踪面板：一万五千个 span，全线飘红。瀑布图像抽象艺术。我花了 40 分钟才定位出故障起点。

结果呢？一位初级开发在认证服务上发布了一个配置变更，只是一个环境变量。它让令牌校验多了 2 秒延迟，这个延迟在 11 个下游服务间层层传递，超时叠加、断路器触发、重试逻辑制造请求风暴，整个系统在自身重量下轰然倒塌。

我们搭了一座纸牌屋，却称之为“容错架构”。

我们花了六个小时才修复。并不是因为 bug 复杂——它只是一个配置的单行改动，而是因为排查分布式系统就像破获一桩谋杀案：每个目击者说着不同的语言，而且有一半在撒谎。

那个被忽略的低语

一周后，在复盘会上，我们的 CTO 说了句让所有人不自在的话：

“要不我们……回去？”

回到单体。回到一个仓库。回到简单。

会议室一片沉默。你能感到认知失调。我们是工程师，我们很“高级”。单体是给传统公司和训练营毕业生用的，不是给一家正打造未来的 A 轮初创公司用的。

但随后有人把指标展开：平均恢复时间 4.2 小时；部署频率每周 2.3 次（从单体时代的每周 12 次一路下滑）；云成本增长速度比营收快 40%。

数字不会说谎。是架构在拖垮我们。

美丽的回归

我们用了三个月做整合。47 个服务归并成一个模块划分清晰的 Rails 应用；Kubernetes 变成负载均衡后面的三台 EC2；12 个仓库的工作流收敛成一个边界明确的仓库。

结果简直让人尴尬。

部署时间从 25 分钟降到 90 秒；AWS 账单从 23,000 美元降到 3,800 美元；P95 延迟提升了 60%，因为我们消除了 80% 的网络调用。更重要的是——我们又开始按时交付功能了。

开发者不再说“我需要和三个团队协调”，而是开始说“午饭前给你”。

我们的“分布式系统”变回了结构良好的应用。边界上下文变成 Rails 引擎，服务调用变成方法调用，Kafka 变成后台任务，“编排层”……就是 Rails 控制器。

它更快，它更省，它更好。

我们真正学到的是什么

这是真相：我们为此付出两年时间和 40 万美元才领悟——

微服务不是一种纯粹的架构模式，而是一种组织模式。Netflix 需要它，因为他们有 200 个团队。你没有。Uber 需要它，因为他们一天发布 4,000 次。你没有。

复杂性之所以诱人，是因为它看起来像进步。 拥有 47 个服务、Kubernetes、服务网格和分布式追踪，看起来很“专业”；而一个单体加一套 Postgres，看起来很“业余”。

但复杂性是一种税。它以认知负担、运营开销、开发者幸福感和交付速度为代价。

而大多数初创公司根本付不起这笔税。

我们花了两年时间为并不存在的规模做优化，同时牺牲了能让我们真正达到规模的简单性。

你不需要 50 个微服务，你需要的是自律

软件架构的“肮脏秘密”是：好的设计在任何规模都奏效。

一个结构良好的单体，拥有清晰的模块、明确的边界上下文和合理的关注点分离，比一团由希望和 YAML 勉强粘合在一起的微服务乱麻走得更远。

微服务并不是因为“糟糕”而式微，而是因为我们出于错误的理由使用了它。我们选择了分布式的复杂性而不是本地的自律，选择了运营的负担而不是价值的交付。

那些悄悄回归单体的公司并非承认失败，而是在承认更难的事实：我们一直在解决错误的问题。

所以我想问一个问题：你构建微服务，是在逃避什么？

如果答案是“一个凌乱的代码库”，那我有个坏消息——分布式系统不会修好坏代码，它只会让问题更难被发现。

快到年底了，系统频繁出问题。我有正当理由怀疑老板不想发年终奖所以搞事。

这不，几年都遇不到的消息队列积压现象今晚又卷土重来了。

今晚注定是个不眠夜了，原神启动。。。

组里的小伙伴火急火燎找到我说，Kafka 的消息积压一直在涨，预览图一直出不来。我加了几个服务实例，刚开始可以消费，后面消费着也卡住了。

本来刚刚下班的我就比较疲惫，想让他撤回镜像明天再上。不成想组长不讲武德，直接开了个飞书视频。

我当时本来不想理他，我已经下班了，别人上线的功能出问题关我啥事。

后来他趁我不注意搞偷袭，给我私信了，我当时没多想就点开了飞书。

本来以传统功夫的点到为止，我进入飞书不点开他的会话，是能看他给我发的最后一句话的。

我把手放在他那个会话上就是没点开，已读不回这种事做多了不好。我笑了一下，准备洗洗睡了。

正在我收手不点的时候，他突然给我来了一个电话，我大意了啊，没有挂，还强行接了他的电话。两分多钟以后就好了，我说小伙子你不讲武德。

直接喊话，今晚必须解决，大家都点咖啡算他的。

这真没办法，都找上门来了。只能跟着查一下，早点解决早点睡觉。然后我就上 Kafka 面板一看：最初的4个分区已经积压了 1200 条，后面新加的分区也开始积压了，而且积压的速度越来越快。

搞清楚发生了什么？我们就得思考一下导致积压的原因。一般是消费者代码执行出错了，导致某条消息消费不了。

所以某个点卡住了，然后又有新的消息进来。

Kafka 是通过 offset 机制来标记消息是否消费过的，所以如果分区中有某一条消息消费失败，就会导致后面的没机会消费。

我用的是spring cloud stream 来处理消息队列的发送和监听。代码上是每次处理一条消息，而且代码还在处理的过程中加了 try-catch。监听器链路打印的日志显示执行成功了，try-catch也没有捕捉到任何的异常。

这一看，我就以为是消费者性能不足，突然想起 SpringCloudStream 好像有个多线程消费的机制。立马让开发老哥试试，看看能不能就这样解决了，我困得不行。

我半眯着眼睛被提醒吵醒了。开发老哥把多线程改成10之后，发现积压更快了，而且还有pod会挂。老哥查了一下多线程的配置 concurrency。

原来指的是消费者线程，一个消费者线程会负责处理一个分区。对于我们来说，增加之后可能会导致严重的流量倾斜，难怪pod会挂掉，赶紧恢复了回去。

看来想糊弄过去是不行了，我把pod运行的日志全部拉下来。查了一下日志，日志显示执行成功了，但同时有超时错误，这就见了鬼了。

作为一个坚定的唯物主义者，我是不信见鬼的。但此刻我汗毛倒竖，吓得不敢再看屏幕一眼。

但是内心又觉得不甘心，于是我偷偷瞄了一眼屏幕。不看还好，一喵你猜我发现了啥？

消费者组重平衡了，这就像是在黑暗中有一束光照向了我，猪八戒发现嫦娥原来一直暗恋自己，我的女神其实不需要拉屎。

有了重平衡就好说了，无非就是两种情况，一是服务挂掉了，二是服务消费者执行超时了。现在看来服务没有挂，那就是超时了，也正好和上面的日志能对上。

那怎么又看到监听器执行的结果是正常的呢？

这就得从 Kafka 的批量拉取机制说起了，这货和我们人类直觉上的的队列机制不太一样。我们一般理解的队列是发送一个消息给队列，然后队列就异步把这消息给消费者。但是这货是消费者主动去拉取一批来消费。

然后好死不死，SpringCloudStream 为了封装得好用符合人类的认知，就做成了一般理解的队列那种方式。

SpringCloudStream 一批拉了500条记录，然后提供了一个监听器接口让我们实现。入参是一个对象，也就是500条数据中的一条，而不是一个数组。

我们假设这500条数据的ID是 001-500，每一条数据对应的消费者需要执行10s。那么总共就需要500 x 10s=5000s。

再假设消费者执行的超时时间是 300s，而且消费者执行的过程是串行的。那么500条中最多只能执行30条，这就能解释为什么看消费链路是正常的，但是还超时。

因为单次消费确实成功了，但是批次消费也确实超时了。

我咧个豆，破案了。

于是我就想到了两种方式来处理这个问题：第一是改成单条消息消费完立马确认，第二是把批次拉取的数据量改小一点。

第一种方案挺好的，就是性能肯定没有批量那么好，不然你以为 Kafka 的吞吐量能薄纱ActiveMQ这些传统队列。吞吐量都是小事，这个方案胜在可以立马去睡觉了。只需要改一个配置：ack-mode: RECORD

第二种方案是后来提的，其实单单把批次拉取的数据量改小性能提升还不是很明显。不过既然我们都能拿到一批数据了，那多线程安排上就得了。

先改配置，一次只拉取50条 max.poll.records: 50。然后启用线程池处理，完美！

@StreamListener("<TOPIC>")

public void consume(List<byte[]> payloads) {

    

    List<CompletableFuture<Void>> futures = payloads.stream().map(bytes -> {

        Payload payload = JacksonSnakeCaseUtils.parseJson(new String(bytes), Payload.class);



        return CompletableFuture.runAsync(() -> {

            // ........

        }, batchConsumeExecutor).exceptionally(e -> {

            log.error("Thread error {}", bytes, e);

            return null;

        });

    }).collect(Collectors.toList());



    try {

        // 等待这批消息中的所有任务全部完成

        CompletableFuture.allOf(futures.toArray(new CompletableFuture[0])).join();

        errorMessage = "OK";

    } catch (Exception e) {

        errorMessage = "Ex: " + e.getMessage();

    } finally {

        // ...

    }

}

前言

对于从事java开发工作的同学来说，Spring的事务肯定再熟悉不过了。

在某些业务场景下，如果一个请求中，需要同时写入多张表的数据。为了保证操作的原子性（要么同时成功，要么同时失败），避免数据不一致的情况，我们一般都会用到Spring事务。

确实，Spring事务用起来贼爽，就用一个简单的注解：@Transactional，就能轻松搞定事务。我猜大部分小伙伴也是这样用的，而且一直用一直爽。

但如果你使用不当，它也会坑你于无形。

今天我们就一起聊聊，事务失效的一些场景，说不定你已经中招了。不信，让我们一起看看。

一 事务不生效

1.访问权限问题

众所周知，java的访问权限主要有四种：private、default、protected、public，它们的权限从左到右，依次变大。

但如果我们在开发过程中，把有某些事务方法，定义了错误的访问权限，就会导致事务功能出问题，例如：

@Service

public class UserService {

    

    @Transactional

    private void add(UserModel userModel) {

         saveData(userModel);

         updateData(userModel);

    }

}

我们可以看到add方法的访问权限被定义成了private，这样会导致事务失效，spring要求被代理方法必须是public的。

说白了，在AbstractFallbackTransactionAttributeSource类的computeTransactionAttribute方法中有个判断，如果目标方法不是public，则TransactionAttribute返回null，即不支持事务。

protected TransactionAttribute computeTransactionAttribute(Method method, @Nullable Class<?> targetClass) {

    // Don't allow no-public methods as required.

    if (allowPublicMethodsOnly() && !Modifier.isPublic(method.getModifiers())) {

      return null;

    }



    // The method may be on an interface, but we need attributes from the target class.

    // If the target class is null, the method will be unchanged.

    Method specificMethod = AopUtils.getMostSpecificMethod(method, targetClass);



    // First try is the method in the target class.

    TransactionAttribute txAttr = findTransactionAttribute(specificMethod);

    if (txAttr != null) {

      return txAttr;

    }



    // Second try is the transaction attribute on the target class.

    txAttr = findTransactionAttribute(specificMethod.getDeclaringClass());

    if (txAttr != null && ClassUtils.isUserLevelMethod(method)) {

      return txAttr;

    }



    if (specificMethod != method) {

      // Fallback is to look at the original method.

      txAttr = findTransactionAttribute(method);

      if (txAttr != null) {

        return txAttr;

      }

      // Last fallback is the class of the original method.

      txAttr = findTransactionAttribute(method.getDeclaringClass());

      if (txAttr != null && ClassUtils.isUserLevelMethod(method)) {

        return txAttr;

      }

    }

    return null;

  }

也就是说，如果我们自定义的事务方法（即目标方法），它的访问权限不是public，而是private、default或protected的话，spring则不会提供事务功能。

2. 方法用final修饰

有时候，某个方法不想被子类重新，这时可以将该方法定义成final的。普通方法这样定义是没问题的，但如果将事务方法定义成final，例如：

@Service

public class UserService {



    @Transactional

    public final void add(UserModel userModel){

        saveData(userModel);

        updateData(userModel);

    }

}

我们可以看到add方法被定义成了final的，这样会导致事务失效。

为什么？

如果你看过spring事务的源码，可能会知道spring事务底层使用了aop，也就是通过jdk动态代理或者cglib，帮我们生成了代理类，在代理类中实现的事务功能。

但如果某个方法用final修饰了，那么在它的代理类中，就无法重写该方法，而添加事务功能。

注意：如果某个方法是static的，同样无法通过动态代理，变成事务方法。

3.方法内部调用

有时候我们需要在某个Service类的某个方法中，调用另外一个事务方法，比如：

@Service

public class UserService {



    @Autowired

    private UserMapper userMapper;



    //@Transactional

    public void add(UserModel userModel) {

        userMapper.insertUser(userModel);

        updateStatus(userModel);

    }



    @Transactional

    public void updateStatus(UserModel userModel) {

        doSameThing();

    }

}

我们看到在事务方法add中，直接调用事务方法updateStatus。从前面介绍的内容可以知道，updateStatus方法拥有事务的能力是因为spring aop生成代理了对象，但是这种方法直接调用了this对象的方法，所以updateStatus方法不会生成事务。

由此可见，在同一个类中的方法直接内部调用，会导致事务失效。

那么问题来了，如果有些场景，确实想在同一个类的某个方法中，调用它自己的另外一个方法，该怎么办呢？

3.1 新加一个Service方法

这个方法非常简单，只需要新加一个Service方法，把@Transactional注解加到新Service方法上，把需要事务执行的代码移到新方法中。具体代码如下：

@Servcie

public class ServiceA {

   @Autowired

   prvate ServiceB serviceB;



   public void save(User user) {

         queryData1();

         queryData2();

         serviceB.doSave(user);

   }

 }



 @Servcie

 public class ServiceB {



    @Transactional(rollbackFor=Exception.class)

    public void doSave(User user) {

       addData1();

       updateData2();

    }



 }

3.2 在该Service类中注入自己

如果不想再新加一个Service类，在该Service类中注入自己也是一种选择。具体代码如下：

@Servcie

public class ServiceA {

   @Autowired

   prvate ServiceA serviceA;



   public void save(User user) {

         queryData1();

         queryData2();

         serviceA.doSave(user);

   }



   @Transactional(rollbackFor=Exception.class)

   public void doSave(User user) {

       addData1();

       updateData2();

    }

 }

可能有些人可能会有这样的疑问：这种做法会不会出现循环依赖问题？

答案：不会。

其实spring ioc内部的三级缓存保证了它，不会出现循环依赖问题。但有些坑，如果你想进一步了解循环依赖问题，可以看看我之前文章《spring：我是如何解决循环依赖的？》。

3.3 通过AopContent类

在该Service类中使用AopContext.currentProxy()获取代理对象

上面的方法2确实可以解决问题，但是代码看起来并不直观，还可以通过在该Service类中使用AOPProxy获取代理对象，实现相同的功能。具体代码如下：

@Servcie

public class ServiceA {



   public void save(User user) {

         queryData1();

         queryData2();

         ((ServiceA)AopContext.currentProxy()).doSave(user);

   }



   @Transactional(rollbackFor=Exception.class)

   public void doSave(User user) {

       addData1();

       updateData2();

    }

 }

4.未被spring管理

在我们平时开发过程中，有个细节很容易被忽略。即使用spring事务的前提是：对象要被spring管理，需要创建bean实例。

通常情况下，我们通过@Controller、@Service、@Component、@Repository等注解，可以自动实现bean实例化和依赖注入的功能。

当然创建bean实例的方法还有很多，有兴趣的小伙伴可以看看我之前写的另一篇文章《@Autowired的这些骚操作，你都知道吗？》

如果有一天，你匆匆忙忙的开发了一个Service类，但忘了加@Service注解，比如：

//@Service

public class UserService {



    @Transactional

    public void add(UserModel userModel) {

         saveData(userModel);

         updateData(userModel);

    }    

}

从上面的例子，我们可以看到UserService类没有加@Service注解，那么该类不会交给spring管理，所以它的add方法也不会生成事务。

5.多线程调用

在实际项目开发中，多线程的使用场景还是挺多的。如果spring事务用在多线程场景中，会有问题吗？

@Slf4j

@Service

public class UserService {



    @Autowired

    private UserMapper userMapper;

    @Autowired

    private RoleService roleService;



    @Transactional

    public void add(UserModel userModel) throws Exception {

        userMapper.insertUser(userModel);

        new Thread(() -> {

            roleService.doOtherThing();

        }).start();

    }

}



@Service

public class RoleService {



    @Transactional

    public void doOtherThing() {

        System.out.println("保存role表数据");

    }

}

从上面的例子中，我们可以看到事务方法add中，调用了事务方法doOtherThing，但是事务方法doOtherThing是在另外一个线程中调用的。

这样会导致两个方法不在同一个线程中，获取到的数据库连接不一样，从而是两个不同的事务。如果想doOtherThing方法中抛了异常，add方法也回滚是不可能的。

如果看过spring事务源码的朋友，可能会知道spring的事务是通过数据库连接来实现的。当前线程中保存了一个map，key是数据源，value是数据库连接。

private static final ThreadLocal<Map<Object, Object>> resources =



  new NamedThreadLocal<>("Transactional resources");

我们说的同一个事务，其实是指同一个数据库连接，只有拥有同一个数据库连接才能同时提交和回滚。如果在不同的线程，拿到的数据库连接肯定是不一样的，所以是不同的事务。

6.表不支持事务

周所周知，在mysql5之前，默认的数据库引擎是myisam。

它的好处就不用多说了：索引文件和数据文件是分开存储的，对于查多写少的单表操作，性能比innodb更好。

有些老项目中，可能还在用它。

在创建表的时候，只需要把ENGINE参数设置成MyISAM即可：

CREATE TABLE `category` (

  `id` bigint NOT NULL AUTO_INCREMENT,

  `one_category` varchar(20) COLLATE utf8mb4_bin DEFAULT NULL,

  `two_category` varchar(20) COLLATE utf8mb4_bin DEFAULT NULL,

  `three_category` varchar(20) COLLATE utf8mb4_bin DEFAULT NULL,

  `four_category` varchar(20) COLLATE utf8mb4_bin DEFAULT NULL,

  PRIMARY KEY (`id`)

) ENGINE=MyISAM AUTO_INCREMENT=4 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin

myisam好用，但有个很致命的问题是：不支持事务。

如果只是单表操作还好，不会出现太大的问题。但如果需要跨多张表操作，由于其不支持事务，数据极有可能会出现不完整的情况。

此外，myisam还不支持行锁和外键。

所以在实际业务场景中，myisam使用的并不多。在mysql5以后，myisam已经逐渐退出了历史的舞台，取而代之的是innodb。

有时候我们在开发的过程中，发现某张表的事务一直都没有生效，那不一定是spring事务的锅，最好确认一下你使用的那张表，是否支持事务。

7.未开启事务

有时候，事务没有生效的根本原因是没有开启事务。

你看到这句话可能会觉得好笑。

开启事务不是一个项目中，最最最基本的功能吗？

为什么还会没有开启事务？

没错，如果项目已经搭建好了，事务功能肯定是有的。

但如果你是在搭建项目demo的时候，只有一张表，而这张表的事务没有生效。那么会是什么原因造成的呢？

当然原因有很多，但没有开启事务，这个原因极其容易被忽略。

如果你使用的是springboot项目，那么你很幸运。因为springboot通过DataSourceTransactionManagerAutoConfiguration类，已经默默的帮你开启了事务。

你所要做的事情很简单，只需要配置spring.datasource相关参数即可。

但如果你使用的还是传统的spring项目，则需要在applicationContext.xml文件中，手动配置事务相关参数。如果忘了配置，事务肯定是不会生效的。

具体配置如下信息：

   

<!-- 配置事务管理器 --> 

<bean class="org.springframework.jdbc.datasource.DataSourceTransactionManager" id="transactionManager"> 

    <property name="dataSource" ref="dataSource"></property> 

</bean> 

<tx:advice id="advice" transaction-manager="transactionManager"> 

    <tx:attributes> 

        <tx:method name="*" propagation="REQUIRED"/>

    </tx:attributes> 

</tx:advice> 

<!-- 用切点把事务切进去 --> 

<aop:config> 

    <aop:pointcut expression="execution(* com.susan.*.*(..))" id="pointcut"/> 

    <aop:advisor advice-ref="advice" pointcut-ref="pointcut"/> 

</aop:config> 

默默的说一句，如果在pointcut标签中的切入点匹配规则，配错了的话，有些类的事务也不会生效。

二 事务不回滚

1.错误的传播特性

其实，我们在使用@Transactional注解时，是可以指定propagation参数的。

该参数的作用是指定事务的传播特性，spring目前支持7种传播特性：

• REQUIRED 如果当前上下文中存在事务，那么加入该事务，如果不存在事务，创建一个事务，这是默认的传播属性值。


• SUPPORTS 如果当前上下文存在事务，则支持事务加入事务，如果不存在事务，则使用非事务的方式执行。


• MANDATORY 如果当前上下文中存在事务，否则抛出异常。


• REQUIRES_NEW 每次都会新建一个事务，并且同时将上下文中的事务挂起，执行当前新建事务完成以后，上下文事务恢复再执行。


• NOT_SUPPORTED 如果当前上下文中存在事务，则挂起当前事务，然后新的方法在没有事务的环境中执行。


• NEVER 如果当前上下文中存在事务，则抛出异常，否则在无事务环境上执行代码。


• NESTED 如果当前上下文中存在事务，则嵌套事务执行，如果不存在事务，则新建事务。

如果我们在手动设置propagation参数的时候，把传播特性设置错了，比如：

@Service

public class UserService {



    @Transactional(propagation = Propagation.NEVER)

    public void add(UserModel userModel) {

        saveData(userModel);

        updateData(userModel);

    }

}

我们可以看到add方法的事务传播特性定义成了Propagation.NEVER，这种类型的传播特性不支持事务，如果有事务则会抛异常。

目前只有这三种传播特性才会创建新事务：REQUIRED，REQUIRES_NEW，NESTED。

2.自己吞了异常

事务不会回滚，最常见的问题是：开发者在代码中手动try...catch了异常。比如：

@Slf4j

@Service

public class UserService {

    

    @Transactional

    public void add(UserModel userModel) {

        try {

            saveData(userModel);

            updateData(userModel);

        } catch (Exception e) {

            log.error(e.getMessage(), e);

        }

    }

}

这种情况下spring事务当然不会回滚，因为开发者自己捕获了异常，又没有手动抛出，换句话说就是把异常吞掉了。

如果想要spring事务能够正常回滚，必须抛出它能够处理的异常。如果没有抛异常，则spring认为程序是正常的。

3.手动抛了别的异常

即使开发者没有手动捕获异常，但如果抛的异常不正确，spring事务也不会回滚。

@Slf4j

@Service

public class UserService {

    

    @Transactional

    public void add(UserModel userModel) throws Exception {

        try {

             saveData(userModel);

             updateData(userModel);

        } catch (Exception e) {

            log.error(e.getMessage(), e);

            throw new Exception(e);

        }

    }

}

上面的这种情况，开发人员自己捕获了异常，又手动抛出了异常：Exception，事务同样不会回滚。

因为spring事务，默认情况下只会回滚RuntimeException（运行时异常）和Error（错误），对于普通的Exception（非运行时异常），它不会回滚。

4.自定义了回滚异常

在使用@Transactional注解声明事务时，有时我们想自定义回滚的异常，spring也是支持的。可以通过设置rollbackFor参数，来完成这个功能。

但如果这个参数的值设置错了，就会引出一些莫名其妙的问题，例如：

@Slf4j

@Service

public class UserService {

    

    @Transactional(rollbackFor = BusinessException.class)

    public void add(UserModel userModel) throws Exception {

       saveData(userModel);

       updateData(userModel);

    }

}

如果在执行上面这段代码，保存和更新数据时，程序报错了，抛了SqlException、DuplicateKeyException等异常。而BusinessException是我们自定义的异常，报错的异常不属于BusinessException，所以事务也不会回滚。

即使rollbackFor有默认值，但阿里巴巴开发者规范中，还是要求开发者重新指定该参数。

这是为什么呢？

因为如果使用默认值，一旦程序抛出了Exception，事务不会回滚，这会出现很大的bug。所以，建议一般情况下，将该参数设置成：Exception或Throwable。

5.嵌套事务回滚多了

public class UserService {



    @Autowired

    private UserMapper userMapper;



    @Autowired

    private RoleService roleService;



    @Transactional

    public void add(UserModel userModel) throws Exception {

        userMapper.insertUser(userModel);

        roleService.doOtherThing();

    }

}



@Service

public class RoleService {



    @Transactional(propagation = Propagation.NESTED)

    public void doOtherThing() {

        System.out.println("保存role表数据");

    }

}

这种情况使用了嵌套的内部事务，原本是希望调用roleService.doOtherThing方法时，如果出现了异常，只回滚doOtherThing方法里的内容，不回滚 userMapper.insertUser里的内容，即回滚保存点。。但事实是，insertUser也回滚了。

why?

因为doOtherThing方法出现了异常，没有手动捕获，会继续往上抛，到外层add方法的代理方法中捕获了异常。所以，这种情况是直接回滚了整个事务，不只回滚单个保存点。

怎么样才能只回滚保存点呢？

@Slf4j

@Service

public class UserService {



    @Autowired

    private UserMapper userMapper;



    @Autowired

    private RoleService roleService;



    @Transactional

    public void add(UserModel userModel) throws Exception {



        userMapper.insertUser(userModel);

        try {

            roleService.doOtherThing();

        } catch (Exception e) {

            log.error(e.getMessage(), e);

        }

    }

}

可以将内部嵌套事务放在try/catch中，并且不继续往上抛异常。这样就能保证，如果内部嵌套事务中出现异常，只回滚内部事务，而不影响外部事务。

三 其他

1 大事务问题

在使用spring事务时，有个让人非常头疼的问题，就是大事务问题。

通常情况下，我们会在方法上@Transactional注解，填加事务功能，比如：

@Service

public class UserService {

    

    @Autowired 

    private RoleService roleService;

    

    @Transactional

    public void add(UserModel userModel) throws Exception {

       query1();

       query2();

       query3();

       roleService.save(userModel);

       update(userModel);

    }

}





@Service

public class RoleService {

    

    @Autowired 

    private RoleService roleService;

    

    @Transactional

    public void save(UserModel userModel) throws Exception {

       query4();

       query5();

       query6();

       saveData(userModel);

    }

}

但@Transactional注解，如果被加到方法上，有个缺点就是整个方法都包含在事务当中了。

上面的这个例子中，在UserService类中，其实只有这两行才需要事务：

roleService.save(userModel);

update(userModel);

在RoleService类中，只有这一行需要事务：

saveData(userModel);

现在的这种写法，会导致所有的query方法也被包含在同一个事务当中。

如果query方法非常多，调用层级很深，而且有部分查询方法比较耗时的话，会造成整个事务非常耗时，而从造成大事务问题。

关于大事务问题的危害，可以阅读一下我的另一篇文章《让人头痛的大事务问题到底要如何解决？》，上面有详细的讲解。

更多精彩内容百度一下：Java突击队

2.编程式事务

上面聊的这些内容都是基于@Transactional注解的，主要说的是它的事务问题，我们把这种事务叫做：声明式事务。

其实，spring还提供了另外一种创建事务的方式，即通过手动编写代码实现的事务，我们把这种事务叫做：编程式事务。例如：

   @Autowired

   private TransactionTemplate transactionTemplate;

   

   ...

   

   public void save(final User user) {

         queryData1();

         queryData2();

         transactionTemplate.execute((status) => {

            addData1();

            updateData2();

            return Boolean.TRUE;

         })

   }

在spring中为了支持编程式事务，专门提供了一个类：TransactionTemplate，在它的execute方法中，就实现了事务的功能。

相较于@Transactional注解声明式事务，我更建议大家使用，基于TransactionTemplate的编程式事务。主要原因如下：

建议在项目中少使用@Transactional注解开启事务。但并不是说一定不能用它，如果项目中有些业务逻辑比较简单，而且不经常变动，使用@Transactional注解开启事务开启事务也无妨，因为它更简单，开发效率更高，但是千万要小心事务失效的问题。

HTTP状态码：从请求的一生重新理解

“所有数字背后，都是一个请求的遗言。”

—— 某位被502逼疯的工程师

或者，你也可以记住这一句：

“状态码不是用来背的，是用来收尸的。”

—— 同一位工程师，在又一次凌晨三点被叫起来之后

为什么写这篇文章

相信很多朋友面试的时候都会被面试官问到：“你记得多少HTTP状态码？具体有哪些含义？”

一般对于这类问题，我们都会提前复习和记忆，才能回答得比较完整。

但后来我发现一件事：

“背状态码就像背尸检报告，你记住了死因，却没见过现场。”

—— 某位靠背答案转行写代码的面试者

本文从一个请求离开客户端之后的链路出发，带你去看现场。

要彻底搞懂HTTP状态码，我们可以换一种思路：设计这么多状态码，它们具体是在哪一环节、因为什么原因被返回的？

我们的请求传递到整个后端，并不是直接访问到服务器。它要经过一大批网络组件的筛选过滤，每一关都有可能倒下，每一关都会有人替它写下遗言。

下面，让我们从一个请求发送到后端的链路，重新认识一下HTTP状态码。

第一站：边缘节点 CDN

“我以为我能活到源站，结果在门口就被拦下了。”

—— 一个试图直接访问服务器的请求

当一个请求经过DNS解析离开设备，遇到的第一个网络组件是CDN。

CDN是一种缓存设备。它把源服务器的资源拉取到离你最近的地方，像个热情过度的前台：“你要这个？我这有，别往里跑了。”

遇到热门的资源文件（比如B站、抖音的热门视频），直接从CDN获取，速度远远快于访问远端的服务器。对于这些占用带宽较大的静态文件资源，缓存到CDN上是性价比最高的方案。

CDN节点状态码

💡 304是个好东西

每次向CDN发起请求，并不一定需要CDN把整个文件再发一遍。

如果我们本地有缓存，带着文件的指纹（ETag）或修改时间（Last-Modified）去问CDN：“我这个还新鲜吗？”

CDN看一眼：“没变，接着用吧。”

省带宽，省时间，双方都舒服。

—— 这是唯一一个**请求和服务器达成共识“你不用干活”**的状态码。

第二站：安全网关 WAF

“我不是不让你进，我是怕你进来搞破坏。”

—— WAF，一个没有感情的安检机器

请求离开CDN后，仍然不能直接到达源站。它先要经过WAF——Web应用防火墙。

这个组件的作用，名字已经写得很清楚：为了安全。

它像个眼神锐利的保安，把你从头扫到脚：

WAF状态码场景

这些“不正经”的请求方式，其实就是网络安全课里讲的攻击手段。

“我只是想进来看看，它说我是黑客。”

—— 一个带着正常User-Agent却被误杀的公司内网爬虫

第三站：负载均衡器 Nginx

“一万个用户就要一万个进程？凭什么等网速还要占着位置？”

—— Igor Sysoev，Nginx之父，2002年

对于这个组件，一开始我也不明白它为什么有那么多功能。

要认识一件东西，最好的方式是了解它为什么被创造出来。

2002年，莫斯科。

Apache的规矩：来一个人开一个进程，来一万个人开一万个进程。

16G内存，Apache张嘴要50G，然后跪了。

Igor Sysoev每天的工作就是重启服务器——像给同一个病人反复做心肺复苏。

终于有一天他骂了句脏话：

“一万个用户就要一万个进程？凭什么等网速的时候还要占着内存？”

他觉得这不合理——像每个客人身后站一个专属服务员，客人上厕所他都得站着等。

Igor决定写一个“不讲武德”的服务器：

一个服务员管五十桌，谁招手过去，谁看菜单就晾着。不等人，不空转，不占茅坑。

两年，一万行C。

2004年，Nginx诞生。

4个进程扛1万连接，内存500MB。

Apache用50G干的活，它用1%的资源。

后来有人问他为什么写Nginx。

他说：

“等的时候，不应该占着位置。”

Nginx核心状态码

💡 关于499

499是Nginx独有的状态码。

它不是后端返回的，不是WAF拦截的，是Nginx自己记下的遗言：

“他没等我，他走了。”

很多时候你以为的超时（504），其实是用户等得不耐烦，直接关掉了页面。

Nginx默默在日志里写下一行：
“请求已转发，但客户端已失联。”

第四站：Web 应用

“终于到我了。”

—— 一个请求，在穿过CDN、WAF、Nginx之后

终于，请求到达了后端应用。

这里的HTTP状态码，是开发者在代码里亲手写下的。

它是唯一一个由你决定生死的环节。

4xx：你的问题，不是我的问题

“你发过来的东西，我尽力了，真的看不懂。”

—— 应用对400说

“你说你叫admin，但我这已经有叫admin的了。”

—— 409 Conflict，注册接口的日常