Weft：声明式后端如何革新Web开发，提升全栈效率

1. 项目概述：Weft，一个被低估的现代Web开发工具

如果你和我一样，长期在Web开发的一线摸爬滚打，那你一定经历过这样的场景：项目初期，为了一个简单的数据展示页面，你需要手动搭建一个后端服务，定义路由，连接数据库，编写CRUD接口，然后再回到前端去处理数据请求、状态管理和错误处理。整个过程繁琐、重复，且极易出错。尤其是在快速原型验证或开发内部工具时，这种“重型”的开发流程常常让人感到力不从心。今天要聊的这个项目——Weft，正是为了解决这类痛点而生的。

Weft 是一个开源项目，它的核心定位是“为现代Web应用提供声明式的后端服务”。简单来说，它允许前端开发者，甚至是不那么熟悉后端细节的开发者，通过一种更直观、更贴近前端思维的方式，来定义和消费数据服务。你不再需要写冗长的控制器和服务层代码，而是通过声明式的配置或代码，告诉Weft你需要什么样的数据，剩下的工作——包括API的生成、数据库的查询优化、权限校验等——都由Weft来帮你完成。这听起来是不是有点像GraphQL或者一些BaaS（后端即服务）平台？没错，Weft的灵感确实来源于此，但它更轻量、更专注于与现有技术栈的无缝集成，并且将控制权更多地交还给开发者。

这个项目适合谁呢？首先，是独立开发者或小团队，你们需要在资源有限的情况下快速构建功能完整的产品。其次，是全栈开发者，希望减少上下文切换，用更统一的思维模型来开发前后端。最后，它也适合那些希望为现有前端应用快速增加一个轻量级、可定制后端服务的团队。接下来，我将带你深入拆解Weft的设计哲学、核心实现以及如何将它应用到你的实际项目中。

2. 核心架构与设计哲学解析

2.1 声明式数据层的价值与实现思路

Weft 的核心创新在于它提出并实现了一个“声明式数据层”。在传统的RESTful或GraphQL开发中，我们通常是“命令式”的：先定义数据库模型，然后编写解析器或控制器函数，在函数内部手动编写查询逻辑、处理关联关系、进行数据转换。这种方式灵活，但模板代码多，且业务逻辑容易分散。

Weft 反其道而行之。它允许你像写React组件或Vue组件那样去“描述”你的数据需求。例如，你不再写“查询用户表，联查订单表，然后过滤状态”，而是声明“我需要一个用户对象，包含其最近10个已完成的订单”。Weft的运行时引擎会解析你的声明，自动生成最优化的查询语句（例如SQL），并返回结构化的数据。

这种设计带来的好处是多方面的。开发效率是首要提升点。对于常见的增删改查操作，你几乎可以做到零代码实现。一致性也得到了保证，因为数据获取的逻辑由框架统一处理，减少了因开发者水平不同导致的性能差异或逻辑错误。更重要的是，它极大地降低了前后端协作的认知负担。前端开发者可以更专注于UI和交互逻辑，而后端开发者则可以更专注于底层数据模型的设计和复杂的业务规则封装。

那么，Weft是如何实现这一点的呢？其架构通常包含以下几个核心模块：

1. 模式（Schema）定义层：这是声明式的起点。开发者需要定义数据模型（类似于GraphQL的Type或Prisma的Model），包括字段、类型、关联关系。Weft的模式语言力求简洁，通常会支持从现有数据库（如PostgreSQL、MySQL）进行反向工程生成。
2. 查询编译器（Query Compiler）：这是Weft的大脑。它接收前端发来的声明式查询（可能是一种自定义的查询语言，或直接是JavaScript对象），结合定义好的模式，将其编译成目标数据库的查询语言（如SQL）。这个过程涉及查询优化，比如避免N+1查询、自动拼接JOIN语句等。
3. 执行引擎（Execution Engine）：负责连接数据库，执行编译后的查询，并处理结果。它需要管理数据库连接池、事务、错误处理等底层细节。
4. API网关/适配器层：将Weft的核心能力暴露给前端。这可能是一个独立的HTTP服务器，提供标准的GraphQL或RESTful端点；也可能是一个库，可以直接在前端框架（如Next.js、Nuxt.js）的服务器端函数中调用。

2.2 与GraphQL和传统REST的对比分析

理解Weft，最好将其放在现有技术的坐标系中。我们将其与GraphQL和传统REST做一个简单对比。

从对比可以看出，Weft 试图在 GraphQL 的强大灵活性和传统REST的简单性之间找到一个平衡点。它不像GraphQL那样给予客户端无限的自由度（这有时会导致复杂的查询影响性能），而是通过一套精心设计的声明规则，在提供足够灵活性的同时，保证查询的可预测性和性能优化空间。

注意：Weft 并非要完全取代 GraphQL 或 REST。对于超大型、客户端需求极其不固定的应用，成熟的GraphQL方案可能仍是更优选择。Weft 的核心优势在于“够用且高效”，特别适合产品早期和中小型项目。

3. 核心功能拆解与实操指南

3.1 数据模型定义与关系映射

一切始于数据模型。Weft 通常使用一个独立的配置文件（如weft.schema或models.js）来定义你的业务实体。我们以一个简单的博客系统为例。

假设我们有User（用户）、Post（文章）和Comment（评论）三个模型。在 Weft 中，定义可能看起来像这样（具体语法因实现而异，此为示意）：

// 示例：Weft 风格的模式定义 model User { id Int @id @default(autoincrement()) email String @unique name String? posts Post[] // 一对多关联到 Post comments Comment[] // 一对多关联到 Comment } model Post { id Int @id @default(autoincrement()) title String content String? published Boolean @default(false) author User @relation(fields: [authorId], references: [id]) authorId Int // 外键字段 comments Comment[] // 一对多关联到 Comment } model Comment { id Int @id @default(autoincrement()) content String post Post @relation(fields: [postId], references: [id]) postId Int author User @relation(fields: [authorId], references: [id]) authorId Int }

这段定义清晰地描述了模型、字段类型、默认值、唯一性约束以及最重要的——关联关系。User.posts和Post.author定义了一对多关系。Weft 的核心能力之一，就是能自动理解这些关系，并在查询时高效地处理数据关联。

实操要点：

• 外键显式声明：像上面的authorId、postId，虽然 Weft 可能能推断，但显式声明能使意图更清晰，也是良好数据库设计的基础。
• 字段修饰符：@id、@unique、@default这些修饰符不仅用于生成数据库约束，也是 Weft 进行查询优化和输入验证的依据。
• 反向关系：定义User中的posts字段，使得我们可以从用户直接“导航”到其所有文章，这是声明式查询能简洁表达的基础。

定义好模型后，通常需要一个数据库迁移（Migration）步骤。Weft 一般会提供 CLI 工具，如weft db push或weft migrate dev，将你的模式变更同步到开发数据库。这个过程会自动生成并执行 SQL 迁移文件，创建或修改表结构。

3.2 声明式查询实战：从简单到复杂

模型就绪后，我们就可以开始“声明”我们需要的数据了。这是 Weft 最迷人的部分。假设我们正在构建博客前端，需要展示一个文章列表页，每篇文章需要显示标题、作者名字以及评论数量。

在传统的 REST 中，你可能需要：1）请求/api/posts获取文章列表；2）循环列表，为每篇文章请求/api/users/:authorId获取作者名；3）再为每篇文章请求/api/posts/:postId/comments/count获取评论数。这就是著名的 N+1 查询问题，效率极低。

在 GraphQL 中，你可以在一个请求中完成，但需要编写对应的查询字符串，并在后端实现复杂的 resolver 来关联用户和计数。

而在 Weft 的声明式世界里，查询可能像这样（假设使用一个假设的weftClient）：

// 前端代码示例 const { data: posts, error } = await weftClient.models.Post.findMany({ where: { published: true }, include: { author: { select: { name: true } }, // 关联作者，只取名字 _count: { select: { comments: true } } // 聚合计数：评论数 }, orderBy: { createdAt: 'desc' }, take: 10, // 分页：取10条 });

这个查询对象清晰地声明了我们的意图：“查找所有已发布的文章，按创建时间倒序，取前10条。对于每篇文章，包含作者的名字，以及评论的计数。” Weft 的查询编译器会将其转换为一个或少数几个高度优化的 SQL 查询（例如，一个使用了 JOIN 和子查询的 SQL 语句），一次性从数据库获取所有数据。

让我们拆解这个查询的各个部分：

• where: 声明过滤条件。支持equals、contains、gt（大于）、lt（小于）、AND/OR等丰富操作符。
• include: 这是处理关联关系的核心。你可以指定要包含的关联模型，并可以嵌套select来精确控制返回的字段，避免数据冗余。_count是一个特殊的聚合字段，用于获取关联数量。
• orderBy和take/skip: 用于排序和分页，这是列表查询的标配。

对于更复杂的场景，比如查询某个用户发表的、含有特定关键词、且至少有5条评论的热门文章，查询依然可以保持声明式的优雅：

const popularPosts = await weftClient.models.Post.findMany({ where: { author: { name: { contains: '张三' } }, // 嵌套过滤：作者名包含“张三” content: { contains: 'Weft' }, comments: { some: {} }, // 至少有一条评论 // 更复杂的条件可能需要通过“条件计数”实现，这取决于Weft的具体实现深度 }, include: { author: true, comments: { take: 5, orderBy: { createdAt: 'desc' } } // 包含最新的5条评论 } });

实操心得：

• 性能意识：虽然include很方便，但要警惕“过度包含”。一次性拉取多层嵌套的庞大关联数据，即使SQL优化了，传输和解析的成本也可能很高。始终遵循“按需索取”原则。
• 探索查询编译结果：高级用法是查看 Weft 最终生成的 SQL 语句。这能帮助你理解框架的行为，并在发现性能瓶颈时进行优化。通常可以通过设置调试模式或使用日志中间件来实现。
• 组合使用：where条件可以非常灵活地组合。理解AND、OR、NOT以及嵌套对象过滤的语义，是构建复杂查询的关键。

3.3 数据变更（CUD）与业务钩子

查询（Read）只是 CRUD 的一半。创建（Create）、更新（Update）、删除（Delete）同样重要。Weft 为这些操作也提供了简洁的声明式 API。

创建数据：

const newUser = await weftClient.models.User.create({ data: { email: 'alice@example.com', name: 'Alice', posts: { // 甚至可以在创建用户时，同时创建关联的文章（嵌套写入） create: [ { title: 'My First Post', content: 'Hello Weft!' } ] } }, });

更新数据：

const updatedPost = await weftClient.models.Post.update({ where: { id: 1 }, // 指定要更新的记录 data: { title: 'Updated Title', published: true, }, });

删除数据：

await weftClient.models.Post.delete({ where: { id: 1 }, });

这些操作直观且强大，特别是嵌套写入（在创建父对象时同时创建子对象）能极大简化关联数据的初始化流程。

然而，真实的业务不可能只有简单的数据存取。我们还需要验证、授权、发送通知、更新审计日志等。这就是业务钩子（Hooks）或生命周期事件（Lifecycle Events）发挥作用的地方。Weft 通常允许你在数据操作的特定阶段注入自定义逻辑。

例如，我们希望在创建新用户后，自动发送一封欢迎邮件：

// 示例：Weft 的钩子函数（伪代码，具体API因实现而异） weftClient.models.User.$use('afterCreate', async (params) => { const user = params.result; // 创建成功的用户对象 await sendWelcomeEmail(user.email, user.name); });

常见的钩子点包括beforeCreate、afterCreate、beforeUpdate、afterUpdate、beforeDelete、afterDelete，以及针对查询的beforeFind等。在这些钩子中，你可以：

• 验证数据：执行比模式定义更复杂的业务规则校验。
• 修改数据：在存储前对数据进行清洗或转换（如密码哈希）。
• 执行副作用：发送邮件、清理缓存、调用外部API。
• 实现软删除：在beforeDelete钩子中将记录标记为删除，而非真正物理删除。

重要提示：钩子中的逻辑应保持轻量和快速。避免执行长时间运行的同步操作，否则会阻塞数据库请求。对于发送邮件、调用慢速API等任务，务必将其推送到异步任务队列（如 Bull、RabbitMQ）中处理。

4. 集成与部署：让Weft在你的栈中运转起来

4.1 与主流前端框架的深度集成

Weft 的价值在前端被消费时才能完全体现。因此，它与现代前端框架的集成体验至关重要。目前，它主要瞄准的是 React/Next.js 和 Vue/Nuxt.js 生态。

与 Next.js (App Router) 集成： Next.js 的 App Router 推崇在 Server Component 中直接进行数据获取。Weft 可以完美适配这一模式。首先，你需要创建一个服务端的 Weft 客户端实例，确保数据库连接在服务端建立。

// lib/weft-server.js import { WeftClient } from '@weft/client'; // 假设的客户端包 // 创建一个仅在服务端可用的客户端 // 注意：这里需要处理数据库连接的单例，避免在Serverless环境下创建过多连接 export const weftServerClient = new WeftClient({ datasourceUrl: process.env.DATABASE_URL, // 其他配置，如日志级别 });

然后，在 Server Component 或 Server Action 中直接使用：

// app/page.js import { weftServerClient } from '@/lib/weft-server'; export default async function HomePage() { // 在服务端直接查询，数据在构建时或请求时获取 const recentPosts = await weftServerClient.models.Post.findMany({ where: { published: true }, include: { author: { select: { name: true } } }, orderBy: { createdAt: 'desc' }, take: 5, }); return ( <div> <h1>Recent Posts</h1> <ul> {recentPosts.map((post) => ( <li key={post.id}> {post.title} by {post.author.name} </li> ))} </ul> </div> ); }

这种方式实现了真正的“全栈”开发，数据获取逻辑与UI组件共存，且由于在服务端执行，不存在浏览器环境下的CORS问题，也天然地保护了数据库凭证。

与 React Client Component 集成： 对于需要交互性、在客户端获取数据的组件，你需要一个能在浏览器中安全使用的客户端。这通常意味着 Weft 需要提供一个基于 HTTP 的 API 层。你可以用 Weft 快速生成一套 RESTful 或 GraphQL API，然后在前端使用fetch、axios或TanStack Query、SWR这样的数据获取库来消费。

更优雅的方式是，Weft 官方或社区提供类似@weft/client的包，它内部封装了 HTTP 调用，但在 API 设计上保持与服务器端客户端的一致性。这样，开发者可以用几乎相同的代码在服务端和客户端进行数据操作。

实操心得：

• 环境变量管理：数据库连接字符串 (DATABASE_URL) 是最高机密，必须通过环境变量管理，绝对不要硬编码或提交到代码仓库。在本地使用.env.local，在部署平台（如 Vercel, Railway）上配置环境变量。
• 客户端单例：在 Serverless 环境（如 Vercel Serverless Functions）中，每次请求都可能创建一个新的运行时。要小心管理数据库连接，使用连接池并考虑使用global变量或外部连接管理库来缓存客户端实例，避免耗尽数据库连接数。
• 类型安全：如果 Weft 是用 TypeScript 编写的，它通常能根据你的模式定义，自动生成完整的 TypeScript 类型定义。确保在开发时启用这项功能，它能提供无与伦比的代码提示和类型安全检查，极大提升开发体验和代码可靠性。

4.2 生产环境部署与性能调优

将基于 Weft 的应用部署到生产环境，需要考虑几个关键方面：安全性、性能和可观测性。

1. 安全性加固：

• API 端点保护：如果你暴露了 Weft 自动生成的 API 端点，必须实施身份验证和授权。这可以通过在 Weft 服务器前放置一个反向代理（如 Nginx）并配置 JWT 验证中间件，或者在 Weft 的钩子函数中添加权限检查逻辑来实现。例如，在beforeFind或beforeUpdate钩子中，根据当前登录用户的角色，动态向查询添加where条件（如where: { userId: currentUser.id }），实现行级数据隔离。
• 查询深度与复杂度限制：声明式查询虽然方便，但恶意用户可能构造极其复杂或深度嵌套的查询来拖慢甚至击垮数据库（类似于 GraphQL 的 DDoS 风险）。生产环境中，必须对查询的深度、复杂度、返回字段数量等进行限制。Weft 应提供相关配置选项。
• 输入验证与消毒：虽然 Weft 的模式定义提供了基础的类型验证，但对于字符串字段，仍需警惕 SQL 注入（尽管查询编译通常使用参数化查询来防范）和 XSS 攻击。确保在将用户输入用于数据库查询或返回给前端前，进行适当的消毒。

2. 数据库与连接优化：

• 连接池配置：根据你的应用负载和部署环境（Serverful vs Serverless），合理配置 Weft 客户端的数据库连接池参数（如最大连接数、最小连接数、连接超时）。在 Serverless 环境下，可能需要使用支持“连接器”模式的数据库驱动或托管连接池服务（如 Supabase、Neon）。
• 索引策略：Weft 自动生成的查询性能，最终取决于数据库表上的索引。你需要分析生产环境中的慢查询日志，为频繁用于where、orderBy和关联查询 (join) 的字段创建索引。许多 Weft 实现会在你定义@unique或@id时自动创建索引，但业务查询所需的复合索引需要你手动在数据库迁移中添加。
• 读写分离与分库分表：对于超高流量应用，单一的数据库可能成为瓶颈。Weft 本身可能不直接处理读写分离或分片，但你可以通过配置多个数据源（datasourceUrl），并在业务逻辑或中间件层根据操作类型（读/写）路由到不同的数据库连接，来实现基础的读写分离。更复杂的拆分需要更上层的架构设计。

3. 监控与日志：

• 查询日志：在开发环境开启详细的查询日志有助于调试，但在生产环境要谨慎，避免日志泄露敏感数据或变得过于庞大。通常建议在生产环境只记录慢查询（例如执行时间超过100ms的查询）和错误信息。
• 应用性能监控 (APM)：集成像 Sentry, Datadog, New Relic 这样的 APM 工具。监控 Weft 生成的数据库查询耗时、错误率，以及应用整体的响应时间。这能帮助你快速定位性能瓶颈。
• 健康检查端点：为你的 Weft 服务添加一个/health端点，用于检查数据库连接是否正常。这在容器化部署和负载均衡器健康检查中非常有用。

部署示例（以 Docker 为例）：假设你的应用包含一个 Next.js 前端和一个独立的 Weft API 服务器。

# Dockerfile for Weft API Server FROM node:18-alpine WORKDIR /app COPY package*.json ./ RUN npm ci --only=production COPY . . # 假设你的 Weft 服务器入口是 server.js CMD ["node", "server.js"]

然后使用docker-compose.yml来编排应用和数据库：

version: '3.8' services: postgres: image: postgres:15 environment: POSTGRES_DB: mydb POSTGRES_USER: user POSTGRES_PASSWORD: password volumes: - postgres_data:/var/lib/postgresql/data healthcheck: test: ["CMD-SHELL", "pg_isready -U user"] interval: 10s timeout: 5s retries: 5 weft-api: build: ./weft-server environment: DATABASE_URL: postgresql://user:password@postgres:5432/mydb NODE_ENV: production ports: - "3001:3000" depends_on: postgres: condition: service_healthy nextjs-app: build: ./nextjs-frontend environment: NEXT_PUBLIC_API_URL: http://weft-api:3000 ports: - "3000:3000" depends_on: - weft-api volumes: postgres_data:

这个配置定义了一个 PostgreSQL 数据库、一个 Weft API 服务和一个 Next.js 前端应用。它们通过 Docker 网络互联，前端通过环境变量NEXT_PUBLIC_API_URL访问 Weft API。

5. 常见问题、排查技巧与进阶思考

5.1 开发与生产中的典型问题速查

在实际使用 Weft 的过程中，你可能会遇到一些典型问题。下面是一个快速排查指南：

5.2 权限模型设计与实现进阶

对于任何严肃的应用，权限控制都是绕不开的话题。Weft 的声明式模型为权限设计带来了新的挑战和机遇。一个常见的需求是“行级权限”（Row-Level Security），即用户只能看到或修改属于自己的数据。

方案一：查询前置过滤（推荐）这是最符合 Weft 哲学的方式。在创建 Weft 客户端实例时，或在一个全局的钩子中，注入当前用户的上下文（如用户ID），并自动为所有查询添加过滤条件。

// 创建一个带权限过滤的客户端工厂函数 function createAuthorizedWeftClient(userId) { const baseClient = new WeftClient({ /* config */ }); // 使用高级技巧：包装或扩展客户端的模型方法 // 这里是一个概念性示例，实际实现取决于Weft是否提供此类扩展点 const authorizedModels = {}; for (const modelName in baseClient.models) { authorizedModels[modelName] = { findMany: (args) => { // 自动在查询条件中注入 userId 过滤 // 假设每个资源都有一个 `ownerId` 字段 const enhancedArgs = { ...args, where: { ...args.where, ownerId: userId } }; return baseClient.models[modelName].findMany(enhancedArgs); }, // 类似地包装 findUnique, update, delete 等方法... }; } return { models: authorizedModels }; } // 在请求处理中使用 const userClient = createAuthorizedWeftClient(currentUser.id); const myPosts = await userClient.models.Post.findMany({}); // 自动只返回 ownerId = currentUser.id 的文章

方案二：使用钩子进行权限检查在beforeFind、beforeUpdate、beforeDelete等钩子中，进行权限判断。如果当前用户无权访问目标资源，则直接抛出错误。

weftClient.models.Post.$use('beforeFind', async (params) => { const { where, context } = params; // 假设context中包含了当前用户 if (context.currentUser.role !== 'admin') { // 非管理员只能查看已发布或自己的文章 params.where = { AND: [ where, // 原有的查询条件 { OR: [ { published: true }, { authorId: context.currentUser.id } ] } ] }; } return params; });

方案三：视图（View）与数据库层权限对于极其严格的权限需求，可以考虑在数据库层面解决。创建数据库视图（View）或使用 PostgreSQL 的 Row Level Security (RLS) 策略。然后，让 Weft 的模式指向这些视图或受 RLS 保护的表。这样，权限控制完全下推到数据库，无论从哪个渠道访问数据，规则都一致。不过，这增加了数据库的复杂度，并且可能让 Weft 的一些高级关联查询特性变得难以使用。

选择建议：对于大多数应用，方案一（查询前置过滤）是最清晰、最易于理解和维护的。它将权限逻辑集中在一处，并且与 Weft 的声明式查询风格结合得很好。方案二（钩子）更灵活，可以处理更复杂的、基于资源状态的权限逻辑。方案三（数据库层）适用于安全要求极高、且有多重应用访问同一数据库的场景。

5.3 扩展性与自定义操作

尽管 Weft 能处理大部分 CRUD，但复杂的业务逻辑（如支付处理、复杂计算、调用第三方 API）仍需自定义。这时，你需要跳出声明式的舒适区。

1. 自定义端点/解析器：大多数 Weft 框架允许你定义自定义的 HTTP 端点或 GraphQL Resolver。你可以将这些端点视为“逃生舱”，用于处理 Weft 标准 API 无法覆盖的场景。

// 示例：在 Weft 服务器上添加一个自定义的“发布文章”端点 import { weftServerClient } from './weft-config'; import { sendNewsletter } from './email-service'; app.post('/api/posts/:id/publish', async (req, res) => { const postId = parseInt(req.params.id); const { scheduleAt } = req.body; // 1. 使用 Weft 客户端进行数据更新 const post = await weftServerClient.models.Post.update({ where: { id: postId }, data: { published: true, publishedAt: scheduleAt || new Date(), }, include: { author: true } }); // 2. 执行复杂的业务逻辑 if (post.author.subscribeToNewsletter) { await sendNewsletter(post.author.email, `Your post "${post.title}" is now live!`); } // 3. 调用外部系统 await fetch('https://internal-audit.example.com/log', { method: 'POST', body: JSON.stringify({ event: 'post_published', postId }) }); res.json({ success: true, post }); });

2. 使用原始查询：当需要执行极其复杂、优化到极致的 SQL，或者使用数据库特有功能（如地理空间查询、全文检索、窗口函数）时，可以直接运行原始 SQL。Weft 客户端通常提供$queryRaw或类似的方法。

const result = await weftServerClient.$queryRaw` SELECT p.*, COUNT(c.id) as comment_count, AVG(r.rating) as avg_rating FROM "Post" p LEFT JOIN "Comment" c ON p.id = c."postId" LEFT JOIN "Rating" r ON p.id = r."postId" WHERE p."published" = true GROUP BY p.id HAVING COUNT(c.id) > 5 ORDER BY avg_rating DESC LIMIT 10 `; // 注意：使用原始查询需要自己处理结果集的类型安全。

3. 事务处理：对于需要原子性的一系列操作，必须使用事务。Weft 应提供事务 API。

const transactionResult = await weftServerClient.$transaction(async (tx) => { // 1. 扣减库存 const updatedProduct = await tx.models.Product.update({ where: { id: productId }, data: { stock: { decrement: quantity } }, }); if (updatedProduct.stock < 0) { throw new Error('Insufficient stock'); } // 2. 创建订单 const newOrder = await tx.models.Order.create({ data: { userId, total: price * quantity, items: { create: { productId, quantity, unitPrice: price } } }, }); // 3. 记录日志 await tx.models.AuditLog.create({ data: { action: 'ORDER_CREATED', orderId: newOrder.id, userId } }); return newOrder; // 如果一切顺利，事务提交，返回订单 }); // 如果上述任何一步抛出错误，整个事务将回滚

最后的思考：Weft 这类声明式后端工具，代表了开发范式的一种演进。它通过提升抽象层级，将开发者从重复的样板代码中解放出来，更专注于业务逻辑本身。它的成功与否，取决于其生态的完善度（如管理后台生成、更丰富的插件）、性能优化能力以及对复杂场景的支撑能力。对于新项目，尤其是追求开发速度的全栈项目，它是一个非常值得尝试的选择。对于存量项目，则可以评估其作为特定模块（如管理后台、内部工具）数据层的可能性。技术选型永远是关于权衡，而 Weft 无疑在“开发效率”和“足够灵活”的天平上，增加了一个有分量的砝码。