hellojl

那一天，我二十一岁，我一生的黄金时代。我有好多奢望。我想爱，想吃，还想在一瞬间变成天上半明半暗的云。后来我才知道，生活就是个缓慢受锤的过程，人一天天老下去，奢望也一天天消失，最后变得像挨了锤的牛一样。可是，我过二十一岁生日时，没有预见到这一点。
王小波，《黄金时代》

3 ，不用考虑； 4 ，垄断型的央企可以考虑一下，其他面对市场竞争的不是很好过

还是在 1 和 2 中选。

三线城市的生活成本通常要比省会低，当然生活也更无聊一些。如果对这方面有需求，可以考虑一下 2 ，但是公务员如果想要过的滋润，基本都要有灰色收入，否则的话还是 1 更好一些。

个人也更倾向于 1 。

子公司没有稳定性可言。国企不裁员，但是人当狗使，卷的一逼。没有背景的话极难升到管理层。做好事情不如添好领导。
另外卷的根源不在于事情多，而是事情不够多，所有很多行政部门为了做事会推行一堆乱七八的政策，一堆人学习政策，在推广到所有人落地政策。写 PPT 的人比干活的人还要多。

@hesetiema 我最早是在 17 年接触的功能开关的概念，但是国内用的确实不多，大部分还停留在灰度发布的阶段。今年面试确实难，我也挂好几家了，共勉吧......

内容穿透容易被公司探测到，是否会封禁或者处罚要看公司

需要解决的问题都是如何小批量的验证新功能。

灰度部署和金丝雀部署通常存在新旧或者 A/B 版本，通过逐渐放量到新版本上，验证上线、新功能是否 OK ，需要基础设施的支持。而在部署两个版本的情况下，通常对基础设施要求会更高一些，比如如何实现上述的按比例 CD 的功能。另外一个隐藏的问题是，对于流量的控制不在程序本身，一个请求访问新 or 旧版本，需要由上游的调用方确定，实际中上游可能是 Nginx 、网关或者另一个服务，需要适配的会比较多一些，对于一些请求链路比较长的服务不是很友好。

后续有一些公司尝试了名为 Dark Launching 的方案，也就是 Feature Flag 功能开关。好处是可以在一个服务内实现更细粒度的请求控制，对于上下游调用、CI/CD 也很友好，因为对于外部来看这个服务只存在一个版本，实际新旧是由服务内部类似 if/else 的逻辑控制的。缺点就是对代码有入侵，功能正式上线后可能还需要去掉 Feature Flag 相关的代码，虽然一些主流的库不去掉也机会没有性能影响。

个人使用体验来看，更倾向功能开关的方案。虽然功能开关的方案对代码有入侵，增加代码复杂度，但是整体上看增加的内容不多，而且在代码层都能控制。无论是灰度发布还是金丝雀发布，在基础设施层引入了更多的配置，实际上会增加出问题的可能性。

面试问这个没什么问题，只要涉及到新功能上线、小批量验证的需求，其实都需要考虑类似的问题，不区分前后端。

英雄联盟。以前会跟队友高强度打字互相交流问候，现在就只有问号和白旗了。

线下的社交基本以同学出差为主了。同事们之前偶尔会下班喝酒，强制加班后同事之间已经不约了。

陌生人社交，不存在的。