类似的东西，我有过构思。
每个用户拥有自己的非对称密钥对，通过公钥的 Hash 组成 DHT 。当用户 A 想联系用户 B 时，通过用户 B 的公钥哈希在 DHT 定位目标 IP 和端口，再用双方的非对称密钥对进行对称加密的密钥交流，最后成功建立连接，进行通信。
我发现这个方法面临几个缺陷：
一，DHT 容易被探测，Github 上一抓一堆 DHT 爬虫，爬取下载的种子和下载者信息。
二，通信质量不稳定，尤其是在移动端，当用户在不同基站下切换过快，联系他的人会有一个重复搜寻目标用户端点的过程，这个过程体验会很不好，如果楼主用 BT 下载过冷门资源，就明白那个搜寻种子需要的时间会有多长。
三，离线消息没有地方储存。
我后来想了一个方法解决，那就是[代表]节点，代表节点取得用户授权的签名后，可以在网络中代替用户接发消息，和 Matrix 相似，但比 Matrix 好的一点是，用户的账号不存在于服务器中，用户可以随时更换一个代表节点。

但最后想了想去，终究是和市面上已有的、针对这个问题的 IM 变得越来越相似。
或许我们更好的选择真的是拥抱那些已有的 IM ，推进他们针对中国的问题本土化。

上面是我以前对类似项目的思考，下面是我自己对此类软件的特性的期望：
一，有网页客户端，这样能让其他人迅速加入。（基于 http 的 p2p 技术已经成熟，所以点对点不是问题。）
二，账号不需要注册，不保存在服务器之上，让没有技术的用户不用面临服务器关闭之后该怎么办的问题。（点名长毛象和 Matrix 。）
三，传输层协议可选，这样我们能融入广泛运用的协议，使得封禁变得困难。（举个例子，使用 WS+TLS 的梯子。）
四，可以分布式运行，但允许中心服务器的加入来优化用户体验，例，我们可以使用 DHT 来查找和储存用户公钥和端点，也可以接受一个服务器储存全网的公钥信息，让用户可以快速查找到端点信息，类似现有的 DNS 体系，只不过不分级。
五，第四点的延伸，协议允许服务器代表某用户参与网络，当服务器一直没有用户的消息，超出用户设定时限，服务器会删除用户所有信息。

我们可以从第四点和第五点入手，让商业行为发生。只有商业化，让人能够赚钱，才会有最大的可能保障通信的质量。赚到钱的人也会有动力让整张饼越来越大。（不要说非法没人做，那么多非法的梯子运营商赚钱赚得很爽。）

第五点可以让用户免于被嗅探、查水表。

一点不成熟的考虑，抛砖引玉。

先检查是否对文件拥有权限，再检查文件是否设置为了只读。
建议报错时捕捉到错误之后，对文件的权限相关信息进行一个日志上的输出，拥有足够的信息后再 debug 。

已发，但是没有写薪资要求，因为更想在互相了解之后商谈。不知道要多久有回复。

你们就没想过楼主可能会在跟随他交易的人数多了之后开对手盘吗？

先通过反射获取空接口变量的类型 检查是否为 channel
确认是 channel 之后获取此变量在内存中的位置 也就是制造了一个指针

注释是 channel 的数据结构
unsafe.Sizeof(uint(0))*2 是跳过 qcount 和 dataqsiz
unsafe.Sizeof(unsafe.Pointer(uintptr(0))) 是跳过 buf
unsafe.Sizeof(uint16(0))是跳过 elemsize
*(*uint32)(unsafe.Pointer(cptr))取得结构中 closed 地址的数据 检查是否大于 0

可以先学 c 语言 看这些就容易很多了

新语言是什么语言啊

商业游戏里什么东西都是厂商说了算，毫无标准可言。你抗拒游戏厂商定下的规矩你就没得玩，这点和传统运动比起来真的是差远了……

安利一个 c#的 System.IO.Pipelines 在这方面贼好用

你教的内容有什么是搜不到的

@vimutt v2ex能输出别的不能输出那就不是编码的事 是解析器的事 你换个解析器 有个HTML5的解析器 纯PYTHON实现的 容错是现有最好的 就是比较慢 还有 推荐用BEAUTIFULSOUP来做这事