向死而生，离最终解脱又近了一天。

先搞清楚，通信协议相关的安全算法主要是防止信道监听者。这类似战争年代无线电被监听、加密防破解。

不是用来防止具有密钥的通信两端的，因为两端本来就各自有密钥。所以这种有机器权限的就不适合 OP 讨论范围。

另外，如果想绕过，你装个虚拟机，在虚拟机里跑，应该就可以了，如果想更狠，虚拟机里再加上加密隧道、VPN 。。。

@echoless
#2 这种观点适合能力强的个体，不适合群体。
对待群体，需要用宏观思维。金融泡沫催动下的经济大周期，本质是供需关系，需求减少、没有那么多 HC 了，不管人们怎么努力等待，都会有对应比例的人失业或者找不到好的职位。

@8520ccc #4 那就无所谓了，自己用着舒服就是最好的
@zmqiang 欢迎使用!

之前在其他帖子也聊过，其实基础知识部分而言，学习 sql 本身并不比学习 orm 需要更多时间，而且逐渐积累起来，你对项目的掌控能力更强，尤其是性能相关，这是对于做大一些的项目的一些核心能力、涨工资或者说进阶的必备知识。一开始便依赖 orm ，并且不求深究，相当于自断了技术进阶的道路。
当然，比如家里条件比较好、只是给自己定位 curd 中小项目，追求的是 work life balance and happiness ，那就无所谓了、orm 挺好

ORM 没什么好的，试试我这个丫：
https://github.com/lesismal/sqlw

转 go 这些人哪，入乡随俗了解一下，非要越搞越蹩脚。。。

@Frankcox 我来啦，感谢 at ！

当初提这个 pr 是因为我的 nbio 实现的 http 兼容标准库，这涉及到 Request 的 context 字段，每个请求的 context 应该是共用一个全局的，这样当全局的 context 退出（比如进程退出、cancel 时），这个 request 的 handler 中使用这个 context 就可以一块退出（比如使用 Mysql 时传入这个 context ）。但这个字段不是导出的，所以没有办法直接设置。

由于标准库规则严格、不肯开放这个字段导出，至少对于官方而言，他们不考虑 nbio 要解决的海量并发连接数写成数量、内存开销、GC 等问题，所以官方也确实不需要开放导出。

无奈只能使用魔法了，预先用 WithContext 生成了一个带有公共 context 的 Request ，后面创建新 Request 时 *newReq = *reqWithCtx 整体赋值，就避过没导出不能设置的问题了。不过虽然能用，毕竟 Request 结构体有点大，这么做能用但不划算，凑合用吧，毕竟我也支持官方不随意放权。。。 :joy:

回复内容不能为空

@beidounanxizi
也就小作坊才会这种个人随便提交就发生产了。最大原因还是管理不善，我呆过的团队基本没出过这种个人瞎搞导致的事故。
如果出了这种问题还不反思，那下次再招聘到这种队友呢？全怪个人吗？人是管理者自己招进来的，管理者自己不制定团队规范，不用改进更科学的方式去带团队，开除只是解决眼下问题，并不是建设高质量队伍的手段
不过小团队的话，大家都是混口饭吃，团队规范费神，看管理者个人追求了

相比于多数人，有一颗折腾轮子的心，会有更大的几率技术向上突破，能不能突破要看实际情况了，比如遇到牛逼的团队规范的流程、他自己想造事故都比较难有机会，但像一般的中小团队流程没那么严格规范、个人行事权限充足，他就可能惹祸、职场不顺利。

毛躁是他的错，团队不规范也有锅，基于团队水平现状、开除可以减少事故率所以也是正确选择。。。

如果运气好，他找个更好团队继续飞升。

我就认识 90 后小伙子，工作前三年干倒了 6 家公司，并不算是他不靠谱，而是出身比较差去的都是比较破的公司，他自己比较上进、一直折腾轮子、搞群拉了我们好些人、老跑来跟我们问各种 sb 问题，问题从弱智到越来越高级，三年后进了家比较不错的公司，技术远超原来那些 CURD 同事，待遇也高一截

少废话，先 star

-r 这个你不考虑合理性的话，那 nbio 的异步解析器肯定吃亏的，如果非要这么卷我有点想再搞个同步解析器来兼容了😆。。。但是这除了浪费我体力没什么实际意义我不想死那么早😆。。