在 get_db 函数中使用 yield 关键字，而不是直接返回 (return) 数据库会话对象，是为了实现更复杂的行为，即延迟执行和资源管理。以下是为什么要使用 yield 的几个关键原因：
1. 延迟执行（Lazy Evaluation）
使用 yield 可以创建一个生成器，它不会立即执行函数体中的代码，而是在调用者开始迭代时才逐步执行。对于数据库会话，这意味着会话的创建和关闭可以与请求处理紧密关联，确保每个请求都拥有独立的会话，并且在请求完成后会话被正确关闭。
2. 上下文管理
yield 结合 try...finally 提供了一种简洁的方式来实现上下文管理。当 FastAPI 或其他框架依赖注入系统使用 get_db 作为依赖项时，它们会在路径操作函数执行前后自动管理生成器的生命周期。finally 块确保无论是否发生异常，数据库会话都会被正确关闭。
3. 依赖注入的协同工作
在 FastAPI 等框架中，依赖注入机制能够很好地与这种模式协作。框架会负责调用生成器并处理它的输出。具体来说，FastAPI 在路径操作函数开始之前启动生成器，在路径操作函数完成之后继续执行生成器中剩余的代码（即 finally 块）。这样就保证了每个 HTTP 请求都有一个独立的数据库会话，并且在请求结束时自动关闭。
4. 避免重复代码
如果不用 yield 和生成器模式，可能会在每个需要数据库会话的地方重复编写打开和关闭数据库连接的逻辑。通过将这个逻辑封装到一个生成器函数中，可以简化代码，减少错误，并使代码更容易维护。
示例解释
考虑以下代码：
def get_db():db = SessionLocal()try:yield dbfinally:db.close()- 当 FastAPI 调用
get_db时，它不会立即创建数据库会话；而是返回一个生成器对象。 - 当路径操作函数（如
read_users）需要数据库会话时，FastAPI 会从生成器中获取下一个值（这会执行到yield db），并将数据库会话传递给路径操作函数。 - 在路径操作函数完成后，FastAPI 继续执行生成器中的代码，进入
finally块并调用db.close()来关闭数据库会话。
这种方式不仅简化了资源管理，还提高了代码的安全性和可读性。因此，yield 是实现这一功能的关键，它使得 get_db 成为一种强大且灵活的工具来管理数据库会话。