× 找人修图，修到亲妈都不认识
√ 拍些真实照片记录重要瞬间

就我而言，若干年后再看，那些真实的照片反而让我更感动，那些修过的，总感觉好陌生。

妈妈心疼地摸着刚从噩梦中惊醒的儿子的头，轻声说：“你看隔壁那个程序员叔叔，也不知道在干什么，大半夜的，一会儿骂骂咧咧，一会儿又像是在道歉，有时候还突然大笑起来，真奇怪。儿子，咱们以后可别当程序员！”

@mumbler 那个店关门了怎么办，领导一会要去另一栋楼开会要修改一下地址怎么办，领导最近信用卡到期了，要更换支付方式，领导夫人来了，需要多点一些，夫人喜欢吃淡点的，领导除了吃猪脚饭，还能吃什么，总不可能是随便吧，领导想给自己的父母点一些该怎么办。我的核心观点就是，想要精确表达需求，就要有足够的输入，你可以优化输入（比如，最近点过什么，我可以说，就吃上次点的），但是你不能省略输入信息，不然，你得到的结果很可能不是你想要的，各种 UI 都在优化这种输入，比如从常用地址中选择而不需要手动输入地址，你没办法做到不精确描述需求，而想得到一个精确的结果，不然就是开盲盒了（点了什么不知道，送到哪去了不知道，是用美团月付还是用信用卡支付的，不知道，餐具有几套，不知道，我最近牙疼，是不是清淡的，不知道）。

@mumbler 你要吃什么，在哪个店铺，要点多少数量，收货地址是哪，餐具要多少，有无口味要求（可能一个人吃，也可能几个人吃）这些可以做哪些优化？一个界面呈现所有选项么？

我认为，信息压缩也是有极限的，有些东西无论以何种方式呈现，最终还是要呈现，你可以改进压缩算法，但是它的极限就在那，你没办法不说出你的需求，就能得到结果，最多做一些优化（比如常用地址只要选择就可以了，而不用重复输入）。话说，真有人会感觉目前 App 订餐以及打车需要优化么(普通人一天最多也就一两次吧）？

@mumbler 你要选择你要点外卖功能，（搜索你想吃的）然后选择店铺，选择你要点的东西，选择收货地址，写备注，这不就是目前 app 在做的事情么？我想不到哪里还可以优化。

出现这个问题的原因是，更新后，旧版本的 js 文件不存在了，然后，旧的页面链接还是指向旧的 js 文件，获取的时候，返回了 404.html （或其他），你这种情况可能是由于使用文件名来做版本控制（同一 js 文件不同版本不同的文件名），我能想到的方法是，固定 js 链接地址，再由后端来决定返回什么版本的 js ，或使用 HTTP Etag 头来做版本控制。

对话框也属于 UI ，我感觉并不适合所有场景，就订餐来说，食物长什么样的，店铺评价如何，要几双筷子，有哪些优惠，如何支付，外卖送到哪了等等，这些信息用自然语言来呈现不一定最佳。还有打车，你如何精确描述你的目的地，以及到哪接你，以及你可接受的价格。

@kamilic 这本书是好，但内容有点过时了（ 2018 年出版的，第二版的话今年 5 月份发布），详细是真详细，我也是看这本书入门的，同时还看了另一本《 The Kubernetes Book 》（只有 243 页，实用为主，核心概念都都介绍了一下）。

实验环境的话，可以安装 minikube 或 k3s 组建单节点集群，但受限于国内网络环境不友好，我是买了一台外网服务器用来运行 k3s 。

@gvison 看了下引用的 frontend 包的源码，发现 github.com/go-dev-frame/sponge/pkg/gin/frontend.FrontEnd.setEmbedFSRouter 有个新的实现方式

staticFS, _ := fs.Sub(staticFS, "dist")
r.GET("/*file", func(c *gin.Context){
staticServer := http.FileServer( http.FS(staticFS))
staticServer.ServeHTTP(c.Writer, c.Request)
})

这种方案也是可以的，直接 wget http://localhost:8080/ 这会返回 301

@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 ，直到永远。”