Hi,
写在开始前：
log如果可以配上注释，方便我这边阅读的话，我会非常感谢。
log能提供原文档和抓取环境的话，我也会非常感谢。
您遇到的真实情况应该是，对端设备在您发送Write之前它已经主动发起了disconnect操作，只是到达时存在延迟，然后您log的打印存在先后失序而导致的。亦即，您的write请求其实完全没有效果，对应于write的log只是应用层方面对发起意愿的粗略记录而已，实际上它没能被真实执行并被对端设备接受。您会看到这样的log，是因为您的log并非完全是协议栈的trace，它不严谨地部分混合了应用层的console记录，故给您造成了“发起write后却直接遇到了disconnect”的假象。而这样的日志并不能真实反映协议栈实际执行时序。您应该优先只分析蓝牙协议栈的完整trace，并且己方设备和对端设备的trace一起对比分析最好。
具体分析起来，站在对端设备的立场来看，它早在您发起write请求之前就已经主动发起了disconnect，所以它并不会响应您的write请求，即使该请求有传递过来也会被丢弃。并且对端设备因为根本上没有响应您的write请求，所以也就不会向您发送write response。
其实问题处理也没有那么复杂，摆在己方设备面前的无非就两条路：第一，如果自己认为自己发送并执行了write，那它就只能在忍耐限度内无条件等待下去，然后在超出忍耐限度后当异常处理，而这一般而言就是强制终止连接。第二，收到disconnect请求的event后，根据disconnect的处理流程，它也只能无条件地立即抛弃所有任务，进入disconnect的流程并终止连接。所以无论是选项一还是选项二，如无意外您最后都需要强制终止连接，故问题实际上还是很好处理的。
不管怎样，这种情况的确属于异常情况。而异常情况都需要您这边自行调查并解决，论坛这边很难对此提供支持。或者，您可以联系销售代表或FAE，来更好帮您解决问题。
<<<<<<<<<<<<<>>>>>>>>>>>>>
Sincere regards from C. L.
<<<<<<<<<<<<<>>>>>>>>>>>>>
