Flask-SocketIO 是一个扩展 Flask 应用以支持 WebSocket 通信的库。它使得在 Flask 应用中实现实时双向通信变得简单，非常适合用于需要实时更新的应用场景。我在自己的项目中也应用到socket连接这个功能，这里简单总结一下。由于网上使用的方式都是前端使用html的方法来实现，现在很多都不直接使用html加js的实现方式了。所以我这里提供的是前端使用vue来实现socket。
Socket（套接字） 是计算机网络编程中的一个核心概念，它提供了一种在不同设备或同一设备上的进程之间进行网络通信的机制。简单来说，Socket 是网络通信的端点，允许应用程序通过网络协议（如 TCP、UDP）发送和接收数据。
当前flask版本为3.0.2，记得之前flask实现线程隔离的时候是使用localstock来实现的，现在再来看源码出现了ContextVar让我感觉比较陌生，接下来我们就来好好看看flask为什么要使用ContextVar。
源码对比
我们需要首先明白一个对象实例化会做那些事情
def cls_instance():
print('我是类属性')
return 1
def init_instance():
print('我是实例属性')
return 2
class Demo:
instance = cls_instance()
def __init__(self):
self.ini = init_instance()
def __call__(self, *args, **kwargs):
print('我是call方法')
app = Demo()
# 我是类属性
# 我是实例属性
contextvars？Python 3.7 引入的 contextvars 模块提供了更灵活的上下文变量管理能力，支持 异步编程 和 更细粒度的上下文绑定。Flask 3.0 的迁移主要基于以下优势：
contextvars 天生支持异步/协程环境（如 asyncio），而 Werkzeug 的 Local 主要针对多线程。contextvars 性能更高，且无需依赖第三方库（如 Werkzeug）。Token 机制可更方便地管理上下文的嵌套和恢复。采用比较官方的话来介绍就是
网络原理中，路由指的是根据上一接口的数据包中的IP地址，查询路由表转发到另一个接口，它决定的是一个端到端的网络路径。
web里的话，路由概念也是类似的，根据URL来将请求分配到指定的一个‘端’，另外也可以这样用，在某一个节点设置个转发，将到达这里的每一个’包‘或者说URL重新定向到另一个端并且可以在这个过程中对这个包进行处理。
endpoint是flask中提出来的一个概念，我们先下结论就是视图函数和url的中间值，我们可以利用endpoint找到url,也可以使用endpoint找到视图函数。它是为了方便我们通过endpoint找到url,寻找视图函数的值。
请求的生命周期这个是比较复杂的我们通过两个方面来进行分析，分别用应用上下文和请求上下文，以及before_request，after_request等处理函数进行分析
源码部分
def wsgi_app(
self, environ: WSGIEnvironment, start_response: StartResponse
) -> cabc.Iterable[bytes]:
ctx = self.request_context(environ)
error: BaseException | None = None
try:
try:
ctx.push()
response = self.full_dispatch_request()
except Exception as e:
error = e
response = self.handle_exception(e)
except: # noqa: B001
error = sys.exc_info()[1]
raise
return response(environ, start_response)
finally:
if "werkzeug.debug.preserve_context" in environ:
environ["werkzeug.debug.preserve_context"](_cv_app.get())
environ["werkzeug.debug.preserve_context"](_cv_request.get())
if error is not None and self.should_ignore_error(error):
error = None
ctx.pop(error)
flask是一个极其自由的框架，其实这也是我喜欢这个框架的原因就是我们可以根据自己的需求来自定义框架，这个就像是有一种养成系的感觉，会觉得这个框架越来越好用。
那么既然我们需要更加灵活的使用这个框架，其中框架中一些提供出来的方法我们肯定需要了解，其实flask中的自定义扩展点我们可以分为两类，其中一类是flask的信号机制，还有一类就是一些请求处理函数，包括但是不局限于before_request、after_request等请求处理函数。接下来我们就进入源码来分析flask提供的自定义扩展点。
我曾经在之前的工作中，使用20行代码实现使用传统视图100多行实现的增删改查的功能。之前使用的是flask_restful，但是这个模块没有swagger文档，还挺说这个模块的负责人是物理层面的找不到了，后面我又接触到flask_restx这个模块，实现了文档自动生成这个很重要的功能。
传统的 Flask 函数视图（Function-Based Views）虽然简单，但在复杂场景下存在以下问题：
WSGI（Web Server Gateway Interface）
ASGI（Asynchronous Server Gateway Interface）
async/await），支持同时处理多个请求，无需等待前一个请求完成。你们平时数据库是真删除还是软删除？
一般来讲都会设置软删除，软删除的好处可以保证数据库索引的顺序，避免数据库索引的稀疏性。大量的真实删除会造成数据库的索引稀疏，导致数据库的查询数据变慢。