玩玩还是不错的，不过如果你的需求是接收 MQTT 推送，可以 MQTT 接收后再走企业微信发消息，用微信接收，就不存在你说的烦恼了，谁还没微信一直在线呢。

stopCh <- struct{}{}被你注释了，main 阻塞在 wg.Wait()，work 阻塞在 select ，没其他 goroutine 在活动能改变这俩阻塞状态。

用小鹤几年了，回不去了，用别人电脑拼音打字时总是输错，想给他改双拼

要求不高的话，用 frp 吧，简单很多，缺点是代理中转了一次，丢失了原始客户端 ip 。

returnValue_1 是 NRVO ，Named Return Value Optimization 具名返回值优化，简单说就是编译器会尽可能给你做返回值优化，减少拷贝。

@weyou frp 的 p2p 模式没有按这个实现吧，我用工具测试，一般是第一次不通过，后面再测就能通过，但是 frp 每次都换一个端口且不会重试，所以 p2p 模式经常不成功。

@fenghuang

@sagaxu 再生一个

static 作用是把符号限制在本编译单元，这样同名函数多处定义也不会报错； inline 作用是建议编译器内联展开，但是编译器也可能不内联，如果内联了，当然不存在符号问题，没内联的话，相当于会在.o 里生成一个弱符号函数，链接时同名的只会取一份。所以按需选择吧：
如果你定义在.c 文件里面，建议 static inline ，因为如果其他.c 有跟你同名但不同实现的 inline ，是有风险的；
如果你定义在.h 里，建议 inline ，在保证只有这个.h 里 inline 定义该函数的前提下，可以使没 inline 时共享同一份实现，减小文件体积，当然你怕出错用 static inline 也行；
还有个 extern inline ，会在.o 里生成一个强符号，也有用处，但也容易出错，几乎没人用。

static 作用是把符号限制在本编译单元，这样同名函数多处定义也不会报错； inline 作用是建议编译器内联展开，但是编译器也可能不内联，如果内联了，当然不存在符号问题，没内联的话，相当于会在.o 里生成一个弱符号函数，链接时同名的只会取一份。所以按需

static 作用是把符号限制在本编译单元，这样同名函数多个编译单元定义也不会报错； inline 作用是建议编译器内联展开，但是编译器也可能不内联，如果你想函数体

@zhoudaiyu 如果后端服务支持 proxy protocol ，可以，例如 nginx 。如果后端服务既不支持 xff 也不支持 pp ，只认 tcp 协议报文取到的 ip ，巧妇难为无米之炊。