Flask核心原理是路由分发、请求上下文、响应构建三部分：路由由Werkzeug匹配树实现动态解析与类型转换；上下文通过LocalStack保障request/session/g线程安全；响应经make_response统一封装并支持自定义与流式返回。
Flask 的核心原理其实就三点：路由分发、请求上下文、响应构建。它不像 Django 那样“大而全”，而是靠精巧的设计把 Web 开发的主干逻辑拎得特别清楚。学懂这三块，你写出来的不只是“能跑的代码”，而是“知道为什么这么写”的应用。
路由机制：不是简单映射，而是视图函数的调度中心
Flask 的 @app.route() 看似只是绑定 URL 和函数，背后其实是 Werkzeug 的 Map 和 Rule 在做匹配。每次请求进来，Werkzeug 会根据所有注册的 Rule 构建一棵匹配树，再用 HTTP 方法 + 路径做快速查找。
- 动态路由如
/user/<int:uid>，Flask 会在匹配后自动类型转换，失败则直接 404 —— 这是 Werkzeug 的Converter在起作用 - 用
add_url_rule()手动注册，比装饰器更灵活，适合插件或运行时动态加载路由 - 同一个函数可以绑定多个路由（比如 GET /api/user 和 POST /api/user），但推荐用
methods=['GET', 'POST']显式声明
请求上下文：让 request、session、g 这些“全局变量”线程安全
Flask 没有真正意义上的全局变量。request 看起来像全局，实则是通过 Python 的 LocalStack + 线程/协程局部存储实现的。每个请求进来，Flask 自动 push 一个 RequestContext，里面封装了 request、session、g 等对象。
-
g是一次请求生命周期内的临时容器，适合存数据库连接、用户权限等中间态数据 -
session默认基于签名 Cookie，不依赖服务端存储；想换 Redis 或数据库后端，只需继承SessionInterface - 在异步视图（如使用 Quart）中，上下文机制会切换为
contextvars，底层适配已做好，开发者无需重写逻辑
响应构建：从 return 值到 WSGI response 的完整链路
你写 return "Hello"、return jsonify(...) 或 return render_template(...)，Flask 都会统一走 make_response() 流程。这个函数判断返回值类型，自动包装成 Response 对象，设置默认状态码、Content-Type 等。
立即学习“Python免费学习笔记（深入）”；
- 自定义响应？直接返回
Response实例，或用make_response()包装字符串/字典 - 需要流式响应（如日志实时推送）？返回生成器函数，Flask 会自动设为
Transfer-Encoding: chunked - 错误处理不靠 try-except 全局捕获，而是用
@app.errorhandler(404)注册专用响应函数，保持关注点分离
掌握这些，再配合一个真实小项目（比如带登录态的备忘录 API + 管理页），你就不再是在“调用 Flask”，而是在“驾驭它的设计哲学”。
