前后折腾了一个多月，几点分享下。
至少到目前（2023.11.30）为止，Nextjs的App Router必须依赖Node的API，指望Bun直接替代尚不行。换言之如果想享受运行时提速，要使用pages路由。
对旧有选择T3技术栈之类的项目，可以尝试更换Bun作为运行时和包管理器。前提是测试要做足够，打包方式的变化会有同npm等打包方式不兼容的问题。尤其是和Bun自带功能重叠的第三方包，Bun团队对此类包不兼容issue的态度往往是建议使用Bun自带的功能。开发资源有限的情况下官方的态度不能说错误，但是使用者要自行衡量重构的风险和收益。
服务端上npm、yarn、pnpm最近两年这三个货已经混战成一团，现在又加上个Bun、实在是不想多说什么。可以预见，ENOENT会成为混用后的常态。
Bun在实际项目运行中速度提升方面，基于各类项目的输入的数据类型、处理方式和次序等诸多不同，没办法做横向比较。
只能表述个人测过、摒弃掉不兼容的第三方包之后的体验：若项目能顺利跑起来，同等硬件条件下同时间内能处理的网络请求量，增加幅度至少是50%起跳。比某些号称能追赶Go的评测差很多，但是比Node显然是强多了。
可问题是，众所周知全栈的瓶颈多在数据库方面。光运行时带动的加速，放在实际部署中受限太多。巨头早就靠静态语言布局，具体业务赛道的需求场景有多大尚未可知。存量市场中相当大比例php和python写成的项目还跑的很正常，很难想象带着Bun运行时的TS/JS去这边攻城略地。
另外Nextjs的部署问题一如既往，Vercel方案初期很方便、后期成本不划算（当前时期）。自行部署的坑存在、且需要时间踩，尤其是版本号14之后的Server Actions体现明显。
生产环境自行部署、用容器更方便，需注意podman和docker制作出来的镜像（build之后）处理Server Actions还存差异。涉及导入字体等需要境外服务器源的，在国内使用建议用平替。
