weixind

@stevezhengs 闲鱼是移动端上了一部分 flutter 页面吧。

@ersic
这几个点都不太能够支撑切换技术选型。
性能方面：高并发场景内存占用大并没有做具体分析，我没深入使用过 electron ，但是如果高并发的内存占用成倍增加，大概率是他们使用姿势有问题。内存占用无非就是 node 进程 + n * 页面进程。能缩减的就是 node 进程 ---> rust 进程。这不太能缩减多少内存占用。
安全方面：这个有点扯淡，本质就是说 node 内存安全性不如 rust 呗，前端的切换没啥意义，这个不能支撑切换技术栈。
体验方面：80m 在现代网络和硬件下可以忽略不计。
信息集成：这看上去是产品问题，不是技术问题。

包体积 7M ，Electron 80M 下降 91.25%。

平均内存占用 249M Electron 497M 下降 49.9%。

平均 CPU 占用百分比 20%，Electron 63.5%下降 63.19%。

没啥参考价值。

1.得物商家端用户量不会很大，ToB 甚至可以点对点兼容。
2. 不利于招聘，会 rust 的前端要比会 node 的前端小一个数量级。
3. Tauri 没有什么 Electron 做不到新 feature 。
4. 我一直不太喜欢用新技术来刷 KPI 的团队和技术选型。

我自己对技术选型有一个要求：贴近业务实际,能够满足当前业务需求,也预留扩展空间,但避免过于激进,确保交付的产品和系统具有实际价值。

已经在用，在爽了。

1. 制定验收规则，不按照你要求就不合代码等。
2. 不遵守团队规范 不是挑战你，是挑战整个团队，直接拒绝合代码。
3. 技术问题归技术讨论，“xxxx 就是这么做的”不能作为方案的充分条件。
4. 增加团队透明度，所有事情由你作为分配方，他分配的工作任务不算产出就好了。
5. 你做好向上汇报。

单休的公司不太用考虑员工年轻化的问题。基层干活的员工 35 岁了基本上就是“要么死，要么走”。