✅ 一句话总结
ORM 的维护成本在前期较高，但在项目规模变大、表之间有复杂关系时，它的开发效率和代码一致性优势会明显超越手写 SQL。
🧱 对比表：ORM vs 原生 SQL（手写 SQL）
方面ORM（SQLAlchemy 等）原生 SQL学习成本高：需要理解模型定义、映射规则低：熟悉 SQL 就能上手初期开发速度慢：需写模型类和字段映射快：写 SQL 就能查维护大型项目✅ 易于维护：结构清晰、IDE可提示、自动迁移脚本❌ 难维护：SQL 散落在各处难统一维护重构支持✅ 变量/字段重命名 IDE 可统一修改❌ 改字段名要全项目查找替换复杂关系支持✅ 自带关联（如外键、反向引用）❌ JOIN 要手动写安全性✅ 自动防止 SQL 注入（参数绑定）❌ 容易忘记做参数清洗性能控制❌ 灵活性差些，复杂 SQL 可能不方便表达✅ 你想怎么写就怎么写调试/日志❌ SQL 隐藏在 ORM 里，需打印 SQL 看详情✅ 一眼看出你写了什么查询
🧠 举例对比
ORM 示例：
# 查询所有库存小于 10 的产品
products = Product.query.filter(Product.stock < 10).all()
# 更新
product.stock += 5
db.session.commit()
SQL 示例：
# 查询
cursor.execute("SELECT * FROM product WHERE stock < 10")
# 更新
cursor.execute("UPDATE product SET stock = stock + 5 WHERE id = %s", (product_id,))
conn.commit()
✨ 看起来 SQL 更直观，但在 10 张以上的表、关系交叉时，ORM 的模型设计能大幅提高一致性和开发速度。
✅ 什么时候用 ORM？
多人开发项目，需要代码一致性和结构清晰表结构可能频繁演化，ORM 支持迁移（如 Flask-Migrate）复杂关系多（如一对多、多对多），ORM 几行就能表达有 IDE 自动补全，能减少低级错误希望尽可能避免 SQL 注入、类型错误等问题
✅ 什么时候用 SQL？
你熟悉 SQL、数据结构不复杂快速写个内部工具或脚本查询逻辑特别复杂、对性能要求极高ORM 映射表达不了的 SQL（如子查询优化器 hint）
🔚 总结
场景推荐方式小项目 / 快速原型✅ SQL 更快更灵活中大型项目 / 多表关系 / 多人协作✅ ORM 更好维护
如果你觉得 ORM 太麻烦，其实可以两者结合：
用 ORM 管理表结构和基础查询用 db.session.execute() 写你需要的复杂 SQL