songray

意义不大。

preact signals 是浅层响应式，也就是 const foo = useSignal([])，你必须要 foo.value = newVal 更新引用才会触发视图更新，而且这种情况会走 vdom diff ，和 react 没啥区别。

官网说的性能好主要是针对单值场景。比如 const foo = useSignal('a'), <div>{foo}</div>, 这个情况下会绕过 vdom diff ，直接更新 dom ，性能会比较好。

现在这个版本我更推荐直接开 react compiler 得了...

当年校招进了教育行业的某头部公司，一个文件三万行，我的笔记本光是启动服务就要 5 分钟。
后来我正考虑要不要跑路的时候，公司把我们这一批校招生全毁约了，不知道算好事还是坏事（难绷

@linxuan716 如果计算和数据量增长是一个平滑曲线的话，我建议还是给服务器配置留下余量就好。

@linxuan716 k8s 的场景是，有时候你的主服务或子服务的流量会暴增，或者是你的业务天然需要部署多个相同服务（比如需要尽可能靠近客户端的边缘计算场景）。
那么你需要 k8s 作为编排器，为你管理这些服务，自动扩容、修复这些服务。
你这种场景主要是维护依赖关系和自动恢复的话，还不如用 kamal 之类的命令式工具。
https://kamal-deploy.org/

@linxuan716 k8s 主要是解决横向扩容场景的。你这个不应该用 k8s 。

跟规模没关系，跟业务有关系。
如果你的业务单机 8c 32g 不能支撑的话，基本就要上 k8s 分布式了。（不过据我观察这样的业务很少）
很多人觉得 k8s 是引入复杂度的，其实这玩意是分布式奶嘴，没这奶嘴更痛苦。

我觉得打开 BOSS 直聘搜职位更能看清现在的需求...
Flutter 的岗位量和 uniapp （小程序） 之间差了不知道多少个 RN 。

@Chuckle 那无解了兄弟。
React 两大原罪，一是 state 颗粒度太大，二是从根开始 diff ，上游的问题你没法从下游解决。

@Chuckle 用 Mobx 或者直接一步到位 Preact + Preact signal ，目前用下来 Preact 没什么兼容问题。