级联删除需外键约束、orm关系定义和事务控制协同，仅靠cascade参数不安全；它仅作用于session.delete()，对原生sql无效；数据库外键on delete cascade才是可靠兜底。
直接上结论：级联删除不能只靠 cascade 参数写对就完事，必须配合外键约束、ORM关系定义和事务控制三者协同，否则容易删掉不该删的数据，或触发数据库报错中断。
SQLAlchemy 的 cascade 参数到底管什么
cascade 控制的是 SQLAlchemy ORM 层的行为，不是数据库层的强制约束。它只在你用 session.delete() 删除 Python 对象时起作用，对原生 SQL 删除（比如 session.execute(delete(...))）完全无效。
-
"all, delete-orphan"是最常用组合：既删关联对象，也清理孤立子对象（如订单被删后，其子项明细自动删） -
"delete"只删直接关联对象，不处理更深层嵌套（比如用户→订单→订单项，只删到订单，订单项不会动） - 漏写
passive_deletes=True时，ORM 会先查一遍子记录再删——在大数据量下可能拖慢甚至超时
外键 ondelete 才是数据库级兜底
仅靠 ORM 级 cascade 风险很高。真正可靠的做法是：在数据库外键定义里加上 ON DELETE CASCADE，让数据库自己保证一致性。
- SQLAlchemy 模型中需显式声明：
ForeignKey("users.id", ondelete="CASCADE") - SQLite 默认不启用外键，建库后必须手动执行
PRAGMA foreign_keys = ON - MySQL/PostgreSQL 要求存储引擎支持（InnoDB / PG 默认支持），但迁移脚本里不加
ondelete就等于没开
批量删除时 cascade 不生效的常见坑
用 session.query(User).filter(User.id.in_(ids)).delete() 这种方式批量删，cascade 完全不起作用——因为 ORM 根本没加载对象，直接发 DELETE SQL。
- 正确做法是先查出对象列表，再逐个
session.delete()： users = db.query(User).filter(User.id.in_(user_ids)).all()for u in users: db.delete(u)- 或者改用数据库原生级联 +
session.execute()配合ON DELETE CASCADE外键
权限与事务边界必须手动控制
级联删除一旦触发，可能横跨多张表，失败时需要整体回滚。FastAPI 默认每个请求一个 session，但你得确保：
- 整个删除流程在一个事务内完成（别在中间
session.commit()） - 权限检查（如管理员校验）放在事务开始前，避免越权后部分删除成功、部分失败留下脏数据
- 对关键操作加日志，比如记录“用户ID=123 删除了 4 个订单、12 条评论”，便于事后审计
最容易被忽略的一点：级联配置是单向的。你在 User.orders 上设了 cascade="all, delete-orphan"，不代表反向从 Order.user 删除就能触发级联——必须从主端（拥有 relationship 的那一方）发起删除动作。
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
