内部系统，django 加自带的 admin ，开发又快，库又多，没有不用的理由吧

看完感觉确实沟通有问题，特别是面试官老搞各种缩写。。。不过这个面试官不像正经招人的，虽然对 hr 来说不是 kpi ，但是面试官的组不想招人所以在应付……这可能是流程制度问题？

gro3k 本来就是目前最强的，差点很正常。

用 certbot 插件，
全自动配置 nginx ，啥脚本都不用写

网盘咋想的，至少得支持多版本吧。。

@Altale #58 经常发版的框架说明 bug 多 这句话太扯淡了。

@LitterGopher #55 https://github.com/gin-gonic/gin/issues

@Altale #58 你不看 issue 吗？？提了多少 bug 了，还有很多子依赖版本有漏洞，都需要升级

@nobject #51 而且 gin 本来就没啥功能，就图个轻量，现在还得考虑这些事情，那干嘛不换一个。替代品太多

@nobject #51 你这么用当然行，不过不是正式版本，说明没怎么测试过，为啥非要强行担这个风险呢？ echo 官方维护测试积极地多

@klakekent 不兼容 http2

@LitterGopher #40 你看上个版本是啥时候发布的，没人发版，难道你是自己 fork 下来用吗 https://i.imgur.com/NIvxivj.png

gin 太久不维护了，用 echo

@bbao #64 你第一、二点回复和我说的有矛盾吗？ 3.2 临时创建 M 就没代价了？而且受还 GOMAXPROCS 限制，不就是降低并发效率。你是补充还是反驳？反驳也没反驳到点上啊 还是你没看懂我说的

我觉得所谓表达能力差就是事先没准备。

你说的就是 mojo ，已经在开发了

1 、goroutine 初始栈 2KB （会动态增长的，并不是说一定省内存了），而操作系统线程的栈通常 1MB
2 、Go 运行时内置调度器，相比线程由操作系统调度，goroutines 的上下文切换成本更低，避免内核态的开销。
3 、配合通道减少了竞争的问题，使用简单
缺点也有：
1 、没法控制怎么分配到 cpu 核上，开几个协程可能都挂一个线程上，，利用不了多核资源
2 、GUI 生态多是线程绑定，go 对这块的兼容很不好，没什么生态
3 、协程一旦执行阻塞系统调用，会把整个线程阻塞，导致该线程无法执行其他 goroutines ，降低并发效率
4 、协程不适合 CPU 密集型任务，因为没什么 io ，上下文切换反而增加了开销，，调度器也有损耗，不如用多线程直接绑定到核心上

选择困难症了。用 python ，一个 requests 解君愁 https://i.imgur.com/agAJ0Rd.png

单机你这场景可能不需要 redis ，直接进程内缓存读写，最最快