这种 body 分离的设计是合理的，有一些需求不能按 OP 的想法直接一个 fetch 就返回整个 response

首先有的需求只需要获取 HTTP header ，不关心 body 是什么，那么浏览器只需要把 header 读取完即可返回，减少不必要的网络请求
其次是解析一个可能无限长的 body ，既一个很长时间才会出现（或者根本就不存在）「 0\r\n\r\n 」的 chunked transfer encoded body 。这种情况下除非出错，基本上很难等到 await 结束，而且可能在此之前内存就已经消耗殆尽。显然合理的做法是先读取完 header 返回然后让开发者调用 body 或者 arrayBuffer() 做流解析

像 .Net 的 HttpClient 也有这种设计，可以通过设定 HttpCompletionOption.ResponseHeadersRead 先读取完 Header 返回 HttpResponseMessage 再通过 Content 获取剩下的部分

@theklf4 #6 除了连接性外还有网络设施带来的带宽流量成本等的问题，哪怕是国外高校也得面对这些

GetProperty/GetValue 这一套下来慢是必然的。一种解决方案就是使用表达式树，生成一个获取 t.prop 的委托；第二种就是使用 Source Generator 把用到的 T 的所有属性的获取代码都生成出来，0 反射

@keyfunc 我没有自行部署就不太确定

用这个 https://greasyfork.org/zh-CN/scripts/25718-%E8%A7%A3%E9%99%A4b%E7%AB%99%E5%8C%BA%E5%9F%9F%E9%99%90%E5%88%B6

根据 https://devblogs.microsoft.com/dotnet/configuring-https-in-asp-net-core-across-different-platforms/ 里说法是为了提供一个接近使用生产环境的开发环境，而这种开发环境的需求可能和 web 前端里调用浏览器的某些功能强制 https 有关。至于反代的话，有些人不一定喜欢在开发环境额外部署。可能会存在部署多个主机调试的需求，这时候就用不了 localhost 了

这看起来像是 5432 暴露公网然后被人攻击了

应当明白一个常识——正则表达式不是万能的，它不能匹配 HTML

这个需求最简单的方式是找个 HTML 解析工具得到 DOM 然后直接修改其每个 innerText

从描述来看应该具体指 serverless function

1. serverless function 对语言没要求，只要平台有能运行该语言的运行时即可，有些甚至可以自己提供容器镜像作为自定义运行时。像 AWS 就能用 C# 甚至 PowerShell
2. 能用，需要自己额外提供数据库

关系型的话用 TimescaleDB ，起码能自动分表还能对历史数据做压缩

@Joker123456789 理论上 uniswap 有交易对的应该也能。当然如果交易对只有 uniswap 有，最好还是直接在那边 swap ，不用给 metamask 手续费

它这个 swap 是个聚合器，是从包括 uniswap 在内的多个 dex 中算出哪个能兑换最多的目标 token 然后使用那个 dex 来 swap ，顺便收点手续费来维护这项服务

fetch 直接调用 Response.blob()，而 axios 要在 Request Config 设置 responseType 为 blob

这不就是贝塞尔曲线？

既然都 pg 了，这需求加个 timescaledb 扩展也好

严格上说这是机制的问题，不算 bug 。Notification icon 的创建和删除都是由应用程序自己 Push 给 explorer.exe ，但 explorer.exe 方面并没有设计一套 Pull 机制来主动了解 notification icon 所属的进程是否存在。所以进程崩溃了没法自行删除，就一直显示在那里了。而 explorer.exe 崩溃后 notification icon 不会重建也是因为这套机制导致的

至于为什么一直不加我不知道

@golangLover .Net 方面的话博客园也不推荐