神秘的邮政服务，你说它垃圾吧，毕竟半年时间用脚跑都能从中国跑到欧洲去了。你说他强吧，它半年以后还能精准跟踪给你退回来。。现代人已经很难想象以这种时间跨度，几十年前通信时代人们是怎么交流的。

@nvkou 我到不觉得是技术惰性的问题，单纯是小型业务上没有升级的必要，大型业务升级了也搞不定导致的。

一个大多数人不注意的有趣讨论是，uuid 其实也能做到无状态，每个业务节点分发一份检验列表即可做到不用回源。而且实际上并不会占用多少内存，毕竟即使存百万用户的数据，现代计算机里又算得了什么呢，所以小型项目上并无升级需求，因为无论哪种方案都不够成性能瓶颈。

而大型项目上，我也不觉得 jwt 的补丁能应付需求，毕竟如果状态频繁变化的话，一个业务节点一秒钟针对同一个账号签发十个令牌，而偏偏持其中任何一个都是合法的，这对于校验逻辑来说实在是无意义的压力大。

@005008 我不是很理解这种刷新模式相比于 vue 自动绑定，在什么具体场景下有优势。因为一般来讲 js 更新了那么用户也期望页面被同步渲染，而且看你这种刷新方法，似乎也没法控制粒度，那不是跟 vue 最终效果一样了

感谢 lz，不错的入门。一个疑问是，记得以前听说过 react 的绑定不是自动监听的，比如你在 html 里渲染了一个 js 变量，变量改变时它不会自动渲染到视图里，而需要手动设置，但看 lz 的教学似乎不是这样？

@CivAx 老哥这是程序和设计全算的工作量？那算下来工资成本应该是两个人 x 工作月，合计在一万美元左右？比想象中落差大啊，记得以前有新闻说 R 星做大表哥 2 花了七亿美元，算下来是这个单独场景的七万倍，感觉不太对。

感谢 LZ 开发便民功能，不过个人感觉不是个很好的方向，因为本身这类软件服务器成本非常高，但是 C 端又没有入口，腾讯之类的公司随便一抄就能打垮所有同类竞争企业。。。

@Renovamen 我是 windows10 20H2 chrome 版本 90.0.4430.93

@Renovamen 我发帖的时候就是单纯陈述一下项目来源，后来读的时候感觉确实是挺凡的。我这看是这个效果，全屏之后右面的滚动条会跑出来，且仍然能够拉伸大小，拉伸时绿框部分会多出一张桌面背景被一起缩放。拉伸过后如果取消最大化的话这个样式会继承而没有取消
<img src="https://i1.fuimg.com/706005/4e14a5c21bdf7f6d.png">

有点意思的问题，读下来似乎楼主是认为 stcp （还是叫 xtcp ）的那个 api 在 client 被爆破后可能用来向 server 上传不安全代码，所以用 http 转发就比较安全了？一个疑问是他那个 http 转发支不支持 tls，不支持的话不是裸奔传输，本末倒置。

哈哈，我要举报楼主抄袭我的凡体文。也许这里可以看出 react 生态远比 vue 生态强势的地方，目前看到的包括楼主的在内的三个 macos 和一个 ubuntu 都是 react 写的，感觉以后如果要学习的话都是不错的参考资料。另外捉个虫，我默认状态打开之后，如果开启 safari，并点击全屏按钮后样式会变得奇怪。

@sky96111 我实测就是 virtualbox 会黑屏，新建虚拟机不能操作，无法挂载镜像

@8e47e42 没看懂，他说 vmware 会使用 whp，也没见说哪里要经过特别设置才能用

算法的话，个人想法是，首先将每个等式标准化，然后依次搜索出现频率最低的变量，将其消去，最后求解。循环直到所有变量都解明

@oppoic 也许是看中了插件的权限？这种已经有一定存量的如果被拿去做灰产，破坏性很大的吧

大概本质还是因为前端程序员的水平差距像海一样深吧。。es6 之后，在良好的编码规范和良好的注释下其实可以达到 ts 相同效果（由于没到语言级别规范，IDE 补全方面会有缺失，不过总体而言堪用）。但实际项目中很难要求前端程序员严格遵守这些规则，由此产生了屎山。

这个问题可以分为几个方面。单纯表现上，pypy 在主流编程语言的 jit 解释器里基本排在最后一名或者倒数第二名，不过客观上讲这不是由于 pypy 技术落后，单纯是因为 python 本身是一门非常动态的语言，这给 jit 带来了很多难题，即使使用了 partial evaluation 等技术，同样难以优化到 java jit 的水平线。

不过 pypy 项目的存在本身也是开发效率即解释效率的一个例子，很多人坚持否认的，认为高效开发无用，实际上 pypy 已经出来这么多年而 cpython 的 jit 仍然在难产足以说明问题。可以想见的是如果 python 的一些现代特性被早一些加入的话，各应用领域（比如 web ）当中的市场份额可能会有大翻转，这也体现出互联网项目推广中的时也运也的一面。

具体坑的层面的话，一个共识是 python 一直以来的运行生态，从不依赖于 jit，可以看得出来 guido 从设计层面认为 ffi 扩展相比于始终不理想的 jit 是更好的解决方案，这也造成了目前的 py 生态。而 pypy 的 cffi 效率和兼容性差几乎成为制约其发展的主流因素，这也是为什么 pyston 这种提升很少性能，但具有完整嵌入支持的项目，即使仍在闭源状态，许多人仍然更看好它的因素。

python 优化的另一个方向可能是最近的 mypyc 项目，我觉得这个方向是对的，一如当初 cython 在 py 中引入类型后效率直接起飞一样，虽然这套方案在今天已经有更好的选择。很多事情如果程序员能低成本地实现，那么不要交给程序，程序处理起来反而会很复杂。

@IgniteWhite 我不是完全从头做的意思，我的意思大体上是希望使用通用材料进行组装，而不是专门为航模设计的产品进行组装，比如具体到芯片的话，我希望使用通用的开发版之类的，而不是专门设计出来的一个由别人做好，卖给航模爱好者的类似黑盒的东西

@billlee 风筝的话，小时候做过，印象中应该是有卖的蒙皮和骨架，只需要自己缝上之后拉到广场上就能飞了。我如果叫我现在做个风筝的话，我感觉主要问题可能是把龙骨烧成指定的形状最困难，具体形状方面我觉得照猫画虎应该不至于偏差太大，蒙皮方面应该是能买现成的，我觉得这些技术不太能跟航模对应的类比。因为我设想里外壳是通过 3D 打印出来的，如果叫我用木条和蒙皮组装一个空心骨架的话，我觉得难度一下会高很多