视图函数塞业务逻辑会导致代码重复、难以测试和维护。应将可复用逻辑抽至service层，其函数需独立于flask上下文、接受明确参数、抛具体异常，并由视图层负责请求解析与响应包装。
Flask里业务逻辑塞在视图函数里会出什么问题
直接在 app.route 装饰的函数里写数据库操作、第三方API调用、状态校验，短期能跑，长期必乱。典型症状是：改一个字段要翻三四个路由函数，加个新校验得在每个地方补一遍，单元测试根本没法写——因为逻辑和HTTP协议细节（比如 request.args、jsonify）死绑在一起。
根本原因不是Flask限制你写多长的函数，而是它不提供分层约定。你不主动切，它就默认“所有事都在视图里干完”。
- 调试时分不清是参数解析错了，还是业务规则错了
- 同一个校验逻辑（比如“用户余额必须大于订单金额”）在多个接口重复出现
-
return jsonify(...)和db.session.commit()混在一起，事务边界模糊
Service层怎么组织才不算“为分而分”
Service不是建个 services/ 目录再扔几个类进去就叫分层。关键看两点：是否可独立测试、是否与Web框架解耦。真正的Service函数只依赖明确传入的参数（比如 user_id、order_data），不碰 request、session、g 这些Flask上下文对象。
示例：一个下单动作，视图层只做三件事——解析请求、调用Service、包装响应：
from services.order import create_order
<p>@app.route('/orders', methods=['POST'])
def place_order():
data = request.get_json()</p><h1>只负责把HTTP输入转成干净数据</h1><pre class="brush:python;toolbar:false;">result = create_order(
user_id=data['user_id'],
items=data['items'],
payment_method=data['payment_method']
)
return jsonify(result)
- Service函数名要动词开头（
create_order、cancel_subscription），别用名词（OrderService类本身不重要，它的方法才重要） - 参数全是普通Python类型（
int、dict、datetime），绝不能传request或current_user - 错误统一抛具体异常（
InsufficientBalanceError），别返回None或{'error': 'xxx'}
什么时候该把逻辑放进Service，什么时候不用
不是所有代码都值得抽。判断标准很简单：这段逻辑会不会被另一个HTTP端点、命令行脚本、定时任务复用？如果答案是“不会”，那可能真没必要硬拆。
- 纯数据转换（比如把
datetime格式化成字符串）留在视图里更直白 - 需要访问
current_app.config的配置读取，可以放Service，但别让它承担配置解析逻辑（比如从JSON字符串里parse出嵌套结构） - 涉及跨表关联查询且只在一个接口用，先写在视图里；等第二个接口也要查同样组合，再提到Service
- 事务控制必须由Service决定——视图层只管调用，不碰
db.session.commit()
容易被忽略的坑：Service里的数据库会话管理
很多人以为把DB操作移进Service就万事大吉，结果遇到 DetachedInstanceError 或数据没提交。根本原因是Flask-SQLAlchemy的会话生命周期和请求周期绑定，Service函数执行完，会话可能已被清理。
正确做法只有两种：
- 让Service函数接收一个显式的
db_session参数（适合需要精细控制事务边界的场景） - 用Flask的
@app.teardown_appcontext确保每次请求结束自动commit/rollback，Service里只管用db.session（更常见） - 绝对不要在Service里手动
db.session.remove()或新建会话——这会让Flask的上下文管理失效
复杂点在于：异步任务、后台线程、单元测试环境都没有Flask上下文，这时候Service必须能接受外部传入的会话对象，否则一跑就崩。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
