Yibin’s Blog https://yibin.dev/ 记录与分享🧀 Tue, 16 Jun 2026 16:00:41 GMT https://validator.w3.org/feed/docs/rss2.html https://github.com/jpmonette/feed zh-CN All rights reserved 2026, Yibin <![CDATA[一条配置查询，搞瘫了整个服务]]> https://yibin.dev/article/37960b50-99a4-80a3-b385-deff53e32068 https://yibin.dev/article/37960b50-99a4-80a3-b385-deff53e32068 Mon, 08 Jun 2026 00:00:00 GMT
那天下午，监控突然炸了。
核心服务在短时间内批量报 QueryTimeoutException。我打开日志一看，满屏都是同一类错误：
三个数字一模一样：active 16，maxActive 16，runningSqlCount 16。连接池被打满了，一个不剩。
更诡异的是，报错的 SQL 五花八门：查用户订阅的 COUNT、查红点状态的 SELECT、查用户标签的查询……看起来毫无关联的业务全部超时。
出问题了。但问题不在这些报错的 SQL。

1. 先找谁占住了连接

连接池只有 16 个连接。既然全部被占，那一定有人在占着不放。
我把每条超时异常的 Cause 链追到底，发现真正占住连接的，始终是同一条 SQL：
一条配置查询，把 16 个连接全部霸占。其余所有业务查询排队等 5 秒后超时，形成连锁故障。
这就怪了。配置查询按理说应该是毫秒级返回的东西，怎么会把连接占住不还？
先还原一下调用链路。故障涉及两个服务：
正常流程不复杂：上游消费 MQ 消息，先查本地缓存，命中直接返回；没命中就 RPC 调下游查库，再写缓存。
看起来挺合理。但就是这个看起来合理的链路，藏了三个问题。
notion image
图 1：调用链路与三个隐藏问题。

2. 第一个问题：查询根本没走索引

我先去看了 config_table 的索引结构：
索引
列
PRIMARY KEY
id
UNIQUE KEY
(code, category_id)
表上有个联合唯一索引 (code, category_id)。但查询条件是 WHERE category_id = ?，没有带 code。
根据 MySQL 最左前缀原则，这个联合索引的最左列是 code。只查 category_id 不走索引，每次都是全表扫描。
表数据量小的时候，全表扫描也无所谓，几毫秒就过了。但数据量涨上去以后，一条本应毫秒级返回的查询变成了秒级操作。而这期间，数据库连接一直被占用。
不过到这里我还有一个疑问：就算全表扫描要几秒钟，那也就占一个连接吧？为什么 16 个连接全部被同一类 SQL 占满？
 
notion image
图 2：联合索引 (code, category_id)，跳过 code 直接查 category_id 不走索引。

3. 第二个问题：SELECT * 拉了大字段

我接着看了下表结构。config_table 里有一个 TEXT 类型的 detail 字段，存的是大段 JSON 配置，动辄几十 KB。
而查询代码是这样的：
没有用 .select() 限定列，默认查全部字段。全表扫描，加上每次拖几十 KB 的 TEXT 大字段，单条查询比正常慢了不止一倍。
慢上加慢。
但这也说不通。慢 SQL 再慢，如果并发量不高，也不至于把整个连接池打满。一定还有东西在放大并发。

4. 第三个问题：缓存击穿

继续往上追，我看到了上游服务的缓存代码：
看到 getIfPresent() + 手动 put() 这个组合，我心里咯噔了一下。
这个写法不是原子操作。15 分钟 TTL 到期那一瞬间，50 个线程同时走到 getIfPresent()，全部拿到 null。然后全部穿透到 RPC，全部打到数据库。
而且上游有多个实例，每个实例的 Caffeine 缓存独立，过期时间接近。也就是说多个实例几乎同时发生缓存失效，压力被进一步放大。
到这里，故障的全貌就清楚了。
notion image
图 3：缓存击穿——TTL 到期瞬间，所有线程同时穿透到数据库。

5. 把时间线拼起来

三个问题串在一起，时间线是这样的：
不到 5 秒，一条配置查询搞瘫了所有业务。
这三个问题，单独拿出哪一个都不算致命。索引缺失让查询变慢，SELECT * 让查询更慢，缓存击穿让慢查询并发暴增。三者叠加，一次普通的缓存过期就变成了全站雪崩。
notion image
图 4：从缓存到期到全站雪崩，不到 5 秒。

6. 怎么修

P0 止血三件事：
第一，加索引。 这是最根本的一刀。
全表扫描变索引查找，查询时间从秒级降到毫秒级。单条查询不慢了，后面的问题就算还在，影响面也大幅缩小。
第二，修缓存击穿。 Caffeine.get(key, loader) 对同一个 key 内部加锁，只有一个线程执行加载逻辑，其余线程等结果。彻底消除惊群效应。
第三，限定查询列。 不查不需要的 TEXT 大字段。
P1 加固两件事。一是连接池 maxActive 从 16 调到 50，提高容错水位。二是下游服务也加一层缓存——配置数据变化极低频，不应该每次 RPC 都查库。

7. 回过头看

这次复盘让我重新理解了"防御性编程"这五个字。
以前我觉得防御性编程就是处理好异常、写好单元测试、加好降级逻辑。但这次的问题，没有一个环节是"异常"的——索引没报错，SQL 没报错，缓存没报错，连接池也没报错。每个组件都在按设计工作，但合在一起，炸了。
防御性编程真正的含义，不是处理已知的异常，而是假设每个环节都可能出问题，然后确保问题不会扩散。
notion image
图 5：三个单独看都不致命的问题，叠加在一起就是全站雪崩。
具体到这次，我觉得有几条值得记住：
  • 写查询前先看索引。 不是写完再补，是写之前就确认能走什么索引。联合索引的列顺序，决定了你的查询能不能用上。
  • SELECT * 在有 TEXT/BLOB 字段的表上是定时炸弹。 尤其是通过 RPC 传输的场景，大字段的代价每一跳都在放大。
  • getIfPresent + put 在高并发下等于没缓存。 用 get(key, loader) 或者分布式锁，别自己手动作缓存加载。
  • 连接池是所有业务共享的资源。 一条慢 SQL 可以拖垮整个服务。多实例本地缓存不共享，N 个实例就是 N 倍穿透压力。
故障的本质很少是单一原因。往往是几个"不大"的问题，在某个时间点刚好凑到一起，一个引爆另一个。你能做的不是消灭所有问题——那不可能。你能做的是，别让一个小问题有扩散成全站雪崩的机会。
]]> <![CDATA[AI 生成的代码有 bug，修还是重来？我的三层判断法]]> https://yibin.dev/article/37860b50-99a4-801d-aba4-c846cacf36bf https://yibin.dev/article/37860b50-99a4-801d-aba4-c846cacf36bf Sun, 07 Jun 2026 00:00:00 GMT
最近和团队其他深度使用AI的同事聊到一个很有意思的问题。
AI 生了一段代码，大部分能跑，但有几个 bug。这时候你怎么选——手工修掉？继续写 prompt 让 AI 改？还是直接把这段代码回滚，重新生成？
每个人反应都不太一样。有的人习惯手工修，有的人第一反应是追问 AI，有的人直接回滚重来。
用了大半年 AI Coding 之后，我慢慢摸索出一套自己的判断标准。核心就一件事：先判问题大小，再决定怎么动手。
我把问题分成三层。
notion image

第一层：小问题，手工修

什么叫小问题？空指针没判、标签没闭合、变量名写错了——这种一眼能看穿的。
这类 bug 我从不写 prompt。为什么？因为写 prompt 描述问题的功夫，你已经修完了。
你想想这个过程：你得把 bug 现象描述清楚 → 等 AI 生成 → 看改没改对 → 可能还得再调一轮。一个空指针，手动改 5 秒。走一轮 prompt，至少两分钟。这笔账太好算了。
小问题的判断标准很简单：你一眼就知道哪里错了，而且你知道怎么改。
这种情况还去写 prompt，不是用好 AI，是被 AI 绑架。时间浪费了，token 也白烧。

第二层：中等问题，看熟悉度

这是最纠结的一层。
比如边界条件没处理、并发逻辑有问题、异常路径没覆盖——不是一眼能看穿的 bug，但也不是架构级的硬伤。
遇到这种，我的判断标准是两条：
第一，这块代码我熟不熟？ 熟的话，大概率手工修。因为我知道改哪里、怎么改、改完会影响什么。不熟的话，可以尝试一两轮 prompt。
第二，是不是核心链路？ 如果是支付、鉴权这种高危模块，我更倾向于手工修——出了问题你没法跟领导说"这是 AI 写的"。如果是边缘功能，让 AI 改一两轮问题不大。
但这里有个坑，我重点说一下。

最大的坑：追问死循环

中等问题上，最容易犯的错是无底线追问。
修了 A，AI 给你冒出 B。修了 B，冒出 C。修完 C 回头一看，A 又坏了。
为什么？因为 AI 在迭代修改时会继承错误的上下文。你每追问一轮，prompt 里就多一层历史包袱。改到第三四轮的时候，AI 已经在垃圾堆上盖房子了。
notion image
这时候有一个办法可以试：换模型。
不同模型擅长的领域真的不一样。我自己的体感，DeepSeek V4 Pro 在处理一些逻辑推理和数据处理类的代码上很灵光，但遇到复杂架构设计或者需要深度理解业务上下文的任务，就容易跑偏。反过来，MiniMax-M3 在某些领域很稳，但换到 DeepSeek 擅长的那类问题，表现又不太够看。
这不是玄学。每个模型训练时喂的数据不一样，推理的路数也不一样，舒适区天然不同。你在这个模型上追了 3 轮还转不出来，不一定是你 prompt 的问题，可能就是这个模型不擅长这类任务。换个模型，同样的 prompt，一遍就过了。
所以遇到追问两三轮还没搞定的时候，别死磕。切到另一个模型试试，有时候比改 prompt 更管用。
如果换了模型还不对，那问题大概率不在模型上。我的止损线很明确：追 3 轮还不对，立刻回滚，重新写 prompt 生成整个功能。
这话说起来简单，做起来难。因为人都有沉没成本心理——"我已经花了半小时修了，现在回滚不是白费了？"
但实际情况是，你继续追下去，可能再花一小时，最后还是得回滚。
我见过最典型的案例：一个同事修了一下午的 AI 代码，来回追了七八轮，最后烦了，回滚重写 prompt，10 分钟搞定。前面那三小时，全是"不舍得"的代价。

第三层：大问题，果断回滚

代码分层不对、整体设计方向跑偏、或者 AI 理解错了需求——这种叫大问题。
大问题不要修，不要追，直接回滚。因为根是歪的，修再多枝叶都没用。
重新生成之前，把 prompt 里的歧义清掉。很多时候 AI 写偏了，不是它不行，是你没说清楚。把需求拆细、把约束写明、给一两个正反例——第二次出来的东西通常好很多。

判断问题大小，本身就是能力

这套三层判断法说起来不复杂，但执行起来有个前提：你得能快速判断一个 bug 属于哪一层。
这个判断力不是天生的。你得对你用的语言、框架、业务逻辑有一定熟悉度，才能在一两分钟内做出判断。
有些同学一看到 bug 就开始追着 AI 改，改到一半才发现是个大问题。等反应过来，时间已经烧掉了。有这个时间，自己修早完事了。
这就是 AI Coding 里很微妙的一点：AI 省的是"写"的时间，不是"判"的时间。 判断还得靠人。
练多了之后，你会形成一种直觉——看到 bug 的第一反应不是"让 AI 修"，而是"这是哪类问题"。到这个状态，人机协同的效率才算真正上来了。

最后

我们团队近期达成了个共识：AI 能不能搞定一个项目，不看项目复杂度，不看代码量，看验证成本。
什么叫验证成本？就是 AI 生成完代码之后，你验证它对不对要花多少时间。验证成本低的（比如跑个测试就完事），AI 可以放开用。验证成本高的（比如核心支付逻辑，错了就是事故），人必须盯紧。
所以回到最开始的问题：AI 生成的代码有 bug，修还是重来？
答案不是绝对的。但它取决于你的判断，不取决于 bug 本身。人机协同，人判机写。判在前，写在后面。
]]> <![CDATA[四个装机脚本，新机到手十分钟搞定]]> https://yibin.dev/article/20560b50-99a4-8067-8119-cc2a5ce8455a https://yibin.dev/article/20560b50-99a4-8067-8119-cc2a5ce8455a Sat, 06 Jun 2026 00:00:00 GMT

四个装机脚本，新机到手十分钟搞定

每次拿到一台新 VPS 或者重装系统之后，有四件事几乎必做——换源、装环境、跑测评、开虚拟机。这四个脚本一直在用，一条命令搞定，不折腾。
我们一个一个说。

换源：LinuxMirrors

notion image
新机到手第一件事是什么？换源。
不换源的后果很直接：apt 或 yum 下载速度几十 KB/s，装个 Docker 能等十分钟。换了阿里或清华源，同样的操作十秒完事。
LinuxMirrors 是目前覆盖最广的换源脚本。支持 26 个发行版，从 Debian 8 到 Ubuntu 26，CentOS 7 到 Fedora 44。甚至 Arch、Gentoo、NixOS、openKylin 这些偏门发行版都覆盖了。
一条命令：
脚本会自动检测你的系统，然后列出可用的国内镜像源让你选。不用记任何参数。
还有两个加分项：
第一，它自带 Docker 安装和换源。装 Docker 的同时帮你把镜像加速器也配好，不用再去 /etc/docker/daemon.json 里手写。如果 Docker 已经装好了，加 --only-registry 参数只换源：
第二，提供轻量版脚本。如果你的机器内存紧张或者网络很差，用 Lite 版更稳。
GitHub 7.6k stars，不算多，但对这个品类来说已经是最高的了。

系统修复与环境安装：one-click-installation-script

notion image
换完源之后，通常还有一堆零碎事要做：修时间、配网络、装开发环境。
这套脚本的作者 SpiritLHL 把常见的修复和安装操作打包成了一个工具箱。每个脚本独立，按需跑。
修复类的几个高频场景：
  • apt 源锁死或公钥缺失 → 一条命令修好
  • 系统时间不准 → 自动装 chronyd 同步
  • 纯 IPv6 机器没网络 → 加 nat64 通道
  • journal 日志撑爆磁盘 → 自动调大小
环境安装类的：
  • Jupyter 环境（Miniconda3 + JupyterLab，适合按小时计费的 GPU 机器）
  • Go、Rust、C++ 开发环境
  • vnstat 流量监控
  • FileBrowser（Web 文件管理器，端口 3030）
还有一个挺实用的：一键卸载云服务器自带的监控 agent。阿里云、腾讯云、华为云、甲骨文、UCloud、京东云都支持。买过国内 VPS 的都知道，这些监控 agent 默认挂着，吃资源不说，看着就烦。
用法很直接，需要哪个跑哪个。比如修 apt 源：
卸云监控：
国内机器把 raw.githubusercontent.com 换成 cdn.spiritlhl.net/https://raw.githubusercontent.com 走 CDN 加速。

跑分测评：融合怪

notion image
机器到手，环境装好，下一步该干嘛？跑个分看看这机器到底几斤几两。
融合怪（ecs）是目前 VPS 圈最常用的综合测评脚本。每次买新机都会跑一遍，看看商家有没有虚标。
它把 bench.sh、superbench、yabs、LemonBench 这几个主流工具的测试项整合到了一起，自己优化了不少细节。你可以只跑单项，也可以一键跑全套。不用挨个找脚本。
测什么：
  • 系统信息：CPU 型号、内存、磁盘、虚拟化类型、NAT 类型
  • CPU 跑分：默认 sysbench，可选 Geekbench 4/5/6
  • 内存和磁盘 I/O：DD 快速测 + FIO 精准测
  • 流媒体解锁：Netflix、Disney+、TikTok（两个版本交叉验证）
  • 三网回程路由：电信、联通、移动各线路延迟
  • IP 质量检测：15 家黑名单数据库查询，含 DNS 黑名单
  • 邮件端口 25 是否开放（能不能搭邮局）
  • Speedtest 三网测速
跑完之后自动上传结果到 pastebin，给你一个分享链接。同时本地也会保存一份 test_result.txt。
一条命令：
跑完全套大概 10-15 分钟。想省时间的话，跑交互模式，只勾自己关心的项目。

开虚拟机：PVE 一键部署

notion image
如果你用的是 Proxmox VE，这个脚本能省大把时间。
oneclickvirt/pve 做的事情很简单：在 PVE 上一键创建虚拟机或容器，支持 KVM 和 LXC 两种虚拟化。可以单独开一台，也可以批量开。CPU 核数、内存大小、磁盘容量、网络配置，全都通过环境变量控制。
比如批量开 3 台：
不需要交互，全程自动跑完。
支持的系统也很全：Linux、Windows、macOS、Android 都能装。ARM64 和 AMD64 都兼容，包括 riscv 也在陆续适配。
内外网端口转发和 NAT 也是自动配好的。开完就能用，不用再去防火墙里手动加规则。
这个脚本跟上面三个同属 SpiritLHL 的生态。跟融合怪测评脚本配着用刚好——新机器开出来，跑一遍融合怪，看看性能有没有问题。
具体用法和命令在配套文档站 virt.spiritlhl.net 上，PVE 分区的说明很详细，照着跑就行。

总结

四个脚本，覆盖了新机到手到正式用起来的主要环节：
脚本
做什么
一句话
LinuxMirrors
换源 + Docker
新机第一件事
one-click-installation-script
系统修复 + 环境安装
零碎事按需跑
融合怪 ecs
跑分测评
看看机器几斤几两
PVE 一键部署
开虚拟机
PVE 用户必备
建议收藏，下次重装系统的时候翻出来直接复制粘贴。
如果只装一台机器，手动敲一遍也无所谓。但如果经常折腾 VPS，或者一次要搞好几台，这四个脚本能帮你从半小时压到五分钟。
]]> <![CDATA[fastjson2 丢字段：不是 reader 吞了字段，是 writer 写错了路]]> https://yibin.dev/article/36960b50-99a4-808b-a32b-dbe53793c66a https://yibin.dev/article/36960b50-99a4-808b-a32b-dbe53793c66a Sat, 23 May 2026 00:00:00 GMT
前面的排查文章【线上 4 个 RPC 参数丢了 3 个字段，到底谁干的】已经把问题收敛到了 fastjson2。
当时我用一个最小的 Dubbo provider + consumer 工程，把线上路径复现出来。结论也很明确：锅不在业务代码，也不在 Dubbo 业务层本身，而是在 Dubbo 最终选中的 fastjson2 序列化路径。
但只说“问题落在 fastjson2”还不够。
下一步不能继续盯着 Dubbo 看了。Dubbo 在这条链路里更像一个把请求送到 fastjson2 的壳。真正要确认的是：把 Dubbo 完全拿掉，只保留它调用 fastjson2 时那组 writer / reader features，纯 JSONB 还能不能独立复现。
这篇我想把 4 件事讲清楚：
  1. 纯 JSONB 最小实验怎么搭。
  1. fastjson2 的写端和读端，分别在哪一步把问题坐实。
  1. 为什么最后应该修写端，不修读端。
  1. 我提给 fastjson2 的 PR，到底改了什么。

1. 先把 Dubbo 拿掉，只保留它那组 features

前一轮排查已经说明：Dubbo 在这条路径里更像调度员。它决定选哪个序列化实现，也决定调用 fastjson2 时带哪组 features。
那现在最干净的验证方式，就是把 Dubbo 拿掉，只保留这组 features。
最小实验核心代码是这样的：
再准备两组数据：
  • 一组让 4 个 StatusQuery 共享同一个 statusCodeSet
  • 一组让每个 StatusQuery 各自 new HashSet<>(codeSet)
最后直接跑：
这里有两个点值得先说。
第一，我故意传了完整泛型 TypeReference<Set<StatusQuery>>()，不是裸 Set.class。因为我想先把“泛型擦除”这个嫌疑人摘掉。既然前面已经怀疑它不是根因，这里干脆先把条件给足。
第二，这里直接复用了 Dubbo 3.2.0 在 FastJson2ObjectOutput / FastJson2ObjectInput 里实际打开的 features。这样跑出来的结果，才有资格和 Dubbo 线上路径放在一起比较。
notion image
图 1：Dubbo 被拿掉后，只保留 fastjson2 features，问题仍然复现。

2. 先看运行结果，再谈源码

最关键的 baseline 输出是这样：
Dubbo 已经不在场了，但结果和线上一模一样：还是“1 个完整，3 个 null”。
再把几组对照一起放出来，问题就更清楚：
场景
外层容器
statusCodeSet
结果
A
HashSet
共享
1 完整 + 3 null
B
HashSet
独立
4 完整
C
LinkedHashSet
共享
1 完整 + 3 null
D
LinkedHashSet
独立
4 完整
这一步已经足够把第一层结论坐实：
只要保留 Dubbo 那组 fastjson2 features，这个问题不需要 Dubbo 也能独立复现。

2.1 先排除一个很容易误判的点

如果你直接看 JSONB.toJSONString(bytes)，会看到一种很别扭的输出：
这个输出很容易把人带偏，以为“写端把同一个字段写了两次”。
但这其实不是根因，而是 JSONBDump 的打印问题。
JSONB.toJSONString(bytes) 底层会把 JSONB 字节流 dump 成一段方便人看的 JSON。它在 dumpObject 里遇到 BC_REFERENCE 时，先把引用打印成了 {"$ref":"..."}；但这个分支结束后，又继续落到外层通用逻辑里，补了一次“写冒号 + 再读下一个值”。
所以你看到的像是：
真实字节流不是这样。
真实的 JSONB 字节流里，field name 没有被写两遍。这个误判先摘掉，后面的源码才不会看歪。

3. 先看写端：$ref 是怎么写出来的

这次问题的第一刀，要先落在 writer。
因为只要你看到“共享引用 + ReferenceDetection”，就该问一句：writer 到底把第二次、第三次出现的对象写成了什么。

3.1 第一次出现时，writer 会先登记路径

fastjson2 开了 ReferenceDetection 以后，第一次遇到对象，不是简单写完就算了。它还会把这个对象和当前路径登记起来。
在这个场景里，第 1 个 StatusQuery.statusCodeSet 首次出现时，大概会走到类似这样的逻辑：
这一步的意思是：把“这个对象现在在什么路径下”记住。后面再碰到同一个对象实例，就可以不重复写值，而是直接写引用路径。
问题也从这里开始露头。
setPath(fieldWriter, value) 记录的是字段路径。放在普通 Bean 里，它很好理解；放在 List 的第 0 个元素里，也还能拼出 $[0].statusCodeSet 这种可求值路径。
但外层如果是 HashSet，writer 此时没有一个稳定的“第几个元素”可以用。于是第一次登记出来的路径就变成了 $.statusCodeSet。
这条路径看起来短，实际上危险。

3.2 第二次开始，不再内联写值，而是写 $ref

后面第 2、3、4 个 StatusQuery 再遇到同一个 HashSet<String> 时，FieldWriterObject.writeInternal(...) 就不会再完整写内容了，而是走 $ref 分支。
源码里的判断大致可以理解成这样：
也就是说，只要 writer 判断“这个对象之前见过”，就直接把之前登记的路径写出去。
在这个场景下，最终写出来的几种路径是：
  • 外层是 HashSet 时：$.statusCodeSet
  • 外层是 LinkedHashSet 时：$[0].statusCodeSet
  • 后续相对引用：#-1
这几个路径里，最危险的是第一个。
$.statusCodeSet 看上去像在说：“从根节点拿到 statusCodeSet 这个字段。”
但根节点是谁？不是 StatusQuery，而是外层那个 HashSet<StatusQuery>。
HashSet 根本没有 statusCodeSet 这个属性。
换句话说，writer 这时候已经埋下雷了：它写出了一个以 Set 为根、但根本不适合在 Set 上求值的路径。
notion image
图 2：第一次出现时 writer 登记路径，后续共享引用直接写 $ref。问题在于这个路径对 HashSet root 不成立。

3.3 为什么 LinkedHashSet 也没活下来

有人看到这里会说：那 LinkedHashSet 写成 $[0].statusCodeSet，不是合理多了吗？
表面上是。
但这只是“看起来更合理”，不等于 reader 一定能按原意解回来。因为这件事还要看读端把 root 建成了什么。这个坑要放到下一节一起看。

4. 再看读端：为什么这些路径解不回来

如果 writer 的问题是“写出了坏路径”，那 reader 的问题就是“它到底是在哪一步解不回来”。

4.1 读端最后会把 $ref 任务攒起来，再统一 resolve

fastjson2 反序列化时，不会在第一次读到 $ref 的那一刻立刻把所有字段补齐。它会先记一笔待回填任务，等对象树大致建好以后，再在 JSONReader.handleResolveTasks() 里统一处理。
核心逻辑可以粗暴理解成：
问题就出在这里的 root。

4.2 $.statusCodeSet 在 HashSet root 上根本求不出值

当 root 是外层的 HashSet<StatusQuery> 时：
  • $.statusCodeSet 的含义是“去根节点上找 statusCodeSet 字段”
  • 但 HashSet 根本没有这个字段
于是这条路径天然求值失败。reader 不是把一个正确路径解错了，而是根本拿到了一条不可能在当前 root 上成立的路径。
这也是为什么我说这次问题的本质更偏向 writer：reader 处理的是一条它自己也无法成立的路径。
notion image
图 3：reader 最后会对 root 执行 path.eval(root)。当 root 是 HashSet 时，$.statusCodeSet 没有求值对象。

4.3 LinkedHashSet 之所以也失败，是因为读回来时 root 还是 HashSet

外层换成 LinkedHashSet 后，writer 写的是 $[0].statusCodeSet。这个路径只有在 root 是有稳定索引语义的容器时，才真正有意义。
但实际实验里，reader 侧拿到的外层容器是 HashSet，不是 LinkedHashSet。
也就是说：
  • writer 以为自己在给一个“有顺序”的容器写路径
  • reader 最后却在一个没有稳定索引语义的 HashSet 上做 path.eval(root)
那 $[0] 还能不能稳定落到 writer 以为的第一个元素上？答案是不行。
这也是为什么 LinkedHashSet 这组实验看起来更像是“差一点就好了”，但最后结果还是“1 完整 + 3 null”。

4.4 为什么 List 没事，Set 不行

这也是我最后没有全局禁用 ReferenceDetection 的原因。
如果外层是 List<StatusQuery>，writer 写出来的路径通常是 $[0].statusCodeSet。读端拿到的 root 也是 List，$[0] 能先定位到第 1 个元素，再继续取 .statusCodeSet。
这条路径能成立，所以 List 场景本来就是健康的。
Set 不一样。
HashSet 没有稳定下标。$.statusCodeSet 在 HashSet root 上也没有意义。LinkedHashSet 虽然有迭代顺序，但反序列化后 root 未必还能按 writer 想象的方式提供 $[0] 语义。
所以这次问题的边界不是“JSONB 共享引用都坏了”，而是更窄：
外层是非 List 集合，元素内部又共享了同一个对象，writer 还打开了 ReferenceDetection。
notion image
图 4：List 有稳定下标，$[0].statusCodeSet 能成立；Set 没有稳定下标，$.statusCodeSet 在 root 上也不成立。

4.5 到这里，又能顺手排掉两个误判

第一，完整泛型 Type 也救不了。
这次纯 JSONB 实验里，我已经传了完整的 TypeReference<Set<StatusQuery>>()。问题照样复现，所以“泛型擦除”不是必要条件。
第二，UseNativeObject 也不是必要条件。
我单独做过一组实验，把 reader 的 UseNativeObject 去掉，结果还是“1 完整 + 3 null”。这说明它确实会放大 LinkedHashSet 那条路径的问题，但不是这次 bug 的根开关。
到这里，触发这个问题的最小条件其实已经很清楚了：

5. 为什么最后修写端，不修读端

把根因钉到这里以后，摆在我面前其实有 3 条路。
方案
思路
主要问题
改读端
让 reader 对 Set 这类容器做更复杂的 resolve
改动面大，要碰 resolve 生命周期和 hash 容器行为
改写端
非 List 集合场景下，不再为元素内部共享引用生成 $ref 路径
共享对象会内联，字节流变大
全局禁用
一刀切关掉 ref detection
太粗暴，会伤到本来没问题的 List 路径
我最后选的是第二条：修写端，不修读端。
原因有两个。

5.1 直接问题在写端

这次最直接的问题，不是 reader 无缘无故把一个好好的字段吞掉了。
而是 writer 先写出了一条在当前 root 上根本不成立的路径。
既然坏路径从这里开始，那最小修法就应该优先瞄准这里。先别让 writer 再写出这种路径。

5.2 读端真要修，会牵出更大的坑

读端不是不能修，而是会修得很重。
因为一旦你想在 reader 侧“帮忙把 Set 上的引用回填好”，马上就会碰到另一个问题：HashSet 这类容器依赖元素的 hashCode()。
如果对象在“字段还没回填完成”的状态下就已经被 add 进 HashSet，后面再去补字段，理论上就可能破坏 hash 容器的不变量。
这不是假想出来的复杂度。
fastjson2 读 $ref 时，会先把回填任务记下来。
等元素已经进了集合，再统一跑 handleResolveTasks()。
如果 StatusQuery.hashCode() 又依赖 statusCodeSet，那就会出现一个尴尬局面：
  1. 先按 statusCodeSet = null 的状态算 hash，把对象放进 HashSet。
  1. 后面 resolve 成功，又把 statusCodeSet 回填成一个非空集合。
  1. 对象的 hash 变了，但它在 HashSet 里的桶位没跟着重排。
这已经不是“补一条 resolve 规则”那么简单了。它会把你拖进更大的读端改造里：先缓冲元素、等引用全部回填完再 addAll、必要时重建容器、还要考虑对象稳定性。
所以我的判断很明确：这次应该先用写端的小修，堵住一个写端先制造坏路径的问题，而不是为了补读端，把动刀范围扩大一圈。

6. PR 到底改了什么

最后补丁落在：
核心思路很简单：
  1. 进入集合写出逻辑时，先判断外层是不是 List
  1. 如果不是 List，并且当前 context 开着 ReferenceDetection
  1. 那就在写元素期间临时把这个 feature 关掉
  1. 写完再用 try/finally 恢复原来的 context
关键代码大致是这样：
然后把原来的元素遍历包进 try/finally 里，结束后再恢复。
这个补丁的意思其实非常朴素：
对外层是非 List 的集合，不要再为元素内部共享引用生成 $ref 路径；直接内联写值。
我没有只对 HashSet 写特判，而是把边界放在“非 List 集合”。因为这次问题的本质，不是某个类名，而是“这类容器没有稳定的数组索引语义”。
这里还有一个实现细节。
我关的不是调用方传进来的 features 数组，也不是永久改掉全局配置，而是临时改当前 JSONWriter.Context 里的 feature bit。写元素前关掉，元素写完后在 finally 里恢复。
这样做有两个好处：
  1. 影响范围只包住这一次非 List 集合的元素写出。
  1. 如果中间抛异常，finally 也会把原来的 context 还回去。
我本地验证时用的是“源文件覆盖”的方式：从 fastjson2 sources jar 里取出 ObjectWriterImplCollection.java，放到测试工程的 src/main/java 同路径下。Maven 编译后，这个 class 会比依赖 jar 里的原版更早出现在 classpath 里，所以不用重打 fastjson2 jar，也能快速验证补丁。
notion image
图 5：外层是非 List 集合时，写元素期间临时关闭 ReferenceDetection，避免生成不可 resolve 的 $ref 路径。

6.1 为什么这个改法能自圆其说

补丁不是只要让一个 case 通过就行。它至少要同时满足两件事：
  1. 原来会炸的 case 现在好起来。
  1. 原来没问题的 case 别被顺手改坏。
所以我本地验证时盯的重点是这 4 组：
用例
修复前
修复后
共享 HashSet
null count = 3/4
null count = 0/4
共享 LinkedHashSet
null count = 3/4
null count = 0/4
关闭 ReferenceDetection 的健康基线
null count = 0/4
null count = 0/4
外层 List 的健康基线
null count = 0/4
null count = 0/4
最后一行尤其关键。
因为它说明这次改动没有把 List 这种本来能正确处理 $ref 的路径一起打坏。补丁的影响面，确实被控制在“非 List 集合元素内部的共享引用”上。
代价也有。
非 List 集合里被共享的对象，会从 $ref 变成内联写出。我的最小用例里，wire bytes 从 217 变成了 373。这不是零成本，但我觉得这个取舍能接受：字节流变大一些，换反序列化结果正确。
notion image
图 6：共享 HashSet 和 LinkedHashSet 从 null count = 3/4 变成 0/4，外层 List 基线保持健康。

6.2 PR 里我放了什么

我最后提给 fastjson2 的 PR 是：
PR 里我刻意把内容收成了 3 件事：
  1. 改动点集中在 ObjectWriterImplCollection.java。
  1. 增加回归测试 SharedReferenceInSetTest.java，覆盖非 List 集合元素里的共享引用场景。
  1. PR 说明里把问题边界写清楚：这是 non-List collection elements + shared reference 的问题，不是泛泛的“JSONB 共享引用都不对”。
我不想把它提成一个“到处都改一点”的大补丁。因为这类问题一旦进开源项目 review，改动范围越大，越难说服 reviewer。
截至现在，这个 PR 还是 open 状态。所以我不会写“某个版本已经修了”。这类结论，得等 merge 和 release 之后再说。

7. 收尾

排查走到这里，我想讲清楚的东西已经够了。
如果只记一句话，我希望是这一句：
这次不是 reader 平白无故把字段吃掉了，而是 writer 先写出了一条 reader 自己也无法成立的路径。
所以最后才会落到“修写端，不修读端”。
完整 demo 我已经整理到 GitHub：
对应的 fastjson2 PR 在这里：
前半段排查解决的是“锅到底在哪”。这次继续往下走，解决的是“知道锅在哪以后，怎么把补丁收得足够小”。
对我来说，这两部分缺一不可。只会把问题指给别人看，不够。只会闷头改代码，也不够。
真正有价值的，是你既能把问题一路收窄到最小路径，也能把补丁收得足够小、足够准，让上游能接得住。

8. 参考资料

 
 
]]> <![CDATA[线上 4 个 RPC 参数丢了 3 个字段，到底谁干的]]> https://yibin.dev/article/36960b50-99a4-804a-9ea2-e0a8c6112c14 https://yibin.dev/article/36960b50-99a4-804a-9ea2-e0a8c6112c14 Thu, 30 Apr 2026 00:00:00 GMT
线上有个 RPC 调用的问题，把我看愣了。
consumer 明明发出去了 4 个完整对象，provider 收到后却只剩 1 个对象还是完整的，另外 3 个对象里的同一个字段全变成了 null。更麻烦的是，整条链路没有异常，没有超时，也没有重试失败。就是静悄悄地坏了。
这类问题最难的地方，不是修，而是先判断锅到底在哪。业务代码有嫌疑，Dubbo 有嫌疑，日志打印方式也有嫌疑。只要中间哪一层没排干净，最后的结论就很容易下错。
说明：本文配图均为自制示意图，用来解释调用链路和定位过程，不对应真实线上界面截图。

1. 问题先摆出来

接口很普通：
一次业务调用里，会传 4 个 StatusQuery。consumer 发包前打印出来是这样的：
provider 刚收到参数时，却变成了这样：
第 1 个对象正常。后面 3 个对象没有 statusCodeSet，等价于 null。
最麻烦的还不是“丢了 3 个字段”，而是整条链路没报任何错。对调用方来说，请求成功了；对下游业务来说，数据已经坏了。这种静默数据损坏，比直接抛异常更难排。
notion image
图 1：consumer 发 4 个完整对象，provider 收到 1 个完整对象和 3 个空字段对象。
当时的环境版本是：
组件
版本
JDK
1.8
Spring Boot
2.7.18
Apache Dubbo
3.2.0
fastjson2
2.0.40
注册中心
Nacos

2. 先止血，但这不算结案

出问题的业务代码，原来是这么构造参数的：
这里的 codeSet 是外面提前 new 出来的同一个 Set<String>。4 个 StatusQuery 指向的是同一个实例。
紧急止血的改法只有一行：
每个对象各拿一份自己的 statusCodeSet，问题立刻消失。
但这个改法只能救火，不能结案。它只说明“共享引用”和问题有关，还说明不了到底是谁把字段吞掉了。
如果这里就停，很容易留下 3 个坑：
  • 以后别的接口也可能继续踩到同一类问题
  • 团队会把锅扣到 DTO、Lombok 或者 HashSet 身上
  • 一旦有人把止血代码改回去，线上还会再炸
所以我没有停在“能跑就行”，而是继续往下收。

3. 先固定现场：Arthas 把证据链补齐

我当时的排查思路很简单：
  1. consumer 发出去之前，参数到底是不是完整的
  1. provider 刚进方法时，参数是不是已经坏了
  1. 如果刚进方法就坏了，那就继续往前看 wire 到底走了什么序列化
先用 Arthas 把 provider 入口和编解码路径盯住：
这几条证据给出的结论很明确：
  • provider 刚进业务方法时，参数已经是“1 个完整 + 3 个字段为 null”了，说明不是业务代码后改坏的
  • CodecSupport.getSerialization(URL) 返回的是 FastJson2Serialization
  • 对应的序列化 id 是 23，也就是 fastjson2
  • decode 栈里能看到 FastJson2ObjectInput.readObject()
继续往前追，关键线索出现在 invoker URL 上：
这一步只能说明一件事：这条 RPC 的 wire，确实按 fastjson2 在编解码。它还不能直接证明“bug 就在 fastjson2”，但 Dubbo 这层的嫌疑已经很重了。

4. 复现不是一次成功的

这次定位最花时间的，不是最后那张单变量表，而是前面几次“看起来马上要成了，结果又不是它”的绕路。

4.1 第一版 demo 走偏了

我第一版最小复现，走的是同 JVM、裸 DubboBootstrap 的方式。结果问题一堆：
  • fastjson2 路径下会出现“连上了，但 5 秒后静默断开”的诡异现象
  • PermittedSerializationKeeper 还会因为 service key 对不上，直接把调用拒掉
  • hessian2 能跑，fastjson2 有时又“看起来也正常”，和线上现象完全对不上
这条路最大的问题，不是代码写不出来，而是干扰变量太多。你很难知道自己现在看到的异常，到底是这次线上 bug，还是 demo 搭法本身带来的副作用。
所以我很快放弃了这条路，改成双进程、Spring Boot starter 的方式。

4.2 双进程能复现，但换个干净工程又不复现了

换成 Spring Boot 双 JVM 之后，问题一度能稳定复现。
但当我把代码迁到一个更干净的 demo 工程里时，bug 又消失了。4 个对象全都完整，连共享引用都被完整还原了。
这种时候最容易犯的错，是开始同时改很多变量。版本、注解、端口、URL、version="1.0.0"，一起改，很快就会把自己绕进去。
我当时就踩了这个坑。
一度我以为决定性因素是 version="1.0.0"。后来做单变量回退，才发现不是。真正起作用的，是 refer URL 里那一小段 query 参数。

4.3 最后锁定的，不是版本号，而是 URL query

我把对照实验补成了最小集：
URL query
wire 最终落点
是否复现
无
hessian2
否
serialization=fastjson2
fastjson2
是
prefer.serialization=fastjson2
fastjson2
是
prefer.serialization=fastjson2,hessian2
fastjson2
是
prefer.serialization=hessian2,fastjson2
hessian2
否
这张表一下子把问题收窄了：
只要 wire 最终落到 fastjson2，bug 就复现；落到 hessian2，就不复现。

4.4 线上线下真正的差异，在 Nacos metadata

线上走注册中心，本地 demo 一开始走的是直连 URL。两边真正的差异，不在 DTO，也不在版本号，而在 provider 注册出去的 metadata。
线上 provider 的 Nacos metadata 里，有这样一段：
这就解释了为什么本地第一版 demo 不复现：直连模式下，consumer 不会从注册中心 merge 这段 query，自然就不会走到和线上同一条路径。
把直连 URL 改成下面这样以后，复现就稳定了：
notion image
图 2：定位真正起作用的变量，不是版本号，而是 invoker URL 上的序列化 query。
到这里，我已经知道“线上为什么会命中这条路径”了。下一步要回答的是：Dubbo 到底在这条路径里做了什么。

5. 把 Dubbo 拿掉之前，先把 Dubbo 这层看清

要想证明锅不在 Dubbo，不能只靠“我感觉像”。得先把 Dubbo 到底做了什么说清楚。

5.1 Dubbo 是怎么选到 fastjson2 的

核心入口在 CodecSupport：
继续往里走，是 UrlUtils：
兜底默认值在 DefaultSerializationSelector 里，写死的是 hessian2。
这几段源码放在一起，结论就很直接了：
  • URL 上没有 serialization / prefer.serialization，默认走 hessian2
  • URL 上一旦把 fastjson2 放到第一个，最终就会选到 FastJson2Serialization
所以前面那张对照表，不是偶然现象，而是源码行为的直接结果。

5.2 为什么线上 invoker URL 会带上 prefer.serialization

关键在 ProtocolConfig.checkDefault()：
这段代码至少能说明一件事：如果 provider 没显式写 preferSerialization，Dubbo 会在运行时给它补一个值。
provider 端常见的配置写法是：
但这段代码本身并不能单独证明线上最终一定会注册成哪个具体值。这个问题，还是要回到线上实际抓到的 Nacos metadata 去看。
而我们线上实际抓到的，就是：
也就是说，这里真正站得住的结论是两段证据拼起来的：
  • ProtocolConfig.checkDefault() 说明 Dubbo 确实会参与补默认值
  • 线上 Nacos metadata 证明最终注册出来的值就是 fastjson2,hessian2
所以线上为什么命中 fastjson2，不是猜出来的，是“源码行为 + 线上 metadata”一起对上的结果。
notion image
图 3：provider metadata 里的 prefer.serialization 最后被 merge 到 consumer 的 invoker URL。

5.3 为什么 consumer 自己 yml 里写 fastjson2 也不生效

这里还有一个很容易把人带沟里的点。
我当时也试过在 consumer 自己的 yml 里写：
直觉上看，这么写以后，consumer 发包不就该走 fastjson2 了吗？
但 Dubbo 这里不是这么分层的。dubbo.protocol.* 对应的是 ProtocolConfig，它只影响当前应用自己 export 出去的 URL。provider 的业务接口 export 用它，consumer 自己 export 的 MetadataService 也用它，但它不参与 consumer 的 refer URL 组装。
consumer 发包时真正看的，还是 ReferenceConfig 最后拼出来的 invoker URL。也就是说，决定 wire 协议的不是“consumer 本地 yml 有没有写 fastjson2”，而是“最终 invoker URL 的 query 上有没有 serialization 或 prefer.serialization”。
这也是为什么前面那组实验里，真正有决定性的始终是 URL query，不是本地 yml。

5.4 Dubbo 对 fastjson2 做了什么

Dubbo 在这条链路里，真正做的主要是两件事。
第一件事，是把参数交给 FastJson2ObjectOutput，并启用它那组 features：
这里最关键的是 ReferenceDetection。它一开，共享引用就不会重复内联写值，而是会写成 $ref。
第二件事，是 provider 侧 decode 时，按 Class[] 去读参数：
对 Set<StatusQuery> 这种签名来说，这里拿到的是 Set.class。再往下会走进 FastJson2ObjectInput，继续交给 JSONB 去 parse。
也就是说，Dubbo 在这条路径里，更像一个调度员：
  • 它决定最后选哪个序列化实现
  • 它决定调用 fastjson2 时用哪组 writer / reader features
  • 它把参数交给 fastjson2 去真正做字节层的写和读
如果把 Dubbo 整层拿掉，只保留这组 features，问题还能复现，那锅就不能再算到 Dubbo 头上了。
notion image
图 4：Dubbo 负责选择路径和透传 features，真正的字节写读仍然在 fastjson2 里发生。

6. 把 Dubbo 拿掉，问题还在

我后面做的实验，就是把 Dubbo 完全剥掉，只保留它实际用到的那组 fastjson2 writer / reader features，直接跑：
  • JSONB.toBytes(...)
  • JSONB.parseObject(...)
而且这次不是传裸 Set.class，我直接传了完整泛型：
如果这样还能复现，就说明问题已经和 Dubbo 业务路径无关了。
结果是：能复现。
notion image
图 5：去掉 Dubbo 后仍然是同样的结果，这一步把 Dubbo 从根因里排掉了。
我又做了 5 组单变量对照，把几个最容易误判的方向全洗了一遍：
单变量变更
结果
baseline：Set<StatusQuery> + 共享 statusCodeSet + Dubbo 真实 features
1 完整 + 3 null
去掉 writer 的 ReferenceDetection
4 完整
去掉 reader 的 UseNativeObject
1 完整 + 3 null
把 DTO 从 @Data 改成只按 sn 做 equals/hashCode
1 完整 + 3 null
外层从 Set<StatusQuery> 改成 List<StatusQuery>
4 完整
这张表的价值很大。因为它把几个“看起来像根因”的东西排掉了：
  • UseNativeObject 不是必要条件
  • Lombok @Data 不是必要条件
  • 泛型擦除也不是必要条件
最后真正留下来的，只有 3 条必要条件：
notion image
图 6：真正的最小条件只有 3 条，其他更像放大器，不是根开关。
到这里就够了。
第一篇的任务，不是把 fastjson2 内部每一行源码都拆开，而是把最小问题路径钉死：

7. 定位问题中间件

到这里已经确认完了：问题不是 Dubbo 业务层的 bug，而是落在 fastjson2 这条序列化路径上。后面如果继续往下拆，我会单独写 fastjson2 的写端、读端和补丁思路。
完整 demo 我已经整理到 GitHub：
真正难的，从来不是“猜到像是哪个组件有问题”。
真正难的是，你得一层一层把中间件里没问题的部分排掉，跟着数据流走，把最小问题路径逼出来。等只剩最后那条路径的时候，锅是谁的，反而就不难看了。

8. 参考资料

 
 
]]> <![CDATA[Claude Code CLI 完整安装教程：从 0 到成功运行]]> https://yibin.dev/article/31e60b50-99a4-80f4-8ef2-dbeb1efe9655 https://yibin.dev/article/31e60b50-99a4-80f4-8ef2-dbeb1efe9655 Mon, 09 Mar 2026 00:00:00 GMT

🧠 Claude 是什么

Anthropic 推出的 Claude 是一款面向开发者与专业用户的先进大语言模型助手，主打：
  • 更强的代码理解与生成能力
  • 更长的上下文处理能力
  • 更安全、可控的 AI 输出
  • 更自然的对话体验

📦 安装 Claude Code

官方提供了一键安装脚本，直接在终端运行：

⚙️ 配置 PATH 环境变量

执行以下命令，将 Claude 加入系统可执行路径：
如果你使用的是 bash：

🖨 国内网络安装

使用 claude 官方脚本安装，是需要网络环境支持的，不然在下载脚本时候会报“地区不支持”。Claude Code 是一个 npm 包，所以可以直接使用 npm install -g @anthropic-ai/claude-code 来安装，相关依赖的环境按照参考以下脚本。

✅ 验证是否安装成功

 
此时命令行输入 claude，会引导登录 claude 账号和配置，如果使用官方账号，按照引导完成输入就可以了

🧩 API 环境配置

如果你希望使用 API Token（例如自建代理 / 企业网关），可以配置：
 

字段说明

配置项
作用
ANTHROPIC_AUTH_TOKEN
API 密钥
ANTHROPIC_BASE_URL
自定义 API 地址（代理/镜像）
API_TIMEOUT_MS
请求超时时间
DEFAULT_*_MODEL
默认模型配置
其他字段解释见官方文档：https://code.claude.com/docs/zh-CN/settings

🧭 跳过新手引导

在~/.claude.json 文件中增加如下配置，用于跳过首次引导流程。

🎉 成功启动 Claude Code

此时即可开始交互：
说明本地 CLI 已可正常使用。
 
 
 
]]>