买个空调吧，也不贵哪怕二手的呢。
压缩机制冷之后降低湿度，风扇没用的，一旦下雨更闷热。

从逻辑上就不对 早 9 晚 9 晚 9 早 9 每周 6 天 不是早就约定好了的吗

ai 起码在可预期范围内都还是工具功能范围的存在。
不能用现在的认知去理解以后的世界，以目前来看的取代或减员重复低端岗位是必然的

你像让粉丝花钱刷票打榜你来赚钱？
你看微博同不同意

微信不就是吗

800 能买冰箱和洗衣机吗。。。。
是不是我认知有问题啊。。

@dandankele #25
举个例子说明下
情况 1
假设你提供一个接口 A
接口的功能是通过 Http 调用外部接口接口 B 接口响应时间是 100ms
那你的接口响应时间 100ms+ 无论是 go 还是 php 对吧。。。

情况 2
假设你提供一个接口 A
接口的功能是通过 Http 调用外部接口接口 B 接口响应时间是 100ms
同时还要再依赖接口 B 的返回值去调接口 C 接口响应时间是 100ms
那你的接口响应时间 200ms+ 无论是 go 还是 php 对吧。。。

情况 3
假设你提供一个接口 A
接口的功能是通过 Http 调用外部接口接口 B 接口响应时间是 100ms
另外去调接口 C 不需要依赖 B 的返回值 接口响应时间是 100ms
使用 go 和 swoole A 接口响应时间是 100ms+ 因为是协程并发调用 等待时间以最长的为准。
这种情况下用 go/swoole 可以改善响应时间 但 swoole 和 go 的差距并没有那么大

同样逻辑适用于写库 调接口各种 io 等待的同理
串行依赖意义不大，可以并行才能降低响应时间

你需要考虑有哪些业务是适合用 go/swoole 去写 而不是说上来就重构。。。
几个接口的任务量和一个系统重构的业务量是两码事。。。

@dandankele #25
https://www.techempower.com/benchmarks/#section=data-r21&hw=ph&test=db&l=zijnjz-6bj
权威测评 不是我乱说

无理由臆想质疑拿数据说话吧。

webman 和 swoole 改 go 提升是很有限的
改 go 的主要目的是提高单机并发数
至于原来的业务假如有调大量的外部接口和流式执行依赖查库性能并不会有多少提升。
提升比较大的是需要从数据库查询大量数据之后做处理这个部分的耗时
laravel 的性能确实比较垃圾 毫无疑义 但已经不是现代 php 了
用 laravel 的底线是要上 octane

@KKLeon #89 你的意思是
主路由拨号并且设置统一网关为旁路由 ip
dhcp 下发旁路由网关。。是这个意思吧。。
稳定性主要取决于旁路由自身是否稳定 流量还是全部都走旁路由过一下

@KKLeon 所以是不是每个要走旁路由的设备都要设置网关？是不是你的旁路由只要挂了就上不了网了？有其他方案吗

垄断+没有医保

@tzwm 这位说的一点毛病没有，补充一下很多开发感觉产品很简单很好做的地方。
这个岗位如果没有强势行业背景背书和业绩基本是要被开发和业务部门怼死，你说的话写的需求没人听的。
天天被 pua 是基本常态，能力不行的时候被研发部门素质不好的人阴阳是普遍场景，心态不行直接爆炸。

产品的 leader 就是分两种要么极强一般是单干做合伙人和职业经理人的很少去公司任职，其他熬资历上来的人什么德行就不好说了，比技术 leader 普遍要差，加班只会比技术还多。
我司一个很负责任的产品天天要盯进度测试要一起测上线之后开发都休息了还要验收，出了问题还要背责任。

这个钱找厂主搭一条专线了。。。

13.4.1 啥事都没有。。。。

无非把零度换成无糖气泡水
有没有那甜味儿无所谓 我只需要带气的冰水罢了