写大文件可以 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 设计成什么样传进去的参数就是什么样了。

基本上比较好玩的桌游规则都比较复杂，不是短时间内能学会玩好的。最难的是大部分桌游一个人都没法玩，你要在现实中凑出来三五个兴趣爱好时间都比较相近的朋友还是很困难的，特别是当你工作以后。比如 DND 这种，跑个团按小时计算，为了保证每次活动都能组起来，而不会因为某人突然有事完不成，你得有个十人左右规模的群才可以。
就跟你网游工会活动一样，除非都是硬核玩家，不然全是工作党的工会你得至少三四十人才能保证活动。

@binbinyouliiii 过了试用期再说吧，起码先了解一下环境。同事之间熟悉了没问题，不熟的话你还是新来的，产生什么刻板印象以后就再消除就很麻烦了。

耗电也就算了，iOS 版的缓存逻辑有问题。刚装好后几百 M，用一段时间以后发现占了几个 G 的空间，打开清理缓存看就还是只有几百 M。
只能每隔一段时间卸载重装。
而且强制你看启动图广告，有的时候网卡一点刷不出来广告就在那卡死你也不会让你进去。不过最骚的是有时候你就切到后台一小会，再回来的时候还能看见刚才看的内容。然后等你看个几秒立刻弹出来启动屏广告。

啥也不用想的自然是 EF 最方便，文档也是相当全。一般的需求只需要点几下鼠标生成对应的代码，全程不需要写 SQL，而且对 Linq 支持极好。缺点就是这框架为了让你可以不写 SQL，做的相当的复杂，你要学的东西很多很多，不然出了问题很难调试。但用 EF 的时候你需要注意就是它不是很推荐你去手动修改数据库，最好是直接写代码，直接用 EF 映射成数据库，不然会有各种问题。
Dapper 就简单很多了，你自己手写 SQL 进代码，查出来的东西直接映射成对象。
个人建议时如果你不是很熟悉 SQL，就用 EF。毕竟很多时候水平一般的码农写出来的那 SQL 还不如 EF 自动生成的。如果你的表关系非常复杂，会有各种关联更新查询删除啥的，也用 EF 吧，毕竟省得你去搞那个复杂的 SQL。如果你很熟悉 SQL，或者你的查询不会很复杂，那就用 Dapper。毕竟这框架需要你手写 SQL，不会自动生成，非常简单。因为简单，性能也很不错。
这里有个官方对比
https://entityframework.net/ef-vs-dapper

上古时代 Windows API 里的各种 HRESULT 不就是这么干的么。。。

N 卡的话有个 GUID
你运行 dxdiag.exe ，保存全部信息。打开那个 txt，找到 display device 那段，里面有个 Device Identifier，是个 GUID。
这个应该都是不一样的