“后端”听起来像一个地方，但它其实是一条边界——你控制的东西和你控制不了的东西之间的分界线。所有从外部跨过这条线进来的东西，在解析之前都是敌意的；线内的东西则由你负责保持一致。前端渲染状态；后端是状态被允许改变的地方，关于它如何改变的每一条规则都住在这里。
2026 年，四个决策定义了这一层：API 的形态、守卫它的 schema、你押注的认证模型，以及代码运行的运行时。每一个在今年都有清晰的默认答案——也有清晰的偏离理由。
API 形态的问题
先从诚实的分类开始，因为“REST 还是 GraphQL”已经不是真正的问题了：
- 面向公众的第三方 API——REST 加 OpenAPI 文档仍然是正确的默认。陌生人没法 import 你的类型。
- UI 内部的变更操作——Server Actions（第 3 篇）已经删掉了这块的大部分。如果唯一的调用方是你自己的前端，RPC 风格的调用好过手搓的 REST 端点。
- 独立的 API 服务——这是 2026 年尘埃落定的地方：Hono。一个约 14 KB、零依赖、TypeScript 优先、完全构建在 Web Standards（
Request/Response）之上的框架，同一份代码可以不加 shim 地运行在 Cloudflare Workers、Deno、Bun、Node.js、Lambda 和 Vercel 上。它在十八个月内从每周 20 万下载涨到 1400 万+，Cloudflare 内部在使用它，AWS 在 re:Invent 2025 上推荐它用于 50ms 以内的 Lambda 冷启动。它的hc客户端不需要代码生成，就能在 API 和前端之间提供端到端类型安全。
退居二线的巨头们：Express 在原始下载量上仍然领先，但已是遗留选择——没有原生 TypeScript，跑不了 edge runtime。Fastify 在你明确需要一个常驻、高吞吐、插件生态成熟的 Node.js 服务器时仍是正确答案。tRPC 作为 monorepo 里的类型化 RPC 选项存活下来，与 Hono 的 RPC 模式大面积重叠。
校验：要解析，不要信任
第 2 篇已经说明，TypeScript 类型在编译时就会蒸发。边界上的替代品是 schema 校验：每一个请求体、查询字符串、环境变量和外部 API 响应，在使用之前都要先解析。响亮地失败，返回带细节的 400，绝不做静默的类型强转。
2026 年的格局：
- Zod 4 是默认答案，而且优势悬殊——每周约 1.6 亿下载，v4 重写的解析器补齐了它过去在速度和包体积上的大部分短板。tRPC、React Hook Form 和 OpenAI/Anthropic 的 SDK 都把它当一等公民对待。
- Valibot 用于包体积是真实成本的场景——浏览器 bundle 和 edge 函数。它的模块化 import 让每个校验器只下发几百字节，而不是几十 KB。
- ArkType 适合类型系统原教旨主义者——用 TypeScript 自己的表达式语法写 schema，三者中最快的解析基准，内置 JSON Schema 导出。
- TypeBox 用于消费方就是 JSON Schema 本身的场景——Fastify + AJV 的热路径，以及如今直接要求 JSON Schema 的 AI 工具定义。
值得注意的元变化：Standard Schema（四个库都实现的共享接口）意味着你的选择不再是终身监禁，而 AI 工具调用让 JSON Schema 兼容性成为每个校验库的一等要求。一个代码库选一个库——混用三个是你在每次 code review 上都要交的税。
认证：三种运营模式
认证是你选错了最后悔的第一个后端决策。2026 年，这个选择发生在运营模式之间，而不是登录表单之间：
- Better Auth——自托管的默认答案。 一个 TypeScript 优先的库，运行在你的应用里，把用户、会话和 OAuth 账号写进你自己的数据库（内置 Drizzle adapter）。v1.0 于 2024 年底发布；到 2026 年中，它已是新自托管应用的共识之选：passkey、2FA、组织、后台管理和速率限制都以插件形式提供，而且永远没有按用户收费。代价是：运维归你。
- Clerk——托管捷径。 十五分钟得到精致的 UI、组织、MFA 和用户面板。1 万 MAU 以内免费，超出后约 $0.02/MAU。对追求上市速度和 B2B 为主的产品是正确选择；但要清楚你是在租用自己的用户表，账单会随你的成功一起增长。
- Supabase Auth——如果你已经在用 Supabase。 它的超能力是 Row Level Security：在数据库策略里直接引用
auth.uid()，删掉一整层授权代码。但它本身不足以成为采用 Supabase 的理由。
Auth.js（NextAuth）仍有最大的装机量，但在 2026 年读起来已经是遗留方案——新项目不应该从它开始。
比任何厂商都长寿的规则：会话放在 HTTP-only、Secure、SameSite 的 cookie 里；密码用 Argon2id 做哈希（或 edge 安全的 bcrypt 变体——仅限 Node 的 bcrypt 在 Workers 上跑不了）；OAuth state 和 PKCE 交给库处理，绝不手写；middleware 只是路由提示，不是授权——真正重要的检查运行在触碰数据的 action 或 handler 内部。
代码在哪里运行：从 region 到 edge
部署位置是一个延迟和物理问题，它分成三档：
- region 里的 Node 服务器——常驻进程，没有冷启动，完整的平台能力（原始 TCP、文件系统、内存状态）。适合重的、有状态的或需要连接池的工作：主 API、后台 worker、WebSocket 枢纽。
- Serverless 函数——缩容到零、按调用计费，在基于 Node 的平台上冷启动约 50–200ms。适合尖峰的、低负载周期的工作。
- Edge isolate（Cloudflare Workers、Vercel Edge、Deno Deploy）——分布在 300+ 节点的 V8 isolate，冷启动约 1–3ms，离用户只有一个网络跳点。适合渲染、会话检查、重定向和 API 胶水。一个实测的迁移案例把东南亚用户的中位延迟从约 180ms（单一美东源站）降到约 22ms（最近的 PoP）。
限制是真实的：没有原始 TCP（数据库访问要走 HTTP driver 或 pooler——第 6 篇），用 Web Crypto 而不是 Node crypto，还有 CPU 和子请求配额。让部署位置日后容易改的那条纪律是：对着 Web Standards 写 handler，而不是对着 Node API 写——这正是 Hono 在构造上强制你做的事。经验法则：在边缘渲染和验证，在 region 计算和持久化。
不可省略的卫生项
一张能抓住真实事故的短清单，没有一条光鲜亮丽：
- 速率限制——放在认证端点和任何昂贵的操作上，在边缘或代理层执行，先于你的代码。
- CORS 用显式的允许清单，绝不在需要认证的路由上写
*。 - 安全响应头——
Strict-Transport-Security、Content-Security-Policy、X-Content-Type-Options——在代理处设置一次。 - 密钥放在平台的 secret store 里，绝不进仓库，启动时用同一个 schema 库做校验（缺失的环境变量应该让部署崩溃，而不是让请求崩溃）。
- 后台工作（邮件、embedding、清理任务）进队列或 cron，绝不内联在请求路径里。用户得到快速响应，worker 得到重试机会。
练习，然后进入第 6 篇
- 搭一个两条路由的 Hono API（一个 GET、一个 POST），在边界上用 Zod 校验。先在本地 Node 上跑，然后把同一个文件部署到 edge runtime，从你的位置对比延迟差异。
- 在一个练手项目里加 Better Auth，用 Drizzle adapter；检查它创建的表。然后去它的源码里读一遍 OAuth 流程——三十分钟，从此你写的每一个登录界面都不再神秘。
- 拿一个你写过的端点，列出它对输入形状、认证和速率限制的每一个假设。把每个假设从注释搬进代码。
第 6 篇推开最后一扇门：数据层——serverless 时代的 Postgres、作为查询层的 Drizzle、不会凌晨三点叫醒你的 migration，以及从三百个地点同时连数据库时连接池的物理学。