Python 的优势在于超高的开发效率，如果一定要追求运行性能，建议考虑一下 C++，或者把 Python 耗性能的部分改成 C++实现或 C++中间件。

收费的，规则一般是十几条，最多二十几条。如果是免费的，规则多，目的应该是为了防范攻击与滥用，也是能够理解的，毕竟很多免费是的湾湾 fan 动 zu 织搞得，他们的经费也不多。

@kisick 我不认为你这萌新水平有资格评价我。

@lxxiil 1.目前有很多事情，比如小区变电站、手机信号、Wifi 、微波炉等等，发明出来还没几代人，且由于目前医学的不发达，这些东西对人造成的积累性的长期微量影响，没有理论与实验证明就一定是安全的。

2.我在某三甲妇科医院与基因研究院（华*基因）有关系，他们以前都提醒过我，搞 IT 要注意休息，注意防辐射，他们那里有职业与胎儿基因问题的关联性数据。虽然不知道理论原理，但有病例数据作为支撑。

3.IT 与电气化专业，容易生女孩子，这也是有小规模数据支撑，但数据不是官方来源。

别用大功率点对点户外无线通信方案，不然你老婆怀孕时基因一查各种异常就麻烦了。

没办法...输入法能保持稳定的，就是 XP 时代 + 智能 ABC 。从 Win7 开始，搜狗就经常出问题，Win8 时代到 Win10，整个快捷键与逻辑都变化了一次。

这事本质是欧美根本用不着输入法，都是第三方整的，OS 也不给这玩意提供好的用户体验，国外一线软件也不考虑这个问题，怎么可能用的好，别怪搜狗了。

王者段位的做法是：

1.预判：先看特性，猜测它的理论依据与实现思路，然后花点时间想想，如果自己来做，应该如何设计。

2.验证：去找 Demo，验证一下猜测对不对，查漏补缺。

3.测试：看文档，做小规模测试。

1.TCP 通信中不存在 [黏包] 这个问题。

2.遇到 [黏包问题] 的人，基本上都是因为这方面学习不过关。

3. [黏包问题] 的发展史是：
很多年前，一堆基础不扎实的黑客，以及上一代的程序员们，经常用 VC 写各种 Windows 客户端程序。一方面他们需要进行通信编程，另一方面由于这部分内容对他们的水平而言比较深奥，他们掌握不好，因而采用“如何简单就如何来”的策略，首当其冲就是 udp 。

VC 的 UDP 编程，一条数据发一个数据包，自然不存在界限问题；同时 VC 的 UDP 编程，代码简单，收发逻辑简单明了，因此深受这群人的欢迎与追捧。

接着，天时地利人和，这群人的时代，恰好是单物理核 CPU 大行其道，最多也只会遇上单物理核的超线程 CPU，因此即使把 UDP 换成 TCP，只要模块拆分得当，就算是并行的程序，也不易黏包。不过也只是不易而已，这些程序时刻有黏包出错的风险，因此，他们那时的程序，很不稳定，经常需要关闭重启。

他们的历史，也就到此为止了。

由于通信应用的复杂性，以及用户需求进一步提出更高的要求，当他们尝试多条数据放在一个 UDP 数据包里进行发送时，就会出现所谓的 [黏包] 问题。这是其一。他们所谓的 [粘包] ，也就是他们本来的收发逻辑是，一次发送或接收，只处理一个数据包，然后一个数据包里，只存放一条数据。现在他们把多条数据放在一个数据包里，甚至多条数据放在多个数据包里，于是在发送与接收的业务就全变了，同时又需要引入合并、拆分、处理顺序以及考虑性能问题，整个流程变得非常复杂，他们处理不了，程序经常出现问题。

UDP 功能有限，因此他们总会需要用到 TCP 。此时，由于水平的局限性，当他们按照 UDP 的方式来进行 TCP 通信时，就非常容易遇到所谓的 [黏包] 问题。这是其二。

这帮人水平本来就欠缺提高，再遇上那时双物理核以及更多物理核的 CPU 开始普及，多线程与并行编程就跟着开始流行，这对于程序员提出了更高的要求。此时，这群人在并行程序里按照以前串行程序的老路子进行通信，注定会遇到黏包问题。这是其三。

以上三种场景，被这帮人把这个问题总结出来，称之为 [黏包] 问题，并且在网络各处留下这个问题的详述，以及一堆古灵精怪嘀笑皆非的解决方案。

如果想做面向用户友好的 reddit，那就需要搬到外网，流量就没办法保障。没流量，后期就很难拿到融资，你不可能一直用爱发电吧...

不搬到外网，你现在小规模，没啥事，规模大了，各种规章制度会主动找上门，甚至要求你提供用户与信息的实时监控 api 。

有，比如体制内。国企，甚至事业单位的信息化部门。

曾经帮某为的几个朋友，推荐到了事业单位，缺点是工资只有以前的 25%，优点是非常清闲。

1.如果你只是为了办公，建议在家里用 小米 wifi 控制的电源 + 开远程，到了另一个地方后远程办公。

2.如果是为了玩游戏，那就没办法了，只能搬台式电脑。经常搬台式电脑，容易出问题。轻则内存条松动，严重的有可能会磕坏硬盘、电源或主板，要注意保护，小心开车，尽量不要急加速急减速。建议为了保护机箱，买个带缓冲结构的小推车。

别急着换方案，先想办法调试一下，找一下不稳定的原因在哪。假设问题是硬件有瓶颈，那么换软件是无法解决问题的。

之前就看到过类似案例，数据库有延迟，优化、换数据库都解决不了。后来有大佬进行整体分析，发现瓶颈在存储上，把 ssd 从 1 个增加到 3 个，组了 raid 0，问题解决。