只要涉及跨境回源，用户体验都会比较差。比如数据在国内 OSS ，海外用 CF 回源国内；或是数据在海外，国内用阿里云 CDN 回源海外。因为通常 CDN 厂商回源并没有跨境优化，就和咱们普通上网一样，跨境速度和稳定性稀烂。
你可能会说回源只有少数几次，后续都能在边缘缓存。但各个边缘节点都有自己的缓存，但如果你的访问量不大并且地域稀疏，那可能用户很难命中缓存。

最稳定的方式是自己解决跨境这小段的链路。
例如，数据在境内，在 HK 搭建一个 reverse proxy 。分区解析，境内用阿里云 CDN ，海外用 CF ，CF 回源指向 HK 。境内到 HK 这一段，自己通过各种隧道技术来加速（类似平时上网翻墙一样）。

这就是 nextjs 广受诟病的地方：强推 SSR / RSC ，为了卖自家 Vercel 的商业服务。
对于很多类型的项目，比如你提到的工具类网站，以及后台管理系统，SSR/RSC 属于最不重要的优化，但会因此让开发和部署变复杂很多（如果不使用 Vercel 的话）。

Nextjs 爆火也就是最近一两年的事情
抛开功能原因，我觉得能火的关键要素是，Vercel 摘了 Meta 的桃子。
这几年正值 Meta 降本增效，react team 在 Meta 内越来越边缘化。Vercel 趁机挖了很多 react team 的人，废了 create-react-app ，重构了 react 官网并借此把 Nextjs 放在头号位置（导致现在新人入门 React 几乎必须从 Nextjs 开始），并几乎控制了 react 未来方向。
React 18 稳定版停更一年多，而 React 19 新功能明眼人都看出来是给 Nextjs 量身定做的。就像楼主说的，“倒也没感觉没有 SSR 就罪恶到要枪毙”，React 痛点那么多，react team 偏偏把主要精力放在了 SSR 。
到头来 React 19 真正的亮点 - React Compiler ，还得是出自 Meta 团队。

目前公司用 grpc + thrift ，甩开了 protobuf 的负担，感觉体验良好。

有 schema 对项目长期维护很重要。
跨语言也很重要。因为保不准团队里就有人想用其他语言来写一部分服务。
我公司内主要是 go ，后来陆续引入了 java/python/nodejs ，大家都在 grpc+thrift 下工作良好。thrift 的代码生成效果也不错。
不过缺点是 thrift 生态还是比 protobuf 差了一些。

玩一玩氪金网游，包治电子 ED

不知道国内安卓推送现在体验如何了，特别是 gmail / slack / teams 这些没有落地中国的 app 。

我是更新狂魔，每周更。okpg update && opkg list-upgradable | awk '{print $1}' | xargs opkg upgrade 一条龙
遇到大版本我是手动更新：手动替换 kernel ，手动 diff rootfs ，把新的东西拷贝过来，旧的 kmod 删掉，手动同步 opkg 状态文件。

我远程的第一第二年很喜欢到处跑。后来时间长了新鲜感褪去，真正能长期舒适办公的地方还是只有家里书房。

有进体制内的想法的话必读

不进体制的话，就观察身边统计而言，硕士学历意义不大，即使是 985 硕

续航下降，不能像过去一样长时间集中精神

对比之下，这么说 react 从 class component 迁移到 hooks 的过程，比 angular 1->2 / vue 2->3 成功太多了。

potplayer + madVR

xda 用 letsencrypt 证书，letsencrypt 的根 ISRG Root 在老 Android 上需要手动安装。

后期可能私有化客户还有定制需求，分支管理会更复杂。

同时支持 saas 和私有化部署，要求本来就挺高的

如果是单纯以私有化部署为目标的应用，从最初技术选型就会很不一样，开发、发布流程也可能和 agile 相去甚远。

既然你已经提到了你们是按照微服务开发的，那注定私有化部署不是个容易事了。
如果以私有化部署为目标，一开始就应该选择单体应用。

上工具吧，helm 、terraform 、ansible 等等。如果客户是云环境，那还可以用各大云自己的 IaC 方案，比如 AWS CloudFormation 。相比之下，单体应用就没这么复杂，打个 zip 包丢给客户就行。