请不要过早的进行不必要的“性能优化”，这只会让代码陷入未来无法维护的境地

首先，请去除“IPv4-only 隧道处理”部分，那点error log并没什么实际影响，不值得维持让openvpn的代码和其他的模块有那么大的出入

其次，不要修改tcp底层缓冲区，也不用盲目扩大chan的缓冲容量，这会大幅增加核心的内存占用

最后，我们不反对用pool，但是streamPacketFramePool显然是不必要的，mihomo本来就有自己的全局byte pool，为什么不直接复用

请不要过早的进行不必要的“性能优化”，这只会让代码陷入未来无法维护的境地

首先，请去除“IPv4-only 隧道处理”部分，那点error log并没什么实际影响，不值得维持让openvpn的代码和其他的模块有那么大的出入

其次，不要修改tcp底层缓冲区，也不用盲目扩大chan的缓冲容量，这会大幅增加核心的内存占用

最后，我们不反对用pool，但是streamPacketFramePool显然是不必要的，mihomo本来就有自己的全局byte pool，为什么不直接复用

已按照以上这些要求进行修改，测试多个节点后未发现问题

看了一下目前的代码还是有些小问题的，主要在outbound那边：

1. run函数忽略传入的ctx后，会导致DialContext和ListenPacketContext也无法正常遵守传入的ctx（即必须要等待handshake完成）
2. 还有一个之前代码就有的问题，代码中有两处o.tunDevice = nil的调用，但是DialContext和ListenPacketContext里并没有检查其是否为nil，会有小概率造成panic

看了一下目前的代码还是有些小问题的，主要在outbound那边：

1. run函数忽略传入的ctx后，会导致DialContext和ListenPacketContext也无法正常遵守传入的ctx（即必须要等待handshake完成）
2. 还有一个之前代码就有的问题，代码中有两处o.tunDevice = nil的调用，但是DialContext和ListenPacketContext里并没有检查其是否为nil，会有小概率造成panic

好，已处理以上的问题

通过openVPNRunLockRetryInterval来忙等待真的好么，有没有更优雅的方式处理一下

此外，既然每次既要调用.run也要调用.stackDevice不如将这两个函数合并，直接让run函数返回那几个值呗，还能避免两次加锁

通过openVPNRunLockRetryInterval来忙等待真的好么，有没有更优雅的方式处理一下

此外，既然每次既要调用.run也要调用.stackDevice不如将这两个函数合并，直接让run函数返回那几个值呗，还能避免两次加锁

已根据建议调整：

1. 移除了 openVPNRunLockRetryInterval 轮询等待锁的实现，改用可被 context 取消的 semaphore acquire，避免忙等待，同时仍能让 DialContext / ListenPacketContext 在等待 OpenVPN 初始化锁时响应传入的 ctx 和 outbound 关闭状态。

2. 合并了 run 和 stackDevice 的职责。现在 run(ctx) 会在完成初始化后直接返回 tunDevice 和 resolver 的快照，DialContext / ListenPacketContext 不再需要先 run 再 stackDevice，避免了重复加锁，也减少了 tunDevice 状态变化带来的竞态窗口。

3. 保留了之前对 tunDevice nil 的保护逻辑：如果设备已关闭或初始化失败，会返回 net.ErrClosed，而不是继续访问导致 panic。