强烈推荐 http.Transport

@R18 echo 出现时间和 gin 差不多吧. 没对比过 echo, 但是我和 bare net/http 对比过 RPS

@missdeer 除非 beego 用了非 net/http 实现, 否则不可能, gin 性能和 裸 http 差不多.

@Pipecraft go 周刊可以试下，阮一峰那两千多 PR 了🌚

我也写过一个内存缓存库，使用 hashmap 和 heap 实现 ttl

@ClarkAbe 性能很不错, 在路径较短的时候接近静态路由了.

@GeruzoniAnsasu 使用有锁队列保存任务; 任务完成后去队列拿下一个任务, 递归地调用;

@GeruzoniAnsasu 不知道我写的这个库是否满足你的需求
https://github.com/lxzan/concurrency

@GeruzoniAnsasu 添加任务的时候加序列号, 线程同步后给输出结果排序

@5h4nh 源码很难读是因为复杂性, 实现得异常复杂. 当然简洁不代表性能.

@hailaz 不行. 但是实际项目里面可以, 因为"/"会被注册到静态路由区

@ClarkAbe 还好吧，只在注册接口的时候创建一次 map, split 的 alloc 不可避免. 后续我测试下 sliceMap 怎么样，O(n)遍历数组

@ClarkAbe 我的测试代码在这里: https://github.com/lxzan/uRouter/blob/main/trie_test.go

@ClarkAbe 可以控制变量和我的对比下: 1024 个接口, 每个路径分 4 段, 参数位置随机

@ericls 实事求是突出主题. 总不能这样起标题吧: 震惊! 比 gin 快一倍的动态路由解析算法 (乱说的, 没测试过)

@GeruzoniAnsasu async 有传染性, 同步方式写异步代码对开发者更友好, 但是牺牲了性能.

@zhanshi 开发环境一般把静态文件放 NGINX.

@tt67wq 我会尽量使用 mutex 替代 channel, channel 明显被滥用了.

@TtTtTtT go 的源码实现很复杂, 一般人看不下去. map, sort, channel 皆是如此.