说白了就是钱的问题。

大厂是就近 CDN，并且 CDN 整套后台都是 C++。

小厂既没有 CDN，又是蜗牛 java 后台，速度怎么会快。

上百 T 的数据，就算全覆盖式毁掉也要好几天。

好几天的时间，足以让事件被发现，操作被中断。

我同事有个表弟，大一写了飞机大战，还是网游，不仅编程，连美术与音乐音效全是自己原创的。

大四他做了个搜索引擎原型，能搜出百度和谷歌搜不出的东西。

他的徒弟在 bat 带队做项目。

可惜，他现在只是在事业单位混吃等死。

@FrankHB 做编程就像建房砌砖一样。小房子，不做设计，先砌砖当然可行。但大型工程，必然要先有设计图。

1.如何开发软件，题主可以找找软件工程之类的书籍，科班把这一块内容放在本科层次，内容不难。

2.即使你再怎么牛逼，面对大工程，没按软件工程的步骤来，急于编码，必然后期会有各种各样的问题。

但是！

项目质量，与是否赚钱，并不成正比。

建议题主尝试先不编程，而是在 Visio 上把流程图画一画，跟着流程走一走。

编程不仅是一门技术，更是一门艺术。
而艺术在于设计。

多设计，少 Coding，才是成为大神之道。

......

上面都答错了。

你这哪里是什么搜索问题，而是一个简单的网页制作的问题（前端问题）。

1.<em>是 html 的标签，当它出现在网页源代码里，它的功能是强调标签内的文字。

2.你的搜索结果字符串里，包含了 html 标签，如果你把这个字符串，没做任何处理，直接放在前端网页里显示，搜索结果字符串里的<em>标签，就成了 html 网页源代码里的一部分，也就变成了强调功能，并且最终在显示出来的网页上面，也没有<em>这个子串。

2.你现在要做的是，把搜索结果，先进行 html 转义。转义后，再放在前端网页上显示，它就不会成为 html 功能的一部分，而会成为前端网页上的一个完整的字符串。

很正常，其实就是开发者水平的区别。

比如我见过某个文件去重工具，居然用 sha1 来计算文件哈希值，这种完全不需要加密的地方，换个方案能提高 200 倍的速度，可惜这个作者就是不明白这点，因此写出来的软件性能特别差。

Wlan 怎么可能比有线快，只能说你自己的有线设备比无线差而已..

你这不是负载均衡，而是智能路由。

不仅需要拆包并发，还要实现瓶颈管理（优质线路满载时计算转发到劣质线路是否划算）、延时预算（走一条还是走多条，只走优质还是优劣并走）、重发管理（如果接收端存活，则缺失片段需要一直寻找不同线路重发）等等。

这一套东西，是真正的科研，弥补了现有协议与路由运作方式的不足，这可不便宜，更别说免费了。

电信一般是一分钱一分货，就算在峰值，也会保障你的上下行带宽，不会出现联通移动那种高峰期掉速现象。

我建议你先换台电脑，看看是不是电脑的原因。

然后你在低峰期和高峰期，分别测试一下 ping 速度、dns 速度，以及 360 的网站打开速度，做个对比图。

你真觉得这种又便宜，但又紧缺，而且还是性命攸关的物资，真的会放出来让大家抢购？

程序员又不傻，当然知道填写收货地址应该放在哪个环节去做。

Clash for Windows v 0.7.6，有 非 全局模式。把 System Proxy 设置为 off 就是非全局模式了。

此时应用程序用 Socks5 连接 Clash 的 Socks Port 就行了。

zerotier 在网络不稳定，以及频繁出现网络故障的环境下，表现非常差。

1.海量数据，又要关键操作性能高，这种情况下，读与写本来就是个矛盾，要不读快写满，要不写快读满，你要两者都高，这怎么可能。

2.你对开源（免费）产品，既要求性能高，又要求功能多，还要求运维成本低，这怎么可能。

3.在一堆海量数据里，确定一条数据的唯一性，这本来就是世界难题，原因是在硬件与运维有限的前提下，这操作完全是在挑战计算机设备的性能极端，这事在理论上根本没办法搞定，就连谷歌最后都只能选择砸钱堆服务器堆运维，才有了较好的性能。你又没服务器，又没人给你运维数据性能，这事怎么可能解决得了？

建议：
1.你应该选择你最关注的因素，比如读速度快，然后牺牲一下写数据，按这个模式，来做业务逻辑。


2.现在任何一款主流的分布式数据库，都做不到帮你把冷热数据均摊好，保证每台物理设备的性能平均。因为这个操作要涉及到经常的大规模的数据迁移，这个过程本身就会大幅度降低系统性能。因此，还不如你自己设计一个冷热数据记录器，再根据业务繁忙度，在闲时就像停服一样，重新分布冷热数据。这操作其实就是运维工作，你不去做这个工作，没办法把冷热数据高质量地均摊在不同物理设备上。

@wwcchn9 我说的是能大幅度压缩代码，不是说所有代码都能被压缩成正则。