作者：姚杨 ｜ 专栏：阿杰的技术成长

周一的早会，运营主管当着全组的面甩过来一张截图：昨天深夜的批量导入脚本，「跑到一半挂了，数据一半进去了」。阿杰 低头，这是他上周亲手写的——脚本里三步写库，第一步成功了，第二步超时，第三步压根没执行。

没有事务，没有回滚，数据库留下半个残局。

散会后，老陈 路过，丢下一句：「你那不是代码问题，是『记账』和『结账』混在一起了。」阿杰 愣住：「什么意思？」老陈 说：「去把 php-vibe-coding-frame 的 unit_of_work 看一遍，你就懂了。」

阿杰的旧伤：save() 到底该什么时候调

阿杰 是那种「让 AI 写代码、自己盯结果」的 vibe coder。他太熟悉传统 ORM 的日常了——每改一个对象，心里都得默念三件事：

- 多张表一起改，要手动开事务，忘了开就等着半成功；

- 并发两个人改同一条数据，最后提交的会悄悄覆盖先提交的。

他给 AI 描述需求时，每次都要补一句「记得 save 啊」「记得开事务啊」。AI 倒是听话，可一换需求、一改逻辑，save 的位置就乱：要么重复提交，要么漏提，要么事务包错了范围。

「该什么时候写库」这件事，成了他和 AI 之间每天要吵一架的糊涂账。

老陈 听完直摇头：「你在教 AI 背一套『结账』的流程。可它真正该管的，只有『记账』。」

闭包里的每一行代码，都只是「记账」——改实体、建实体、删实体，全部记在内存里，

。闭包一结束，框架统一「结账」：扫描这期间所有实体变更 → 生成 INSERT / UPDATE / DELETE SQL → 开事务 → 一次性提交。

阿杰 眼睛亮了：「所以我不需要管 save，只需要管业务逻辑？」

一段闭包 = 一个工作单元 = 一次原子提交。

 要么全成，要么全败，没有中间态。」

if_post('/order', function () {
    $order = order::create(input('user_id'), input('amount'));   // 记账：订单
    $detail = order_detail::create($order->id, input('sku'));    // 记账：明细
    $stock = stock::find_by_sku(input('sku'));
    $stock->quantity -= input('num');                            // 记账：扣库存
    // 闭包结束 → 自动生成 3 条 SQL → 一个事务提交
});

「三张表，没有一行事务代码。你只管说『要发生什么』，提交是它的事。」

场景一：再也不会「改到一半」

阿杰 想起那个半夜翻车的导入脚本——现在用工作单元重写，就是三层嵌套：

unit_of_work(function () {
    // 解析文件、写订单、写流水、扣库存，全在这一层
});

闭包内任何一步抛异常，整个工作单元直接失败，

。那个「跑一半，数据一半进去了」的截图，从此只能活在回忆里。

「这就是工作单元最值钱的地方，」老陈 说，「它把『事务』从你要记的 checklist 里，变成了你跑不掉的默认行为。

你不用想着开事务，你只要保证别在闭包里干别的。

场景二：忘掉 save()，告别「改了没写进库」

以前阿杰 最怕排查一种 bug：界面上看着改成功了，数据库里没有。一查——忘了 

在工作单元里，这个问题不存在了。实体一变，框架就知道它变了：

$stock->quantity -= 5;   // 内存里减 5
// 闭包结束 → 框架发现 quantity 变了 → 自动生成 UPDATE → 提交

「它怎么知道改了？」阿杰 问。

「实体每次赋值，都会和初始快照比对。有差异就是『已变更』，闭包结束自动写。

你连『声明我改了』都不用说。

底层方法到底要不要 save？两头都是坑

阿杰 又想到一个更细的问题：他以前封装了很多「底层方法」——比如 

，内部去改用户余额、改流水。那 save 到底写在哪儿？

老陈 说：「两头都是坑，你自己数数。」

// 不 save：把实体抛给外层
function charge_user($uid, $amount)
{
    $user = user::find_by_id($uid);
    $user->balance -= $amount;
    return $user; // 外层记得 save 吗？
}

「外层一旦忘了 save，改了半天等于没改。而且一个功能要改三张表，外层就得收三个实体、挨个 save，写起来又臭又长。漏一个，就是线上事故。」

// 内部 save：同一行改几次，就落几次库
function refund_order($order)
{
    $order->status = 'refunding';              // 第一步：改状态
    $order->save();                            // SQL #1

    // 中间几步业务：查流水、算金额、走风控……

    $order->refund_amount = $amount;           // 第二步：改金额
    $order->save();                            // SQL #2

    $order->refund_time = date('Y-m-d H:i:s'); // 第三步：改时间
    $order->save();                            // SQL #3
}

「同一个订单，一个请求里改了三次——状态、金额、时间——传统 ORM 就得往同一行发三条 UPDATE。业务步骤越多，save 越多，SQL 越多。要是外面再套一层循环，SQL 数量直接乘上用户数。」

save 放底层，性能崩；不放底层，漏提交。

 传统 ORM 逼他在两坨坑里选一坨。

底层方法只记账，一个都不 save；闭包结束，框架把最终状态一次性写进去。

function refund_order($order)
{
    $order->status = 'refunding';              // 记账：改状态
    // 中间几步业务照写，但一次 save 都没有
    $order->refund_amount = $amount;           // 记账：改金额
    $order->refund_time = date('Y-m-d H:i:s'); // 记账：改时间
    return $order;
}

if_post('/refund', function () {
    $order = order::find_by_id(input('id'));
    refund_order($order);                      // 全程零 SQL
    // 闭包结束：同一行，一条 UPDATE，写完最终状态
});

「同一行，一个请求，不管中间改了多少次，最终只有一条 UPDATE。

既不用外层背 save 的锅，也不会被 SQL 数量打脸。

场景三：两个人同时改同一条数据？

阿杰 又问：「那并发呢？运营和我同时改库存，后提交的覆盖先提交的，这个它管不管？」

 字段：「工作单元的每次 UPDATE，都带乐观锁——

UPDATE ... SET version = version + 1 WHERE id = ? AND version = ?

。影响不到 1 行，说明在你改的这段时间里，别人已经先改了，直接抛异常：

你改的不是最新版，这一单不算，重来。

「这不就是 Git 的 'conflict，先 pull 再 push'？」

「一回事。理念都是：宁可让你重做，也不悄悄覆盖你的劳动。」

两个钩子：成功后干什么，失败后干什么

真正让阿杰 觉得「像个人」的，是工作单元还给事务配了前后台：

if_unit_of_work_executed(function () {
    cache_delete('order_count');   // 提交成功后：清缓存、推队列
});

if_unit_of_work_disturbed(function ($e) {
    notify_ops($e);                // 提交失败后：告警、记日志
});

「以前成功回调、失败回调，都要自己挂在业务代码里，散得到处都是。现在框架统一给你两个时刻：

 你把『提交后该做的事』写进去就行。」

阿杰 忍不住笑了：「这哪是框架，这是帮我管财务的。」

阿杰 用了两周，终于咂摸出味道——这套机制对 AI 的友好，是「设计」出来的，不是巧合：

。save、flush、事务、提交时机，这些是框架在教人类背的流程。工作单元把它们全吃掉了，AI 只需要描述业务。

。一个功能一个闭包，一个闭包一次提交。AI 修改逻辑时，改动永远在一个「原子单元」内部，不会把事务范围改错。

。乐观锁、异常回调，AI 看到报错就知道「我改的数据过期了」「提交失败了」，不需要猜。

老陈 最后总结：「传统 ORM 让 AI 背了一堆『什么时候写库』的规矩，规矩越多，幻觉越多。工作单元把规矩删了，只留一条——

把业务写进闭包，剩下交给框架。

 这就是为什么这套框架下，AI 写库几乎不出错。」

阿杰 看着自己那三个再也没出过事的接口，给老陈 发了条消息：「我现在写接口，脑子里只剩『记账』，没有『结账』了。」

老陈 回得干脆：「本来就不该你结。

你把业务说清楚，账，让框架自己算。

至于这套「记账 / 结账」的思路，怎么长成一整套让 AI 放心的工程环境——那是下一个故事了。

周一的早会，运营主管当着全组的面甩过来一张截图：昨天深夜的批量导入脚本，「跑到一半挂了，数据一半进去了」。阿杰 低头，这是他上周亲手写的——脚本里三步写库，第一步成功了，第二步超时，第三步压根没执行。没有事务，没有回滚，数据库留下半个残局。

我把所有 save() 都删了：一段闭包就是一个工作单元，数据库自己会算账

数据库

编程语言

后端

阿杰用工作单元模式重写数据库操作，通过闭包实现原子提交，彻底告别手动save和事务管理。系统自动跟踪实体变更，乐观锁防并发覆盖，成功失败回调清晰。AI只需描述业务逻辑，框架自动处理所有写库细节，大幅降低错误率。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

我把所有 save() 都删了：一段闭包就是一个工作单元，数据库自己会算账

我把所有 save() 都删了：一段闭包就是一个工作单元，数据库自己会算账

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐