@foam 我觉得基本上未来就是 Kube/Docker + Serverless Function
然后 IaaS 就用来自搭 Kube/Docker 或者 Serverless 或者 BaaS 或者跑一些老旧服务
纯 PaaS 估计要被淘汰了


@murmur 对于小厂 虽然交出了数据和控制权 但是省下了运维人工费
这个对于初创公司而言 意义就大了 找 1-2 个开发和测试 产品都不用写完就可以上线了

@love 对于 php 的特殊性 对于纯开发而言 确实没什么区别 可能虚拟主机还更方便 因为不用部署 直接上传即可
但是对于运维而言 区别还是有的 首先不需要配置虚拟主机 而且也不用考虑扩容的问题
对于收费也不一样 如果持续都在用 估计会更贵 但是如果用的频率低 那么费用会大幅减少 说白了就是没人用的话 你基本上也不用付钱

不是大神 只是我自己的理解 你说法有点不对
HTTP/3 就是 新版 QUIC 其实就是换个名字（或者是 QUIC 被标准采纳成了 HTTP/3 ） HTTP/2 就是 更新的 SPDY
HTTP/3 是把传输层的 TCP 换成了 UDP

如果存粹基于 HTTP 协议的应用协议 如果兼容 HTTP/2 没问题 那么对于上层应该是透明的 因为 API 基本上一样 可能只有写细节估计要处理
但是 HTTP 1.1 和 HTTP/2 区别还是挺大的 HTTP/3 其实就是把 HTTP/2 的底层改了

另外我们一般把云服务分成 IaaS PaaS SaaS
IaaS 其实就是可以用 API 自动管理的虚拟机 VM 比如 AWS EC2 和 GCP CE
PaaS 其实就是“弹性”的虚拟主机加某个语言的运行时 可以是基于 VM 也可以基于容器
SaaS 其实就是应用本身了 一般 SaaS 要用 PaaS 或者 IaaS 来运行

作为基础的 IaaS 目前其实就那样了 只需要提供效率，速度和加强管理能力
但是 PaaS 比如 GAE/SAE/BAE 现在已经愈来愈不流行了
因为出现了 CaaS (容器即服务) 和 Serverless

CaaS 即可以当作是一个更加灵活的 PaaS，你可以随便定义自己需要的环境；也可以当作是一个更快更轻量的 IaaS，启动时间大大减少，扩容也更加容易 介于 IaaS 和 PaaS 直接

Serverless 就上上面说的就是一个简化版的 PaaS 你只需要提供 Function 来触发即可 而且可以支持多种语言 收费也更加弹性 可以理解是比 PaaS 更加接近 SaaS

Serverless 可以看作是 GAE/SAE/BAE 这些 PaaS 的进化
GAE/SAE/BAE 只是提供了一个弹性的虚拟主机加运行时环境
你在 GAE/SAE/BAE 上面写的 App 还是一个独立的 server
既然是服务器你既要一直跑着 如果停了 你的功能就停了

Serverless 其实就是在 PaaS 基础上 你这个常驻的 server 不需要了
你直接提供一个 Function 然后由 Serverless 服务来触发
而且这个触发条件也很丰富 不一定要 http call 了

另外由于这个触发的模式 那么计费的方法也就完全不一样了
PaaS 或者其他形式的服务 就算没有人用你的 你的 server 还是得跑着 那么就要付钱
Serverless 默认情况下 如果没有人用来触发 Function 一般情况下你就不需要付费

外企估计会有黑名单吧

@jjianwen68 基本上和当年网吧里面玩的效果差不多 挺不错的

@raoxiaowen 但是这样影响 Apple Pay 的使用吧

@tesorouo 现在大部分硅谷科技公司 基本上研发大都是三哥 不管是高层中层还是底层码农 基本上要占大多数
本来华人比例就逐年减少 这次贸易+疫情 会导致越来越少的华人有机会进入这些科技公司 而且华人也更加难得到晋升的机会了
与此同时三哥们越来越多 越来越高层 又特别抱团 加上积极参政 这些科技公司迟早都会变成三哥主导的公司的

inc field 这个操作本身不是幂等的
直接放到 PUT 和 PATCH method 都不合适

比如 /object/11111/count 需要 inc 操作
那么 PUT 和 PATCH 都应该是直接对 count 进行赋值 而不是 INC 的操作
而赋值是幂等的

如果非要支持 INC 操作 那么应该用 POST 比如 POST /object/11111/count/inc 或者 POST /object/11111?op=incCount 这样比较合适
PUT 一般对应 db 的 replace 功能 替换记录
PATCH 一般是 update 功能 部分修改

@fuzhuo233 虽然$6.99 不是很贵
但是没有试用期来决定是不是值得买
有没有可能可以有个 Coupon ？

LZ 这么牛逼也才一个 Sponser 啊
我们组所有项目都在用 ioredis

@xiaoming1992 自己动手能力强 而且喜欢 webpack 就好办了
不然信任 react-app-rewired customize-cra craco 这种现成的
自己 require override CRA 的 webpack config 就好了
我就这这么做的 具体怎么做 参考 react-app-rewired customize-cra craco 的核心就好了
就是几个 require.cache[webpackConfigPath].exports = function 就是了

Override CRA 的 webpack config 就是
自己搞不定用 customize-cra 也行

@xuanbg 不会多余 毕竟 OS 不一样 除非 Apple 能够让 iPadOS 强到可以和 macOS 一样
终极目标可以是用 iPad Pro 替代 MacBook/Air 甚至 MBP 短期内是不现实的

@cwbsw 目前用 ARM 来代替 MacBook 和 MBA 或者 Mini 还是可以接受的 但是代替 MBP 或者 iMac 短期内是不大可能
当然 Apple 可以同时换 但是这样可以还要过好几年 但是前面这些是可以先换的 以现在的水平 除了第三方软件的生态 没什么大的障碍

对于 MBP 而言 ARM 那套目前的最强性能还没办法和高端的 x64 CPU (i7/i9/Ryzen) + 独立 AMD GPU + 16G+ 内存抗衡
所以定位没办法太高 加上专业软件还不可能一时半会儿从支持 ARM 构架 强行让 MBP 上 ARM 专业人士不会买账的
专业一些的应用 比如虚拟化 GPU 加速运算或者渲染 软件的交叉编译 ARM 下也远没有 x64 上面成熟
而且配套硬件 ARM 也远没有 x86 构架的成熟 比如 TB3/USB4 外接设备之类

所以用 ARM 在低端入门或者便携本上试水是最好的选择 而且可以显著的改善续航和散热 加上 iPad 上面已经成熟的蜂窝网络加入
那么就可以搞一个 5G 长续航版的 MacBook 或者 MacBook Air 定位也很明确 消费者估计也会更愿意买单 而且可以比 iPad Pro 更加受学生和白领的喜欢 不至于是个玩物

什么时候 ARM 可以搞到个什么 32 核心 64 核心 配上更加专业的显卡 超大内存的时候 MBP 上 ARM 就没有任何阻碍了 而且到那个时候估计硬件和软件的生态也相对会更加成熟一些

换 ARM 估计是和 Windows 那种 5G 长续航便携本竞争的 和 iPad 定位更加接近
所以上 12 寸或者 Air 可能性比较大

MBP 肯定不会太快换 ARM 不过会有 ARM 核心（现在已经有了）估计也会开放给 App 用 这样可以节能
比如待机的时候 可以有类似 iOS 的后台功能 类似现在的 PowerNap 但是开放给所有 App
就可以用 ARM 来执行一些操作 不用唤醒主 CPU

这次 13 寸没上 14 超薄边框 应该是因为太难上 时间不够
我问过一些业界的人士 16 寸超薄边框已经非常艰难了 14 寸更要难的多 比 16 寸多半年时间估计都不一定够

XR XS 升级 13 后偶尔也会遇到

估计大概率是蓝牙信号干扰
排除触摸板本身的问题 可以用 lightening 线直接插 mac 试试

iPhone8 其实如果你保养的好 没有什么性能需求 确实没什么好换的
但是 iPhone8 已经两年了 很多人差不多都用烂了 除非自己换过电池 否则至少电池也不行了 那么换一下相对于买了一个新版 iPhone8

但是现在还有很多事因为不喜欢刘海或者喜欢 TouchID 还在用 iPhone6/6s/7 甚至 SE
那么换 SE2 还是很不错的升级选择