@kiddingU 你不说可能没事，说了可能就有人想要开始 diss beego，进而开始 diss 楼主了。

桂林到阳朔段的漓江风景是桂林最值得看的风景之一，不建议用其他交通方法去阳朔，建议买船票。

别吧……我觉得这个框架设计出来简直就是给人制造麻烦。

学 haskell 吧。

其实学了 Spring 的核心思想之后，觉得“把程序的入口点交给框架，让它帮我把我写的各种组件拼起来，不要我自己 new 出来并且传来传去”这个想法还是蛮好的。

@whileFalse

> 依赖注入是有很高成本的。启动时间、运行速度、框架的可理解性都是成本。

之前学了一下 go 的 wire，用的是代码生成方式的依赖注入，我感觉就还挺好的……启动时间和运行速度应该都不会有什么影响，大部分依赖注入的问题也会（比起运行时依赖注入来说）在编译阶段就暴露出来。可理解成本确实会增加，不过依赖注入本来就是为了减少依赖很多的时候自己组装依赖的成本，我觉得可以接受。当然我还没深入使用过这个框架，按照我的理解，如果你一定要把运行时的事情放到编译期间去做，那肯定是会有一些 Trade Off 的……

想起轮子哥好像说过（他的观点不一定对），很多语言没有依赖注入之类的那一套，并且喷 Java 扯淡，是因为他们还没有如此复杂的项目需要用上这套玩意儿，等哪天这语言被广泛用于复杂的项目的时候，就会发现他们讨厌的那一套都回来了。

首先，去过楼主手汗比较多的话，建议不要买。因为手上有汗的时候摸触摸板会非常的不顺滑，好用的也变得不好用。

另外依据我个人的使用经历，说 Mac 的触摸板好用不如说 Mac 要是没了触摸板不好用。我现在日常也不一定用触摸板，一般用 m370 鼠标，这个是真的好用。

@Immortal 看来一楼这位用户是 JS 使用者了。

我也说一下我遇到的两次类似的事情。

第一次是我发现一旦 apt update 就报错，然后我 curl https 的网站，发现 curl 直接就 coredump 了，查看 dmesg 好像是 libgnutls 啥的出了问题。我想重新装一下这个包，但是又没法 https，又不想 http 。于是我在别的计算机上下载了一个这个包的 .deb ，安装后一切恢复正常。

第二次是 curl 某些 https 网站说证书错误。结果我重装一下 ca-certificates 这个包就好了。不过当时已经知道 apt 源下下来的东西都有 pgp 签名校验，于是就直接全改 http 源就能访问 apt 源了。

两次事情都出问题在 tls 相关的组件上面，你们说我是不是可以去买彩票了。

50 块，十分钟。

Spring security 这玩意儿真的有人用吗，感觉就是个黑盒，出了问题文档说不清，看源码随随便便就能抽象一堆东西出来，完全理不清楚内部的逻辑。

avahi

go 这种是对称协程，没有老爸儿子的概念。

@JamesMackerel 放在心里-> 放在

另外，楼主的文章里的说法：用 jwt 可以防止 csrf。csrf 本质上是用户不在你的网站，却能向你的网站发送请求，并且这个请求中还能带上他的凭据而导致的问题。所以要解决这个问题，要么你验证请求是不是你自己的网站上发来的（验证 referer ），要么你想个办法不要让浏览器自动把用户凭据带到请求里。

把 jwt 放在心里 authorization 里的操作一般写在 js 里，而不是利用浏览器自动携带 cookie 的行为，所以天然避免了 csrf。但是如果有人把 jwt 扔到 cookie 里，而且还没做 csrf token，那么其实还是会有 csrf 的问题。

@encro 很多人对单点登录自动跳转有误解，认为它可以管理接入服务的 session。实际上单点登录并不管理甚至不关心你的 session。单点登录的职责是认证用户，并且把用户的身份提供给接入方，用户的登录态还是要服务自己管理。

加密字段需要查询的话，目前在网上别的地方看到的一个方案是做一个冗余字段，在里面放一个 原文加盐后 Hash 的值，查询的时候就查这个字段。但是假如遇到了碰撞，那就真的不知道怎么办了。

如果这个时候我失业了，我想我会去武汉做志愿者。

话说 autocmd 应该本来就有 ft 识别的吧。有必要把它放到 ftplugin 去吗。