@gvison 你的方案确实可以，但我不想引入额外的包而且我就想把主页挂在 / 下，有无办法只用 gin 实现？

@kingcanfish 你的方案会有两个 301 重定向，当你碰到首页不在根目录下的情况，你的最佳实践是什么，我目前的做法是

r.GET("/", func(c *gin.Context) {
c.File("dist/") // 会直接返回 dist/index.html ，没有重定向
})

把 / 映射到 index.html 应该很常见吧，有更好的方式么？

@lovelylain 什么意思？你的意思是 /dist/index.html 会内部转发到 / 么？但是，wget 确实收到了 301 ，然后一直有尝试重定向，然后一直收到 301 。

@tbxark 原因我昨天通过调试就已经知道了，就是先把问题代码贴上来，看看大家能否一眼就能看出，你提出的修改方案也还是会返回 301

// 还是会返回 301
dist, _ := fs.Sub(dist, "dist")
router.GET("/", func(c *gin.Context){
c.FileFromFS("index.html", http.FS(dist))
})

补充一点：帖子被贴上 “404 not found” 的标签了，应该是没有创建 ./dist/index.html 文件的缘故，但这里说的问题并不是这个低级错误。

- wget http://localhost:8080 返回的是 301 ，而且我这边返回的是 20 次 301 （超过阀值强行退出）。

如果您刚掌握了 gin 的基础知识，可以参考 https://github.com/gin-gonic/examples 和中间件示例 https://github.com/gin-gonic/contrib 。

两者本质上都可以抽象成，一个线程池在完成多个任务队列，那么问题来了，既然两者都差不多，然后，Go 还引入了
goroutine 抽象层，为什么 Go （可能）要高效一些。如果所有任务都是非阻塞的，那么多线程和 goroutine 在性能表现上差别可能并不明显（猜想，未验证）；但在现实情况中，由于 I/O 或通信等原因，不可避免会发生阻塞。传统线程一旦阻塞，则会占用整个线程资源，而 goroutine 在阻塞时会被挂起，并在等待条件满足后重新调度，大部分时候不会需要阻塞底层线程，从而更高效地利用系统资源。也就是说，如果你很 NB ，能够做到又能尽量少阻塞线程，又能把任务完成（也就是高效利用线程池，这就是 Go 调度器做的事情），那么两者差别不会很大。

除了以上其他人所说，我认为还有一个重要原因，在 Go 中，对象的概念主要通过 struct 实现，而 struct 为值类型，为了让方法修改其内容，只能依靠指针，所以，只要还有值类型存在，而函数传参均为值传递，那么如果希望定义能够修改对象本身的方法，就必须使用指针。

@cloverzrg2 PeerGuard “夜幕降临，我的守望始于此，直至死亡将我收走。我不娶妻、不育子、不占有土地；我不争荣誉，不戴王冠；我只在城墙上生、老、病、死。我是黑暗中的剑，是守护 peer 的盾，我以我的生命和荣誉守护
peers ，直到永远。”

1. 看到 PG 第一反应联想到 PostgreSQL 。
2. 在阅读 README 时，我发现了一个有趣的词——“Birthday Paradox （生日悖论，在一个群体中，只需要 23 个人，就有超过 50% 的概率存在两个人的生日相同）”，用在 NAT 穿越上，指的是在双方都知道对方 NAT 地址但不知道对方 NAT 映射端口的情况下，各自随机选择一组目标端口发起通信，从而有一定概率能建立连接，这不禁让人联想到你我相识全靠缘分。最近刚好看了两个关于概率相关的数据结构：跳跃表和 HyperLogLog 。感叹数学真美和烧脑。

@daimaosix 不是大佬。关于你的问题，如何界定“无用”？如果定义了一个本地变量但没有使用，这种情况很容易界定，因为该变量仅在其所在范围内生效；但对于其他函数、变量或类型，编译器很难判断它们是否“无用”，可能你只是想编写一个供外部调用的库，而并非在自己的程序中使用它们，这也是合理的。如果你确实想知道哪些代码没有被使用，直接查看代码覆盖情况即可（`gool tool cover`)。

项目有很浓的 AI 味，我花了半小时看了下，有几个疑问：
– 自适应分区究竟有什么用？我只看到分区调整，好像并未真正应用；
– 自适应限流似乎并未实现，只见一个 adaptive 字段，却看不到任何实际使用；
– 这个项目的意义何在？仅仅是统计 QPS 吗？（既然都用 Prometheus ，为何不直接上报，而要绕一个弯路）或者是作为中心限流器？（我的理解这个一般在流量入口（负载均衡或网关）处就做掉了吧） 。
– 令牌桶已有 golang.org/x/time/rate 这样稳定的实现了，没必要再造轮子了吧。
总结：一个项目把所有后端爆款关键字都用上了（“百万”，“精确”，“高性能”，“优雅”，“自适应”，“智能”...)，我的感觉就是一个（ AI ）炼手的项目。
唉，我的时间。

@kkhaike “As part of building a test binary, go test runs go vet on the package and its test source files to identify significant problems. ” 以上这段话摘自`go test`文档。`go test`会在编译测试代码之前，运行`go vet`，`go build `则不会。

@RedisMasterNode 问了下 GPT ，得到了一个我之前也没注意到的新功能（ go1.17 引入）: pprof labels
```go
func handler(w http.ResponseWriter, r *http.Request) {
// 为当前请求创建一个带标签的 Context
ctx := pprof.WithLabels(r.Context(), pprof.Labels("request_id", r.URL.Path))
pprof.Do(ctx, pprof.Labels("request_id", r.URL.Path), func(ctx context.Context) {
// 在这里执行业务逻辑，该段代码调用的所有 CPU 占用情况会带有指定的标签
doSomeWork()
})
w.Write([]byte("ok"))
}
```
后续可以通过`(pprof) tags `查看所在 label 所占用的 CPU 。

OpenTelemetry + Jaeger 能够详细量化单个请求中各阶段所耗费的时间.

整理了下, 基于小鹤双拼方案让 hop.nvim 支持中文的扩展上传到了 github 上, 地址: https://github.com/zzhirong/hop-zh-by-flypy, 最大的好处就是, 支持 vscode-neovim, 另外, 不会在高亮跳转目标时改动编辑内容, 从而不会惊动 linter.

@xell 其实我已经切换到 https://github.com/phaazon/hop.nvim 了, 因为 EasyMotion 的一个缺陷(高亮时会改动 buffer, 触发 linter 报错, 详见 https://github.com/easymotion/vim-easymotion/issues/402), hop.nvim 就不存在这个问题, 另外, 它也可以直接在 vscode-neovim 中使用, 所以 VScode 专门版本的 EasyMotion 是不需要了. 回到支持中文, 我暂时通过修改小部分代码的方法让 hop.nvim 支持中文, 源码暂时还没整理上传, 我想有时间把修改封装成一个 hop.nvim 扩展再上传到 github 上.

@stoluoyu 根据一个新的双拼方案定制插件其实很简单的, 只要修改下`autoload/EasyMotion/cmigemo.vim`中的`s:Flypy_table`这个映射表就可以了.

@jeffShell 我也是音形用户, 暂时没有想到如何运用鹤形到里面去, 就目前来说, 音码已经够用了, 因为跳转的目标是当前窗口或行中的所有文字, 因为文字总量很少(应该只有几百个), 对应每个音码的重码个数已经很少了, 如果引入鹤形的话, 唯一想到的就是, 高亮目标的时候, 通过形码来标注, 比如, "的"和"得", "的"高亮为"b", "得"高亮为"i", 但如果是这样的话, 同行或窗口中有多个"的"又该如何区分?