好奇 Wine 能跑吗？
https://github.com/Gcenx/homebrew-wine
上面写了仅限 Intel，但是没有补充说明为什么不行。
这个版本的 Wine 是带 wine32on64 的，意味着如果它能 Rosetta 2，相当一部分 Win 需求可以得到解决。

你还不如标 1w6，然后接刀到 1w5，整数以下不接刀

如果是直接复制流的话应该不会太慢啊，或者用 mkv 做容器？

作为 ASGI 用户，每次看到 WSGI 们纠结 Windows 就觉得有 Uvicorn 真好，Waitress 到现在连个 SSL 都不支持，Uvicorn 功能已经做到快和 Gunicorn 齐平了。

@catfan 我是说右划的时候看不到上一页的预览的问题。如果点击链接前顶栏是缩回去的，点击后又打开了，那么前后 webview 高度不一致会使得右划无预览。

希望可以滑条调整夜间模式的对比度。

另外一些菜单文字和图标的对比度在夜间模式下不统一。

以及，WebView 有右滑白屏的 Bug，是这样的：当上一页面离开时的 WebView 高度和当前的 WebView 高度不一致的时候，右滑会出现白屏，这里需要单独对这个 WebView 的 Bug 做调整。

还有一些界面交互上可以明显看得出想学 ios，但是却在许多小的地方是反直觉的，比如阅读模式下滑不能关闭，比如一个有 Grip 的设置栏不能上下滑等等。

另外基于私心，我比较希望地址栏编辑时可以左右拖拽滚动，并且拥有语法高亮。

滚轮不支持倾斜，需要配合侧键组合才能实现横向滚动。

async 的支持怎么样？

@abersheeran 但是也同样无法解决闭包不可靠的问题啊，你只能规定禁止 scope 深拷贝，并且规定禁止 scope["session"] = {}这样的操作。

@abersheeran 但是你的中间件需要调用内层的 Application，而 send 则是一层一层传递下去，直到最后一层 Application 才调用这个 callable 的，所以你不应该在中间件里直接执行这个 send，而是要把它传递到更深层的 ASGI Application 里：

```python
async def __call__(self, scope, receive, send):
session = {}
scope["session"] = session

await self.app(scope, receive, send)
```

这样一来，你就只能存一个 scope 的闭包：

```python
async def __call__(self, scope, receive, send):
session = {}
scope["session"] = session

async def send_wrapper(message):
# do something to store session
scope["session"]["saved"] = True # 这里的闭包是不可靠的
await send(message) # 但是这里是可靠的

await self.app(scope, receive, send_wrapper)
```

但是就像 ASGI 标准里描述的那样，Scope 是会被下一层 Application 复制的，这就使得内层如果真的复制了 Scope 的话，外层对 Scope 的闭包引用读取到的只会是脏数据。我仔细思考过了，觉得这里如果 ASGI 不做调整，ASGI 的实现也不保存 Application 栈的话（因为像 Django 的 Daphne 一样保存栈是很消耗资源的），这里应该是没有解决方案的。

可如果 ASGI 提供一个单例的上下文的话：


```python
async def __call__(self, scope, receive, send):
session = {}
scope["session"] = session # 把它存到一个请求期间的上下文变量，不一定是 Scope

async def send_wrapper(message, scope): # 这里接收一个请求期间的上下文变量，不一定是 Scope
# do something to store session
scope["session"]["saved"] = True # 这里就不是闭包而是普通地用参数了，所以是可靠的
await send(message) # 这里本来就是可靠的

await self.app(scope, receive, send_wrapper)
```

或者，如果修改 ASGI 的规定，使得 Scope 由一个 immutable 变为一个 mutable single instance 的话，任何一个地方都可以取到一个可靠的 Scope 的引用，也就不会存在复制的问题了。

@abersheeran 我试了一下，结果倒是挺遗憾的，Python 里的正则的性能与捕获组的数量是呈线性关系的，与捕获组之间的包含关系无关。所以，将树展开成正则组的操作应该是仅在树的同级节点的时候可以通过合并获得性能提升，超过同级的情况下就是 Python 的语言性能和正则引擎的执行效率之间的撕逼取舍了。

我个人不倾向于使用换语言的方式实现这个，因为你似乎还没完全榨干 Python 呢。

将上下文传入 receive 和 send 是有意义的，比如不然的话，你怎样使用纯 ASGI 中间件实现一个干净的 Session 呢？ Session 的读取发生在__call__期间，而存储和 cookie 的更新则发生在 send 期间，而这之间则需要一个上下文去保存 Session 中的信息吧。

以及好像跑题了，说回来的话，我注意到你的实现实际上是个巨大的正则树。那么这样的话，这个正则树是否可以合并为一个巨大的单一正则以实现更大的性能提升和更少的内存占用呢？

@abersheeran 不仅如此，Starlette 早期是直接拿 Scope 当 Context 用的，Auth 、Session 、App 实例一类的都塞进 Scope 里，后来又有了 app.state 和 Request.state 两种 state，但是受限于 ASGI 标准，没有任何办法可以在中间件里访问到这个 Request.state…

所以如果真的玩 ASGI 标准的话，倒不如把这件事扔上台面，把 scope 变成一个 mutable dict 的单例，然后决定一下上下文是存到哪，是新开一个 dict 叫 state 或者 context，还是直接就存到 scope 里。

然后还得决定一下怎样让这个上下文在整个请求周期内都是可用的，怎样把它传到 receive 和 send 里。

@abersheeran 老实说比较底层的部分每个框架的实现都有问题，比如没有一个框架和 Server 实现了 Websocket 的 Set-Cookie，明明 2.1 标准里就有了…这就扯远了。

但是 Socket 的问题我感觉不是特别大，因为目前其实也不推荐裸跑 ASGI 或者用 ASGI 传静态文件，大家都是外面套一个 Nginx 用的。

ASGI 还有一个问题就是它只是个纸面标准，没有针对每一项纸面规定的测试…也是比较遗憾了。

@abersheeran ASGI 标准要求 Scope 是不可变的，每次修改都要复制 Scope 以避免污染上层 Middleware：
https://asgi.readthedocs.io/en/latest/specs/main.html#middleware

但是这样一来，Session 实际上是无法以纯 ASGI Middleware 可靠实现的，因为它需要一个上下文，在请求传至 Router 之前初始化上下文中的 Session （从 Cookie / 数据库中读取 Session 放入上下文），在 Endpoint 处理完之后将上下文中 Session 的最终状态进行存储。

而 ASGI 中不存在这样一个上下文存储，所以 Starlette 才会把 Scope 当作上下文，而最终的 Scope 又不会被传递至 send，就导致了一系列问题。

@abersheeran ASGI 标准我感觉没什么前途，标准已经推到 3.0 了，但是各个实现都还很不完整，设计上也有点问题。

举例子说的话，比如 scope 明显应该是一个单例，但是 ASGI 里却将 Scope 定义为了一种 immutable，并且是在中间件之间可随意复制的。这埋下的一个巨坑就是对于一个中间件来说，根本没办法获取到最终的 Scope 引用，从而不能在 send 期间访问到一个稳定的上下文。

也就是说，这个半残的中间件机制甚至连一个稳定的，不需要在请求里操心存取的 Session 都实现不了。Starlette 里的 Session 实现是有坑的，他们把 Session 存到了 scope 里，违背了 immutable，然后使用了 ASGI 明确声明不可靠的闭包 scope 引用去在 send 期间检查和存储 scope 中的 session，这就使得 scope 一旦被复制，session 的管理就变得完全不可靠了。

而这根本就是一个 ASGI 标准的问题，因为基于性能的考量，一个上下文状态本就应该是单例，可变，不可复制的。

所以总之就是，如果有心力的话，可以考虑把实际的性能对比拿出来，提一下 PR，测量点应该主要有这几个：

模拟一个简单的路由情况，提供树实现和遍历实现的性能对比（非 WSL 的 Linux 下内存、吞吐、延迟）。

模拟一个常规的大型网站的路由情况，提供性能对比。

模拟一个深层次的路由情况，提供性能对比，看一下你的实现是否会在深层次的时候性能跑不过遍历。

模拟一个树被压成单层扁平的路由情况，提供性能对比，看一下你的实现在做普通遍历的时候性能会不会跑不过当前的遍历实现。

如果能实现全面的性能提升，并且代码风格良好的话，我觉得 encode 社区会很乐意接纳的。但如果因为误解而没有心力了的话也不勉强。

我仔细翻了一下你之前的讨论（在 7 月 13 日前后），实际上是没吵起来的。

社区成员 erewok 表达的意思仅仅是之前关于这件事就有讨论了，所以更希望有实际的实现和性能对比，而不是在要求一项功能。并且后面的意见也是希望能开 PR 出来，用性能实测数据说话。

Tom 的意见是简洁优先，但没有明确拒绝一项性能改善。所以你注释充足结构清晰，拿代码说话的话也是可以 PR 的，性能始终是 Encode 社区的很重要的考量。

“大哥哥，你的作业里的 dx 是什么意思呀，是解方程吗，好厉害！”
↑大约就这种欲言又止的感觉…