docs(nextjs-tech-select): update doc

Author: json-q

post/dev/nextjs-tech-select.md

@@ -1,15 +1,15 @@
 ---
-title: 记录一次团队 Nextjs 的项目搭建及技术选型
+title: 记录一次团队 Nextjs 的技术选型
 date: 2025-03-28
 ---
 
-# Nextjs 项目搭建及技术选型
+# Nextjs 技术选型
 
 ## 背景
 
-内部要做 AI 相关业务，由于 deepseek 的开源，使得相当多的公司都可以进行私有化的 AI 部署，然后需求下来，开发这边就只能研究一下了...
+内部要做 AI 相关业务，由于 deepseek 的开源，使得相当多的公司都可以进行私有化的 AI 部署，然后需求下来，开发这边就只能研究一下了 ~~一块砖而已~~...
 
-目前采用 RAGFlow 做知识库管理及模型的调优，但是 RGAFlow 本身是不带权限控制的，不适用于公司每个部门的独立知识库，所以需要自己做一套权限控制，且 AI 对话需要和交建通对接，就意味着要兼顾 PC 和移动端
+目前采用 RAGFlow 做知识库管理及模型的调优，但是 RGAFlow 本身是不带权限控制的，不适用于公司每个部门的独立知识库，所以需要自己做一套权限控制，且 AI 对话需要和第三方软件对接内嵌，就意味着要兼顾 PC 和移动端
 
 - 独立的权限控制意味着需要一个独立的数据库进行管理
 - 对话等大部分接口调用 RAGFlow 提供的
@@ -18,34 +18,40 @@ date: 2025-03-28
 
 ## 技术选型
 
-不管选什么技术，一定要记住，你认为的最优解可能对个人来说是对的，并不一定适合你的团队。因此在选择技术栈时，哪怕对你来说非常合适，也一定要优先考虑团队，当然如果项目只有你一个人负责就无所谓了。
+不管选什么技术，哪怕对你来说非常合适，也一定要优先考虑团队而非自己独断独行，当然如果项目只有你一个人负责就无所谓了。
 
 ### Nextjs
 
 由于 AI 对话方面就是做一个简单的权限控制，不涉及特别复杂的业务，上 Springboot 的话有点大材小用了（java 也是我们写，我哭死），这种情况下，直接选一个全栈框架是最合适的。
 
-因为内部主 React，选 Next 也是理所应当。
+因为内部主 React，选 Next 也是理所应当，全量的 TS，团队有使用 TS 的经验，所以问题不大。
+
+个人观点：使用 TS 的优点绝对是大于缺点的，在业务逻辑越来越复杂的现在，友好的类型约束和提示能给团队带来的收益是毋庸置疑的（外包项目和要求快速出产品的除外）
 
 ### 组件库 antd
 
-我个人是非常希望使用 shadcn 的，因为很轻量，产物体积小，对于兼容移动端的情况下更适合，但是考虑到团队内部都是常年写后台的，而且对 tailwindcss 并不熟练，只能退而求其次，选择更 “重” 一点的 antd，这也是没办法的
+我个人是非常希望使用 shadcn 的，因为很轻量，产物体积小，对于兼容移动端的情况下更适合，但是考虑到团队内部都是常年写后台的，而且对 `tailwindcss` 并不熟练，只能退而求其次，选择更 “重” 一点的 antd，这也是没办法的
 
 ### orm 框架 drizzle
 
 为什么不是 prisma？
 
-其实在 Nextjs 中，prisma 是使用最多的 orm 框架，我也尝试了一下 prisma，但是很遗憾，它并不适合我的团队。因为 prisma 更像一个大而全的 orm，内置了非常多的功能，和对应的上手难度和学习成本。
+其实在 Nextjs中，`prisma` 是使用最多的 orm 框架，我也尝试了一下 prisma，但是很遗憾，它并不适合我的团队。因为 `prisma` 更像一个大而全的 orm，内置了非常多的功能，和对应的上手难度和学习成本。
 
-drizzle 是一个非常轻量级的 ORM，我第一次看文档的时候就觉得这个 orm 非常合适，因为 drizzle 只是对 sql 进行了一次很薄的封装，所有的 API 和 原生 sql 基本保持一致，意思就是只要你会 sql，你就能很轻松的上手 drizzle，学习成本是非常低的
+`drizzle` 是一个非常轻量级的 ORM，我第一次看文档的时候就觉得这个 orm 非常合适，因为 `drizzle` 只是对 sql 进行了一次很薄的封装，所有的 API 和 原生 sql 基本保持一致，意思就是只要你会 sql，你就能很轻松的上手 `drizzle`，学习成本是非常低的
 
 ### pnpm workspace
 
-为什么使用 pnpm workspace 呢？
+为什么使用 pnpm workspace？
+
+其实当时规划的时候，有考虑到服务端的迁移，因为信创是趋势，一旦使用国产数据库，node 生态是不可能存在支持国产数据库的插件的（达梦数据库有对 `typeorm` 进行 fork 兼容，看了一下改动，~~其实就是 `oracle` 套壳，还声称高度兼容 `oracle`，只能说国内公司是会弯道超车的~~）。
 
-其实当时规划的时候，有考虑到服务端的迁移，因为信创是趋势，一旦使用国产数据库，node 生态是不可能存在支持国产数据库的情况的，到时候只能使用 springboot，所以尽量将 drizzle 构成的服务端代码单独抽离，这样如果真的需要迁移，也能够在不和客户端代码耦合的情况下，减小迁移成本。
+在 node 生态不满足的情况下，只能使用 springboot（`MybatisPlus` 对国产数据库的支持性挺好的），所以尽量将 drizzle 构成的服务端代码单独抽离，这样如果真的需要迁移，也能够在不和客户端代码耦合的情况下，减小迁移成本。
 
 其次就是一个聊天对话组件和逻辑了，将这一部分抽离，只专注于聊天组件的封装和逻辑处理
 
 ### linter biomejs
 
-说实话，做这么久的项目，已经对 eslint 和 prettier 插件的启动速度、formater、linter 的速度折磨的够呛，更别提在 workspace 下的启动速度了，所以这次索性用 biomejs 来做项目的基础 lint 和 format，只是在 nextjs 中再使用 eslint 来处理一些边界问题
+在前端工具链 rust 化的现在，使用 rust 的 linter 显然能够极大的提升开发体验，而且这部分只需要做基础配置，团队成员基本无需关心。
+
+其实在本人在自己写项目时，使用 eslint 和 prettier 也经常会吐槽，插件启动和扫描文件速度很慢，而且在做 `lint-stage` 时，文件越多，需要的时间就越长，这个缺点也会更明显。