如何选择一套能持续交付的 SaaS 技术栈

围绕产品约束做选择

在比较框架名字之前，先写下产品需要什么。Web 控制台、离线移动工具与长时运行的研究工作流有着不同的约束。确定你需要哪些客户端、哪些数据属于每位客户，以及哪些操作必须在浏览器标签页关闭后继续。

把团队经验与功能清单放在一起考量。边界清晰的熟悉技术栈可能比更新潮的组合更易维护——后者要求同时学习认证、部署与持久化约定。要计算升级与调试的持续成本，而不只是首次安装。

• 第一天就需要哪些客户端形态——只要 Web，还是也要移动端和桌面端。
• 哪些数据属于每位客户，以及团队是否共享工作区。
• 哪些操作必须比浏览器标签页活得更久：排队任务、定时工作、长时运行的任务。
• 你要按什么收费——订阅、席位、用量——以及由谁付费。
• 团队实际上扛得住多大的运维面：数据库、队列、供应商。

评估框架之下的各层

框架的名字只描述了表面。底下的各层才决定产品能否立得住。逐层走一遍，对每一层问同一个问题：谁拥有这个决定，它在哪里被执行？

技术栈留白的任何一层，都是你签约认领的工作。“自带认证”是正当的设计——它只意味着你要自己负责会话语义、供应商集成，以及随之而来的每个失败场景。留白是选择；看不见的层是负债。套件的模块文档是理解“被拥有的层”长什么样的好参考。

检查工具之间的接缝

技术栈是一系列集成决策。弄清谁拥有会话、记录如何划定边界、支付事件在哪里变成访问权限，以及界面如何取得后台任务的结果。正是这些连接决定了请求失败或重复到达时，正常路径是否仍然正确。

supastack 在 Web 端使用 Next.js、移动端使用 Expo，底层是共享的 TypeScript 包。Better Auth 负责身份，Postgres 与 Drizzle 负责持久化，Trigger.dev 负责显式的工作流行为。这些是本仓库的选择，并非主张每个产品都应使用同样的工具——技术栈指南记录了每个选择及其理由；即使你选了别的工具，这些问题依然适用。

无论用什么工具，检验都一样：挑一条记录，跟着它从界面穿过服务端边界进入持久化再走回来。如果任何一跳只是约定而不是被强制的规则，未来的某位贡献者迟早会打破它。

把持续运行的成本算进去

技术栈决策也是运维决策。Postgres 需要备份和迁移纪律。任务运行器需要一个真有人打开的仪表盘。每个供应商密钥都需要轮换机制和客户端包之外的家。在功能清单把你征服之前，先把这些条目加进对比。

趁还有选择时检查升级路径。一个锁死依赖、有文档化更新流程的 monorepo——套件为此专门维护了一份更新指南——比由各持一套版本假设的教程拼出来的技术栈更经得起时间。

• 依赖与安全更新：多久来一次，由谁应用。
• 供应商凭证：存放在哪里，谁能轮换。
• 数据：备份计划、恢复演练和保留策略。
• 可观测性：什么会响着地坏掉，什么会悄悄坏到客户来报。

构建一条小的垂直切片

在承诺采用某套技术栈之前，先跑通一条切片：让用户登录、写一条归属记录、启动一项工作并取回结果。然后故意尝试错误的工作区、过期会话与失败的任务。评估这些普通场景需要多少自定义胶水代码。

留一份简短的决策记录：该栈支持什么、你选择推迟什么、什么情况会触发重新评估。原生购买、真实供应商验收与部署运维应是明确列出的项目，而不是藏在一次成功本地构建背后的假设。合适的技术栈会给团队留出足够的注意力做产品。

如果这条切片在某个 starter 的仓库里跑得顺利，接下来的问题就是是否采用它——用脚手架还是从零开始走查了那个决定。

• 登录，然后在刷新后恢复会话。
• 写一条限定在某个工作区的记录并读回来。
• 启动一个后台任务，稍后取回结果。
• 用错误的工作区和过期的会话重复同样的调用。

关于选择技术栈的常见问题

技术栈决策总能引来一堆自信的建议。这些才是值得为自己的产品回答的问题。

• 应该选自己已经熟悉的技术栈吗？ —— 通常是的，只要它能表达产品的约束。边界清晰的熟悉栈，胜过要花几个月去学的时髦栈——除非产品确实需要它没有的东西，比如原生移动端。
• 前端框架最重要吗？ —— 不如它周围的各层重要。框架塑造的是 UI；身份、范围、计费和后台任务才决定产品能否保持正确。
• 技术栈评估应该花多久？ —— 以天计而不是以周计：写下约束、检查接缝、跑一条垂直切片。如果普通的失败都要靠自定义胶水，就继续找。
• 什么时候换栈才算合理？ —— 当核心约束变化时——比如必需的平台、规模门槛——而不是新版本看起来更漂亮时。切换成本在认证和数据里，不在组件里。