Service层是隔离业务逻辑与HTTP协议的缓冲带，应将数据库操作、第三方调用等抽离至独立模块或类，函数只返回领域对象或抛自定义异常，依赖须通过参数或构造函数注入，确保可测试与复用。
Flask 本身不强制分层，但一旦业务变复杂，缺了 Service 层，路由函数（view）就会迅速变成“万能胶水”——既查数据库、又调第三方 API、还拼 JSON、顺手处理异常和事务，最后连单元测试都写不动。
Service 层不是“多此一举”，而是隔离变化的缓冲带
当一个用户注册流程要同时：写入 User 表、发邮件、记录审计日志、触发消息队列——这些操作不属于 HTTP 协议范畴，也不该由 @app.route 直接耦合。把它们抽到 user_service.py 里，就能做到：
-
view只负责解析请求、校验格式、返回响应状态，不碰 DB 或外部服务 - 同一业务逻辑（比如“创建用户并通知”）可在 CLI 脚本、定时任务、API 接口里复用，不用复制粘贴 SQL 或
requests.post - 单元测试时，直接 import
create_user函数，mock 数据库或邮件客户端，不用启动整个 Flask 应用
Service 函数该怎么设计？别返回 dict，也别直接抛 HTTP 异常
常见错误是让 service.create_order() 返回 {"status": "success", "data": {...}}，或者在 service 里写 abort(400)。这会让 service 失去可移植性。正确做法：
- 函数只做业务动作，成功就返回领域对象（如
User实例），失败就抛自定义异常（如UserExistsError） - HTTP 状态码、JSON 包装、错误消息格式化，全部留在
view层统一处理 - 事务边界必须显式控制：如果用 SQLAlchemy，
session.commit()不该出现在 service 内部，而应由 view 或专用事务装饰器管理
什么时候该拆出独立 Service 类，而不是一堆函数？
小项目用模块级函数（user_service.py 里全是 def create_user(...)）完全够用。但以下情况建议上类：
立即学习“Python免费学习笔记（深入）”；
- 需要共享状态，比如多个方法共用一个缓存 client 或配置上下文
- 有明确生命周期，比如
PaymentService需要初始化网关密钥、设置超时、重试策略 - 团队协作中需明确契约：类名 + 方法签名 + type hint 就是接口文档，比一堆散装函数更易对齐
注意：Service 类不应继承 Flask 的 Blueprint 或持有 current_app，它得是纯 Python 对象，否则无法脱离 Flask 环境测试或复用。
容易被忽略的坑：Service 层的依赖注入太随意
很多人直接在 service 函数里 import db 或 from app.extensions import mail，导致难以替换 mock。真正可控的方式只有两种：
- 参数注入：把
db_session、email_client作为参数传入，测试时直接塞个 Mock 对象 - 构造函数注入：Service 类初始化时接收依赖，避免全局变量或单例硬引用
依赖写死在函数体内部，看着省事，后续加单元测试、换数据库、切环境时，你会花三倍时间返工。
