ORM框架概述：告别裸SQL，拥抱对象思维
说到ORM，我猜你肯定不陌生。但你有没有想过，为什么我们要用它？
我刚入行那会儿，项目里全是裸SQL。查个用户信息，得写SELECT * FROM users WHERE id = 1。改个密码，又是一串UPDATE。最烦的是，数据库表结构一变，所有相关SQL都得跟着改。那叫一个痛苦。
后来接触了ORM，感觉整个世界都清净了。说白了，ORM就是一张“翻译官”——把数据库里的表，翻译成我们代码里的对象。你操作对象，ORM帮你操作数据库。
我个人觉得，理解ORM最核心的一句话就是：用面向对象的方式，操作关系型数据库。
ORM三大核心能力：
- 映射（Mapping）： 把表映射成类，把行映射成对象，把字段映射成属性。
- 持久化（Persistence）： 对象状态自动同步到数据库，增删改查都是方法调用。
- 查询（Query）： 用对象API代替SQL字符串，链式调用，可读性拉满。
为什么ORM能帮我们做加密字段改造？
你想想看，要是每个模型都自己写加解密，那得多少重复代码？而且容易漏掉某个查询，导致数据明文泄露。
ORM给了我们一个“中心化拦截”的机会。具体来说：
- 属性级拦截： 在Python属性赋值/取值时加解密（比如SQLAlchemy的
@hybrid_property或Django的@property）。 - 序列化层拦截： 在数据进入/离开数据库时自动处理（比如SQLAlchemy的
TypeDecorator）。 - 查询层拦截： 自动对加密字段的查询参数进行加密匹配。
我在项目中遇到过一种情况：业务方要求手机号在数据库里必须是密文，但查询时又要支持模糊搜索。这要是用裸SQL，基本上就得写存储过程了。但用ORM配合特定加密策略，通过自定义字段类型就能搞定。
常见ORM框架一览
Python生态里ORM框架不少。我用了一张表帮你梳理清楚：
| 框架 | 特点 | 适用场景 | 对加密字段的支持 |
|---|---|---|---|
| SQLAlchemy | 功能最全，灵活性极高 | 复杂查询、遗留数据库、高性能需求 | TypeDecorator原生支持，加密字段改造的最佳选择 |
| Django ORM | 与Django框架深度绑定，使用简单 | 标准Web应用、快速开发 | 需要通过自定义Field或Manager实现，不如SQLAlchemy灵活 |
| Peewee | 轻量、学习成本低 | 小型项目、脚本工具、原型开发 | 可以写自定义Field，但对复杂加密策略支持有限 |
| Tortoise ORM | 异步原生，支持Tortoise-ORM | 异步框架（如FastAPI） | 支持自定义字段，但生态较小 |
我个人建议： 如果团队是Django技术栈，就用Django ORM的扩展方案；如果是Flask/FastAPI这类灵活的框架，直接上SQLAlchemy。成本最低、坑最少。
ORM核心知识体系
下面这张图，概括了我们这一章要聊的核心逻辑。你可以把它当作整个课程的“地图”：
选型建议：哪个框架适合加密改造？
我记得之前有个同事，非要用Peewee做加密字段。写了三天，发现查询加密字段完全没法自动处理，最后还是换成了SQLAlchemy。
所以，如果你问我哪个框架最适合做加密字段改造，我会毫不犹豫地说——SQLAlchemy。原因有三：
- TypeDecorator足够底层： 你可以在数据从Python对象存入数据库之前，以及从数据库加载到Python对象之后，这两个时间点插入加解密逻辑。完全透明。
- 混合属性（Hybrid Attributes）： 可以在Python层面加密，ORM层面明文，方便业务代码使用。
- 事件系统（Events）： 监听
before_insert、after_load等事件，做精细化控制。
避坑指南： 我曾经在一个项目里直接用Django ORM的@property做加解密。结果查询加密字段时，发现Filter会对未加密的值做判断，导致查不出来。后来改成自定义Field才解决。所以，属性装饰器不等于ORM层加密，它只影响Python层面的取值行为，不影响数据库查询。
好了，ORM的基本概念、核心价值以及各框架的特性，到这里就聊完了。你知道为什么我们要先讲这些吗？
因为后续所有的加密字段改造方案，都建立在这些核心机制之上。你把映射、字段类型、会话查询这几个概念吃透了，后面的代码和配置才能真正理解。