SQLAlchemy 2.0 更受青睐因其原生异步支持：AsyncSession 与 create_async_engine 基于 asyncpg 等驱动，强制类型约束、统一 select() 语法、DeclarativeBase + mapped_column 显式建模，并天然契合 FastAPI 异步依赖注入。
SQLAlchemy 2.0 在 Web 开发中更受青睐，核心原因不是“功能更多”，而是它对现代 Python 运行时（尤其是 asyncio）的适配更直接、更少妥协。如果你用 FastAPI 或 Starlette 写服务，又依赖数据库 I/O，那 SQLAlchemy 2.0 的异步路径就不是可选项，而是默认合理选择。
AsyncSession 和 create_async_engine 是真异步，不是包装层
SQLAlchemy 2.0 的异步支持不是靠线程池模拟，而是基于原生 asyncpg、aiomysql 等驱动构建的完整执行栈：
- create_async_engine() 返回的引擎只能配合 AsyncSession 使用，类型系统强制约束
- AsyncSession.execute()、AsyncSession.commit() 全部是 awaitable，不混用同步方法
- 错误提示明确：比如你误用 session.query()，会直接报 AttributeError: 'AsyncSession' object has no attribute 'query'，而不是静默降级
常见踩坑点：
- 用 psycopg2（同步驱动）配 create_async_engine() → 连接失败，报 Driver not found for async dialect
- 在 AsyncSession 中调用 .add() 后直接 .commit()，但没 await → 报 RuntimeWarning: coroutine 'AsyncSession.commit' was never awaited，且事务不生效
- 混用 session.execute(select(...)) 和旧式 session.query(User).filter(...) → 前者返回 Result，后者在 AsyncSession 中根本不存在
select() 语法统一，不再依赖 session.query()
SQLAlchemy 2.0 彻底废弃了 session.query(Model) 这套 API，所有查询都从 select(Model) 构建：
- 查询语句本身与会话解耦，便于单元测试（你可以先构造 select(User).where(User.id == 1)，再传给任意 session 执行）
- 类型推导更准：select(User) 的返回类型是 Select[tuple[User]]，IDE 和 mypy 能精准提示 result.scalars().first() 返回 User | None
- where()、order_by()、join() 全是链式方法，没有歧义入口点
注意参数差异：
- select(User).where(User.name == "alice") ✅ 正确（表达式比较）
- select(User).where(User.name = "alice") ❌ 语法错误（不能用赋值）
- select(User).filter(User.name == "alice") ❌ filter() 已移除，仅保留 where()
DeclarativeBase + mapped_column 让模型定义更可控
SQLAlchemy 2.0 强制使用 DeclarativeBase 子类作为模型基类，并用 Mapped 注解 + mapped_column() 显式声明字段：
- 字段是否可空、默认值、索引、注释全部在列定义里写死，不靠隐式约定
- mapped_column(String(50), nullable=False) 比老式 Column(String(50), nullable=False) 多一层类型绑定，mypy 能校验 user.username = 123 这种误赋值
- 关系字段必须显式标注 Mapped[List["Post"]]，避免运行时才发现 user.posts.append(...) 报错
容易忽略的细节：
- mapped_column() 的 default 和 server_default 行为不同：前者是 Python 层默认值（插入对象时生成），后者是数据库层默认值（INSERT SQL 里不带该字段）
- relationship() 必须配 back_populates，否则正向访问 user.posts 可能返回空列表，即使数据库有数据
异步上下文管理器天然契合 FastAPI 依赖注入
FastAPI 的 Depends 机制和 AsyncSession 的 async with 生命周期高度匹配：
- 你可以写一个依赖函数，每次请求自动提供新 AsyncSession，用完自动 close()
- 不需要手动 try/finally 或中间件管理连接，出错时会话自动回滚并释放
典型模式：
- 依赖函数返回 AsyncSession，用 yield 包裹 async with 块
- 路由函数参数直接声明 session: AsyncSession，FastAPI 自动注入
- 如果路由中抛异常，yield 后的清理逻辑仍会执行，保证连接不泄漏
真正复杂的地方不在语法，而在于异步资源生命周期必须和 HTTP 请求生命周期严格对齐。比如你在后台任务里复用同一个 AsyncSession 实例，或跨 await 点持有 session 引用，很容易触发 DetachedInstanceError 或连接超时。这些不是文档没写，而是得靠调试时看日志里有没有 “session is closed” 或 “Task was destroyed but it is pending” 才能定位。
