目前前端开发的大环境变更频率没有过去几年那么快了，感觉此时正是技术选型固定，沉淀 最佳实践 或 最佳方向的好时机，后续会在这个专栏中：
持续更新真实项目 分析、选型、调研等相关内容，根本目的在于持续强化个人的产品分析能力，及技术广度，同时分享给有兴趣参考的各位。
前情提要
在 上一篇 中我们对本次开发的项目，做了基本的 背景介绍 和 需求分析，现在是开发的起步阶段，作为一个从零开始的项目，基础框架的选型很重要。
项目是React C端应用类，由于直接使用已有的 openai 接口，可预见的是暂无复杂的后端（server、db）需要，是一个 偏前端/纯前端 类型项目，重点在后续功能的实现，所以最好能快速生成开发环境（具备项目生成模板、提供热更新的dev-server），具备常见资源的编译链路（webpack / vite / postcss的基础配置）。
平常开发中使用的 umi.js 是肯定能满足开发需要的，但也是想多看看别多方案，且 umi 本身也是偏 B端中台类，ssr、JAMStack、rsc（react-sever-component）这些 C端应用 所需的支持不是重点。大致看了下，目前已有的方案可包括：
以上的框架大多具备了 ssg 功能，即在文件开发中添加 node server 端逻辑，如调用某个请求结果 或读取某个外文件内容 存入状态或直接生成 html 内容中，在编译期这类 server 端逻辑会被执行，继而生成最终产物的前端文件，生产端省去了再次访问 sever 获取以上内容的过程，网页继而可以纯静态部署，这个过程也叫预渲染；
remix、astro 是相对较新的两个框架，astro 使用了一种叫 island 的新架构，算是 ssr 的一种新实现，目的在于较原页面层级渲染拆分，转为组件级别的渲染拆分（类似 server-component 又不太像😭）增长很快，主打web性能的极致增强，个人理解后举个例子就像，进入一个页面，需要点击button才渲染一段长文本，这段长文本应该在点击发生后，再去获取 html，初始加载即可省下获取长文本块的时间。框架也偏向静态生成类项目，弱富交互类项目，框架本身的应用广泛程度未知。
remix 与 astro 的宗旨类似，重视加载性能及载入中体验，主打全栈，本身是依托 react-router 团队延伸的项目，更像是在现有基础上的前端框架再造，偏向一个新概念的大而全框架，也有基本的 ssg、渲染拆分细化等，给人还在发展中的感觉。
Gatsby.js 与 Next.js 也都具备 ssg 功能，本身也是 jamstack 架构起家的，及web基础 + 自有平台，只是 Gatsby.js 貌似只有 ssg 功能较全，其他应用开发需要的功能一般。
其中 Next.js 可以说是目前最流行的网站开发框架，原因主要在于他也是典型的大而全，且经历了众多生产项目的验证大致吸引我的有以下功能：
- 支持多种预渲染模式；
- 内置多种文件优化；
- 同时提供了 开启ssr的产物（server + website） 和 纯静态产物 (website 即 html + js + css) 的两种编译产物方便用户自行选择部署方式；
Next.js 也背靠 vercel 平台，支持一键部署，是快速验证项目的好帮手。
除了 ssg、ssr 等常见的开发可接触类的，astro、remix、next.js 都提出了 edge runtime 的概念，个人理解是前端全栈的新形态（前端形态真多），但需要搭配一个 edge-runtime 平台去完成，如 cloudflare、deno 这样的，具体了解不多，还需继续学习。
更多可自行了解：edge-runtime.vercel.app/
目前也有较多比较类文章，感兴趣可查看：
www.commoninja.com/blog/astro-…
虽然 astro、remix 很新，很具备吸引力，但最终考虑普适性、稳定性还是选择使用 Next.js（人菜、怕坑）。
目前 Next.js 最新为 13，关注最新动态时，发现出了一个 appDir 模式。
大致了解了下，主要是对 react-server-component 的实现支持，查看框架源码时也可见与之前的模式有较大区别，一些底层组件 Error、Router 也都是完全不同的，还是试验性的功能，且没法纯静态导出（都server-component了，必然是要有个server的），限制还是挺大的，所以还是选择使用普通的 pagesDir 进行开发。
next.js 项目的结构是比较清晰的，默认基于文件目录对应页面路由。所以 pages 下的 index 就是根路径下的页面文件，而 _xx、global.xx 则是一些约定的定制文件，用于修改全局默认初始加载、全局样式、html模板文件等，
可见 umi.js 的设计也参考了此处，在文件结构上基本是一一对应的。一个前端开发框架内部的实现细节是很复杂的，横跨插件式框架设计，多方案编译链路搭建等，好在我们只是做个应用项目，暂不关注反而更合适一些。
具体文件代表意义的详细信息，都可以通过官网的 routing 章节继续了解细节：
Next.js 项目的从零开始很简单：
pnpm create next-app
按命令行引导，选择可选功能的开启关闭，一些信息确认，然后就没了，可以启动了，非常快捷高效。
官方 examples 中也提供了众多与其他主流工具/框架结合的开始模板，可以参考：
如这个配合 docker 部署的例子：
最终部署时 docker file 肯定还会做些修改，会在后续的部署章节进行补充
基础框架调研的过程中遇到了很多新名词、新概念，其实挺一知半解的，我该收回前端发展放缓的话了（也有可能是自己学习速度太慢），分析也较浅，但偏保守的选型还是能确认最终方案的，过程是纠结的，但也是很好的学习机会。
调研的过程还是偏纸上谈兵一些，后面先做一些基础功能的实现。
下一篇预测：ChatGPT对话类项目开发 - 流式对话实现
本系列中间过程的记录：《chat 对话类项目开发实践》比较杂，仅供参考；
另外还有个人的每日学习专栏，感兴趣可以参考 www.yuque.com/jhonxy/note
