以上三个都是毛用没有的东西啊，哪看出未来了

第一个数据绑定的问题是 js 变量和 dom 、样式以及事件变化同步的问题，你再怎么编译也改不了这个啊，所以没有运行时扯的吧，顶多叫运行时打散使用可选编译和业务代码编译在一起了
第二个这东西都说了快十多年了吧，有没有用还用说
第三这种顶级坑货就更不用说了，服务器无状态硬生生搞成有状态，难度复杂度提高十倍不止还不能适应各种环境问题吧，谁选这种方案真是作死

过去十年前端能大发展本质还是互联网行业的繁荣催生的，互联网啥情况不用说，所以前端技术方向也不可能再沿着这个方向继续发展了，这就好比十年前 pc 时代，各种 ui 框架也是做的很牛逼，可是之后呢，所以紧跟时代步伐啊

@yezheyu #8 网络看除了传输协议不同外，没啥区别，只是 rpc 一般会定义更完整的调用流程，http 本身只定义了传输过程，http 服务端和客户端都各有各的实现

似乎有点本末倒置了啊，所有文件保存的、网络传输的都是二进制，并没有啥区别，

为啥有二进制文件和文本文件，这个其实是用你的查看方式决定的，你用文本查看就是文本文件，文本文件有不同编码方式，比如 gbk ，utf8 之类的，你打开文件的时候就已经选定了一种解码方式，并不是文件告诉你应该用啥解码，所以才会有乱码问题，乱码图案自然从你选定的解码方式里找啊

关于 base64 其实是邮件和网页已经首先选定了文本型 utf-8 编码换行分隔，如果你直接在里边放二进制数据，那么二进制数据自身就会影响解析，比如二进制里按文本解析就有换行符啊，这时就要解析出错了，本质来说在编码的分层结构中，网页和邮件是用的是规则匹配来解析数据，那么首先你网页邮件里保存的数据就必须保证不能有符合网页邮件解析规则的数据，所以才有了 base64 来把二进制数据编码成肯定不会匹配网页解析规则的文本数据，而像 grpc 这种用的就是预定义结构解析，所以内部保存的数据不可能影响结构解析过程，所以也就不需要再编码

想太多，这么多公司估计比这漏洞大的多了去了，还不是照样用的好好的，小公司名不见经传的，漏洞不漏洞的谁理你啊，项目做三月发现毛用没有的倒是挺多，大公司就那么几个，这种就算自己搞个估计都不会去买，而且商业库也会有漏洞的吧，说不定更多

java 这一套的话，反正更新重启一下十分钟过去了也不止，所以两个节点也想用注册中心也可以理解，否则真没啥必要，否则节点数比较少服务也少也搞似乎是个坑，大炮打蚊子可不但没提高生成效率反而坑死人的了

简单来说我猜应该是地球温度应该主要时靠地面吸热和空气来保温的，海拔搞了理地面越远空气也越稀薄，温度更低应该是吧

@guyeu #11 这不就是 callback 和协程的区别么，一个手动调度一个自动调度，逻辑上也没啥区别，两者谁更快还不一定呢，毕竟业务流程复杂了 callback 写出高性能代码的更难了

再说各位别把异步 io 和协程混在一起啊，这两个虽然配合使用，但是这两并不是一回事

一个商品信息需要 90 个字段么？！显然没理清楚吧，其实很多信息看起来和商品相关的，但实际来源却不是商品，哪个系统的就放到哪去呗，后面迭代你会发下容易很多，不要以哪个信息写在哪个页面上来分字段放在哪，这是个大坑

@passerbytiny #22 java 生态的问题就是在这，老是瞎想万一要啥啥所以一开始就要这样那样，且不说真后面有这需求了改起来也未必有多高成本，更不用说现实绝大部份情况根本不会出现一开始预测的情况，基于瞎想和技术装逼症滥用且过度设计，反而导致现实情况下很多时候既不能了解基础原理亦不能完全了解设计逻辑，然后实际依然一堆问题，而且大多数时候既弄不清底层又不理不清设计原理，也就各种加班自己辛苦了

固然这个世界还是有少部分头部公司确实会把各种只在想象中的需求踩一遍，但也不妨碍基础组件设置为可选递进选择模式的吧，最后更重要的是，大公司有足够人力物力滥用设计也就滥用了吧，反正人家有钱，但是中小公司不看业务场景不看自己成本，也学大公司喜欢技术牛逼症滥用设计模式这种思维模式才是坑死个人

没必要解释有没有需求这种问题，java 这些东西本来就有过度设计的问题，不需要解释，一个打日志组件做这种解析居然不是个可选功能，毫无疑问过度设计了，但重点是一直搞不懂干 java 的都有种盲目的把过度设计当系统牛逼的依据而完全不管自己的业务场景业务需求，真是不明所以

websocket 过 nginx 跪了

关于下线问题客户端开心跳，服务端也还要做心跳超时啊，而且吧一般来说负载均衡应该设置为同一个设备始终连接到同一个 pod ，这样可以确保新连接建立时踢掉老连接，保证一个设备只会有一个连接在线才是

非静态编译型语言的都这样好的吧

前段时间不还有个图说啥都不买的收益超过了今年百分之八十的股民😂😂😂

@3dwelcome #1 标题都写了啊，simd

原来 pillow 默认不支持 sse4 和 simd 。。

你这代码百度复制粘贴的吧，第一个参数啥意思都不看下的么

这和性能不性能的无关吧，和维护及开发效率有关吧

现实来说，太多情况需求三天两头变，很少有按固定产品需求开发测试然后交互就结束的，直接用数据库且不说面对需求频繁改变确实有些吃力，而且吧正因为改变太快太多，所以恰恰需要一个稳定的存储逻辑，业务逻辑做在数据库里你就不怕三天两头改的时候直接把数据库干废了么

再者吧数据库毕竟是查询组织管理数据的，对业务逻辑的表达能力本来也不强，何不把数据和业务流程组织过程放在一起，这样且不说更直观，而且对人员的要求也降低了，毕竟如果后台用 php 的话，招人来做看 php 就行，数据库你会增删改查也就行了，要求可是降低很多的吧

看到“nginx 的单机负载也就是 3w-5w 连接”才是被惊了，你不是用的假 nginx 吧

@imherer #15 但是把如果是 c 和 c++的话，原地址被回收只是代表其会被重用于其它内存分配，地址指向的物理内存是不会消失的，所以也就不会出现空指针错误，除非这是一个双重指针，地址回收的时候更新了第二层指针的指向为空

说起来实际使用来看，go 还真是这么设计的，双重指针，只是这样设计似乎效率低了一点，但是好处确实是保证不会突破内存屏障了，上层使用来看确实有些地方还是很让人莫名其妙的

@imherer #13 然后原地址可能已经被回收，但因协程调度原因此时有协程才刚开始使用原地址进行操作这样么？嗯，极高并发下看起来还真有可能