用一次天气查询跑通 Function Calling：请求里传 tools 菜单，响应里收 tool_calls 申请单，真正执行函数的始终是你自己的代码。
大模型本质上只会做文本补全。人们用提示词技巧让它输出格式化内容，外部程序再解析执行，看起来就像模型长出了手脚。
三台 RabbitMQ 连成集群后，「同步」「复制」这些词就开始含糊。这篇文章跟着一条消息，从生产者发出到消费者取走，看它经过哪些节点、集群内部同步了哪两类数据、哪些根本不进集群；再把接入节点故障、Leader 故障、失去多数派逐个拆开，记录发送与消费各自怎样失败或暂停。全文以 RabbitMQ 4.3.5 为准，集群是三台本机容器里的节点，结论只对这个实验环境成立。
一条消息从发送到消费，中间要经过哪些组件、走哪几段路。文章先把 RocketMQ 4.x 的全貌铺开——有哪些角色、各自负责什么、谁跟谁通信，再跟着一条消息走完主链路：寻址、发送、落盘、被取走。顺序、定时、事务、过滤这些功能特性挂在同一条链路上，正文在每个功能上停一次，说明它的取舍与代价。全文以 apache/rocketmq 4.9.7 为准，覆盖传统 Remoting 客户端与静态主从部署，不涉及 5.x 的 Proxy、gRPC 与 Controller 自动切换。
一笔跨行转账，凭什么断定两边都没记错？建一个简化对账系统：两个银行各自维护借贷账本，模拟结算服务提供第三方数据，日终对账任务逐笔匹配并分级处理差异。对账只发现差异，分级处理才决定动作——这个分界是金融系统能在出错后继续运行的基石。
一笔订单的消息发送成功了，下游却没收到——它死在哪一段？在 RabbitMQ 上把生产者、Broker、消费者三段各跑一遍可复现的实验：confirm 返回 ack 时消息可能已经被丢弃，持久化要分清消息恢复和拓扑恢复，prefetch 决定消费者崩溃时最多重投多少条，重试用尽后为什么不能靠 nack 收尾。
一条消息从客户端发出到被消费掉，要穿过 vhost、connection、channel、交换机、绑定、队列这几层结构。在 RabbitMQ 4.3.5 上逐层看这套结构：三种队列类型的差别是消费语义而不是性能档位，quorum 上有一档溢出配置声明会被接受却不生效，而三个 5xx 错误码关掉的是整条连接而不是信道。
一览 JDK 21 相比 JDK 8 的关键新特性。
