心跳协商机制技术问询：RequestedHeartbeat相关逻辑确认

Hey Anthony, let's break down what I've observed with heartbeat negotiation in similar client-server messaging setups, since you're hitting gaps in the docs and code:

• 通用行为逻辑：在绝大多数心跳-enabled的架构里，确实遵循「取客户端RequestedHeartbeat和服务器心跳超时的最小值」这个规则。如果服务器的超时设置比你的客户端RequestedHeartbeat小，客户端要是硬用自己的大值，服务器会在它的超时窗口内收不到心跳，直接判定连接死了并关闭。所以从合理性来讲，客户端库应该自动适配这个最小值——不然连接稳定性根本没法保证。
• 代码层面的隐藏逻辑：你说没找到ConnectionConfiguration.RequestedHeartbeat的确定性用法？大概率这个值是作为握手阶段的请求参数发给服务器的，服务器会在握手响应里返回它自己的心跳配置，然后客户端底层代码会悄悄把实际发送心跳的间隔改成两者里更小的那个。这种逻辑通常藏在握手帧处理、响应解析的底层模块里，不会有很显眼的直接赋值语句。可以搜搜代码里有没有处理server_heartbeat或者类似变量的地方，看是不是会覆盖客户端的初始RequestedHeartbeat值。
• 文档缺失的常见原因：很多框架会把这类「符合行业默认逻辑」的细节省略在文档里，尤其是如果它是基于某个标准协议（比如AMQP、MQTT）实现的，协议规范里已经明确了心跳协商的规则，框架文档就不会重复啰嗦。你可以去查对应底层协议的官方规范，里面肯定有明确说明。
• 快速验证方法：如果想实锤的话，做个小测试就行：把客户端RequestedHeartbeat设成30秒，服务器心跳超时设成10秒，然后抓包看客户端实际发心跳的间隔，或者观察连接会不会稳定保持。如果连接没被服务器掐断，那说明客户端确实自动用了最小值；如果断了，那大概率这个库的心跳协商逻辑有问题或者没实现。

内容的提问来源于stack exchange，提问作者Anthony Mastrean