最简单的就是自带的那个 Server Manager 了吧。
Prometheus 也支持 Windows。

Gitflow 实际应用的时候还是直接用集成的解决方案比较好，虽说单纯用 Git 也能做，但是比较麻烦。
目前个人体验比较好的就是 Jira+Bitbucket，在 issue 上可以一键开 branch，source tree 弄下来就能开发，后续的 MR，Review 也很方便。
Gitlab 也有这功能，但是它自带的 issue 管理比较弱。如果觉得够用的话也可以试试。

飞利浦是旋转式，不太适合比较浓密粗硬的胡子
博朗和松下都是往复式，刮的比较干净，但不如旋转式刀头用着舒服。
这几种电动的直接买旗舰款就可以了。
最舒服方便快捷的就是手动，吉列锋隐加妮维雅的剃须泡先买来试试，习惯以后可以买兼容的刀架，有木质手工的。

devops 这东西是纯坑，跟当年的全栈差不多。你既要懂一些开发，会写代码，明白项目需求，构建测试流程；还得有办法修好那些乱七八糟的网络系统问题。搞到最后你就是给整个团队擦屁股的人。开发完不成功能找你帮忙写代码做需求，哪天服务器崩了你得 7x24 滚回来修。
就算是 k8s，照着文档跑一套起来很容易，但是你作为运维，这东西崩了你得有办法修好。这就不仅仅是 k8s 本身的问题了，操作系统，网络基础积累不够你可能都不知道哪里坏了。

个人意见，你如果有心学习不管是前端开发还是运维，都能学到不少。计算机相关的所有技术都不是凭空造出来的，就算是前端开发，MVVM，工程化等等实践也全部都是几年十几年前就做过的东西了。你可以对比一下这些概念在这十几二十年里面有什么发展，多深入了解总结一下就能有不少收获。更不说浏览器本身就是一个极其复杂的项目，布局渲染 v8 都够你好好学习的了，不存在什么“应用层比较靠上”的问题。

写大文件可以 File Mapping，很容易。
但是不建议做成 CSV，这东西不是一个非常标准的规范，总有各种各样的问题。
如果你导出的数据只是内部使用，可以直接导出到 Sqlite 或者 Access 数据库。
这种的 Excel 也能直接用

大多数软件开发的技术并不值钱。
虽说开发健壮稳定可扩展的软件对技术要求很高，但很多时候企业考虑的是如何活下来。你可以说花时间做一个特别牛逼的系统，可还没做出来公司就拖倒闭了，这种系统半毛钱价值都没有。
做技术的总有一种错觉，以为技术可以解决一切问题，技术牛逼了什么都有了。但对于大多数公司来说，销售才是核心竞争力。你东西做的再好，卖不出去也是垃圾。
毕竟大多数公司造的又不是火箭，大多数 IT 的技术也不是除了你以外别人做不出来的东西。

@dcoder 性能问题只要你做聚合就都会有的，用不用 GraphQL 都一样，也不用期待 GraphQL 能解决本应该用其它方法解决的问题。
其实自己做一个聚合查询的接口也可以，但要自己设计 API，Parser，配套的辅助工具，再给前端后端讲清楚接口。
GraphQL 实际上做的就是这些事，省了你自己设计这 API 的时间。基本上是和 Swagger 类似的地位，也没人指望 Swagger 能解决端口的性能问题吧。

Type C 的 PD 协议分好多种，想要达到最高的充电效率，你的线材，充电头必须的全部达到标准才行。
你用的充电头功率不够，或者线材比较劣质，哪怕你的设备支持更高等级的标准实际使用的时候也会降级。笔记本的话会插着电源使用也一直掉电，或者干脆充不进去。
你买个 65w 的充电头，支持 5A 的线材，足以应付绝大多数使用 Type C 的设备了，不管是笔记本手机还是 Switch。

不管是什么技术，总有个适用范围。没什么东西是万能的。
GraphQL 的语法也好，ElasticSearch 的 Query 语法也好，SQL 也好，本质上都是一个用来 Query 较复杂结构的 DSL。你如果把整套 Graph QL 抽象为接口，那么你认为你是在前端写 SQL 也没有问题。
但 GraphQL 主要是用来解决 API 设计问题的，至于怎么优化查询并不是它的重点。SQL 本质上也是一样，这种语言是设计用来查询关系型数据的，怎么优化是 DBMS 的事。
REST 接口实现简单，也没什么复杂的心智负担。但如果你需要做成 REST 的东西比较多的话，前端免不了做一堆的 Promise 来回的查。而且这种多次查询后台也没法做优化。
你给每个需求写个 API 可以做到细致的优化，但是前后端很难同时开始工作，你得先定好接口，Mock，或者上 Swagger。而且这种写法扩展性有限，新增需求很多时候你就得新弄个 API。
GraphQL 和 ElasticSearch 的 Query 比较类似，优点不在于优化性能，而在于更大程度上去释放系统的可扩展性。比如你要做个类似 Kibana 的工具，绘制的图像各个轴可以自定义 model 和 field，但不涉及特别复杂的计算聚合和优化。那么类似的东西就是最好的选择。
真正使用的时候还是要根据自己项目的特点去选择合适的技术，不是看什么新就用什么。GraphQL 也有一大堆的缺点，但是你的需求如果可以正好避开这些缺点，同时它擅长的东西也是你想要的，那么没什么理由不用它。

风行卖的是车架，基本都是淘宝自组。
大行的话你可以找附近的实体店买，会比京东淘宝常规价格便宜。而且售后什么的找实体店修就好了。
刚开始骑行的话，很多地方你自己不会弄，有个实体店帮忙会好很多。比如简单的保养换胎什么的。
车的话你可以考虑大行 P 系列，不过都是钢架并不轻。钢架优点就是比较坚固，骑车发力会比较容易。但是 P 系列没有额外的拖动轮，折叠起来拎上楼还是很沉的。
不差钱的话可以考虑小布，折叠以后可以拖着走。
如果你之前有骑行经验，会自己选配件维修保养，那就直接风行买个架子自己拼好了。

@zzxin 雄脱基本都是遗传的。。。你这个。。。。

@ufjfeng
@CommandZi 感谢提醒，我 SIM 卡是最开始出 4G 的时候换的，看来我再去换个卡试试吧。

@darrenfang 没有小火箭，应该不是这个问题。

@littlewing 理论上是的，不过确实我现在已经烦的不行了

还在用 8p，已经快受不了 4G 断流这毛病了。动不动就得飞行模式重启一下，不然就算显示有信号任何 App 也都无法联网。

@jasonyang9 跟血液没关系，无论何时大脑的供血都是最优先保证的。
目前的研究也没确定原因，大概有两种理论：血糖升高和吃的太油腻都会影响激素水平从而导致困倦。
主要还是因为吃的太多了，少吃油腻，少吃高升糖指数的东西都不容易困。

@shijingshijing Java 的话数组声明就是两种都支持的，这跟 Main 函数没关系。不管用那种写法，都只是说这参数是个数组而已。
然而这两种写法比较容易混，比如
String[] arr1, arr2[];
arr2 是个 String[][]
官方的说法是这个[]可以出现在声明的最前面，也可以出现在特定变量处。但不推荐两种写法混着写，所以一般代码规范就强制要求使用一种写法。
这个其实不光会影响变量，比如你甚至可以把一个返回数组的方法写成这样：
String method()[]{return new String[1];}
String[] method()[]{return new String[1][1];}
看起来就比较乱

@codehz 我的意思是 Windows 的 PE 入口是个 int (*)(void)，linux 不太清楚是不是。但是 CRT 这些东西都是一致的。

看你提到了 VS，大概应该是 Windows 程序了。
Windows 程序的入口其实是个 int (*)(void)，没有入口参数的。Windows 创建进程以后调用 PE 入口就没有参数。
然后你的 CRT 会初始化，它会用 GetCommandline 一类的 Windows API 从系统获取 PEB 里面保存的命令行参数，然后构造出一块内存保存这些东西，再用这玩意作为你的 main 函数的参数，调用你的 main。
CRT 传给你的是个 char **，你愿意转成[]随你便的。
包括 Java 那个也是一样，所有写成 main 的东西都是由 Runtime 调用的，Runtime 设计成什么样传进去的参数就是什么样了。