什么是ORM中的事务处理
在开发电商网站或记账类应用时，经常会遇到“转账”这种操作。比如用户从账户A转100元到账户B，需要先扣A的钱，再给B加钱。如果中间出错，比如扣了钱但没到账，问题就大了。这时候就得靠事务来保证操作的完整性。
ORM（对象关系映射）让我们用代码操作数据库时不用写太多SQL。但在涉及多步数据修改时，光靠ORM的基本增删改查还不够，得引入事务机制，确保所有步骤要么全部成功，要么全部回滚。
常见ORM框架中的事务用法
以Python的Django ORM为例，处理事务最常用的是transaction.atomic装饰器或上下文管理器。它会把包裹的代码块放进一个事务里，一旦抛出异常，自动回滚。
from django.db import transaction
# 使用装饰器
@transaction.atomic
def transfer_money(from_user, to_user, amount):
from_user.balance -= amount
from_user.save()
to_user.balance += amount
to_user.save()上面这段代码中，如果to_user.save()失败，前面的from_user.save()也会被撤销。就像你去超市买东西，刷卡成功但小票没打出来，店员通常会认为交易没完成——系统也该这么处理。
再看SQLAlchemy，它是通过session.begin()来开启事务的：
from sqlalchemy.orm import sessionmaker
Session = sessionmaker(bind=engine)
session = Session()
try:
with session.begin():
user1.balance -= 100
user2.balance += 100
session.add(user1)
session.add(user2)
except Exception as e:
print(f"交易失败：{e}")这里的with session.begin()会自动提交，出错则回滚。和做饭有点像：切菜、炒菜、调味都顺利才端上桌；中间发现食材坏了，整锅扔掉也不心疼。
嵌套事务与保存点
有些复杂业务可能需要“部分回滚”。比如下单时先锁库存，再计算优惠，最后生成订单。如果优惠算错了，想退回这一步但不取消整个流程，就得用保存点（savepoint）。
Django支持在atomic块内创建保存点：
@transaction.atomic
def place_order():
# 主事务
lock_inventory()
sid = transaction.savepoint() # 创建保存点
try:
calculate_discount()
except DiscountError:
transaction.savepoint_rollback(sid) # 回滚到保存点
create_order() # 继续下单这种设计就像写文档时打个“临时备份”，改了几段不满意，可以退回到那个点，而不是从头再来。
事务边界要合理
不是所有操作都要包进事务。比如查看余额、搜索商品这类只读请求，加事务反而拖慢性能。事务时间太长，还可能导致数据库锁等待，影响其他用户。
有个朋友做后台批量导入用户数据，一开始把几千条INSERT全塞进一个事务，结果内存爆了，回滚又花十几分钟。后来改成每200条提交一次，既保证局部一致性，又不会压垮系统。
所以事务范围要拿捏好：太小，数据可能不一致；太大，系统容易卡住。就像打包行李，一件件装好再拉上拉链，比塞满一半就拉、中途不断打开调整要高效得多。