不同的模式用不同的解释过程，这个你想了解细节还真得去看 Node 源码。

不过 Node 是要求必须有地方能明确指出你当前文件到底是 ESM 还是 CommonJS，要么是通过文件扩展名，要么通过当前模块目录下的 package.json，目前看来 Node 是无法在同一文件内同时兼容两种模块语法的。

做分布式和语言引擎框架关系不大。
一种思路是去状态化，即不需要在服务器上保存会话状态，然后每个请求处理过程 就是一个简单的面向当前请求的处理过程。

分布式服务连接同一个数据库的话，可以使用数据库事务来保障数据操作的一致性。
要是使用微服务思想的话可以把服务按照功能领域拆成若干微服务，每个微服务有独立的服务、集群、数据库，微服务之间通过稳定的 API 互相调用。

你要想了解细节就得提出细节问题，比如需求是什么，遇到的具体问题又是什么，单讲分布式的话是个超大的概念。

技术是用来解决问题的，没有问题没必要硬上，会事倍功半。

微前端确实是从后端微服务思想衍生过来的，但是并不是说一定要和后端微服务一起用，只是个思想借鉴。
B/S 和 C/S 是非常古老的概念了，自从富前端、单页面应用出现之后，B/S 和 C/S 就没有区别了，它是由浏览器端和服务端构成的，但是同时又是按照客户端与服务器端的思路来开发的，将浏览器上的页面与服务器功能进行解耦。

后端微服务解决的问题主要是降低系统复杂度、性能隔离、混合多种技术栈，那么微前端是不是也有相似的问题要解决。

比如一个有 5 年历史的后台管理系统，5 年间功能一直都在增加，最一开始用的是 Angualr 框架的第 1 个版本，但是五年后的今天 Angular 已经出了第 9 个大版本了，功能和设计以及使用方式都发生了翻天覆地的变化，那么摆在你面前的有两个方案，1. 把旧功能全部用最新版 Angular 重写。2. 新功能也用 Angualr 旧版本继续开发。
以及有的时候需觉得两个功能之间并没有啥关系，而有一部分适合用 React，另一半部分更适合用 Vue，以及一些简单的页面适合直接用原生 JS 或 JQuery。

那么第 3 个方案就是用微前端技术，将复杂的前端系统按照对应的领域拆分成不同组件，可以分开开发、设计以及用不同的技术，最后用微前端技术整合成一个网站。

手腕问题，靠轨迹球恢复了，预算不高可以试试罗技 M570，预算充裕可以上 MX ERGO。
同样是手腕问题换了人体工学或分体式键盘，之前用微软的人体工学键盘，后来办公桌子小，就换了 UHK 分体式键盘。
对蓝光屏蔽产品保留怀疑态度，如果感觉不适，请看医生，另外建议将重点放在健康的工作习惯上，比如定时休息一下，之前用了个喝水 App，定时提醒喝水，形成习惯的话也挺不错的。

从小学三年级开始基本上是每天玩 6 小时电脑，作为一个曾经的“熊孩子”想说，“网瘾”只是表面现象，实际上还是得从孩子生活状况上找原因。

之前看过一篇文章讲从事游戏制作行业的家长是如何对待孩子和游戏的，感觉说得非常有道理，感兴趣可以看看 https://zhuanlan.zhihu.com/p/37910229

@Kagari 我的意思并不是说 WiFi6 技术实现上有难度，我的答案也一直都是围绕市场经济供求关系来说的，这是关于市场策略的问题。

会打纸牌的人都知道“俩王带四个二”的问题，核心在于战略资源的利用效率。

设备厂商每年都有 KPI 要完成，假设 2020-2021 年的 KPI 靠 5G 来作为主要市场策略，促使消费者换一批设备，预计可以达到近两年的 KPI 要求，那就没必要引入额外卖点，没准到了 2021 年 5G 市场达到饱和，2022 年销量开始下降，那么 2022-2023 年的 KPI 还可以靠 WiFi6 作为主要卖点来完成。可能技术和成本上厂商完全可以在 2020 年就和 5G 一起推出 WiFi6 特性，但一方面市场需求小、面向 KPI 的而利用率低，另一方面发现两年后没有新卖点来冲销量了，继续做 5G+WiFi6 难以让前两年买了产品的消费者再掏腰包。

一个典型案例就是“牙膏厂”Intel，技术早就成熟了，就是不上市，有计划地、持续地让消费者掏腰包。

我这些也都是预测，未来没有人说得准，要是还是无法理解，可以随时了解一下市场情况。

如果是当地人的话，酒、茶比较有地区特点，可以打听一下当地人比较钟爱的酒、茶种类。
渔具确实太具有专业性了，而且针对不同水域、不同鱼有不同的渔具，要是是在不了解也不要勉强，买错了比较尴尬。
再找些礼盒装的零食饮料，附近买点水果啥的，凑个 4 样以上就差不多了。

关键点还是在于见面，过年的话免不了见其他亲戚，建议提前做做功课。

运行肯定是可以运行的，功能也能满足要求，ESLint 规则只是建议，并不一定代表程序一定有问题。

动态 require 的问题可能有：
1. 如果你用 Webpack 等打包工具分析代码依赖的时候，无法妥善处理动态 require 的代码，只能处理静态引用。
2. 如果引用的文件有被替换或篡改的可能性（如上传功能），或如果引用的路径有被篡改的可能性，那么在文件第一次被 require 之前，可能会被攻击，并最终导致运行恶意代码。

暂时想到的只有这么多，如果你的使用场景不具备以上风险的前提条件，就可以用。

如果用户体验对公司运营目标有影响的话，那么 KPI 的制定应该包含用户体验相关指标，如果没包含的话，说明 KPI 的制定有问题。

但假设 KPI 的制定是合理的，此时没有包含用户体验相关指标的话，就说明用户体验对于公司运营目标没有影响。

创业公司的创业阶段绝大多数靠投资吃饭，投资是有烧完的一天的，所以要在投资烧完前达成承诺投资人的各项目标，履行承诺的同时公司可以盈利，或者让投资人看到发展前景愿意继续投资。所以有取舍是必然的。

楼主直接拒绝个人认为是错误的决策，不利于自己和公司的发展，如果可以的话，建议做一些调研，以论据说服 KPI 的制定者考虑用户体验，或者让自己理解当前用户体验确实不重要。

都比 8400 性能高很多，选哪个都行，看你的场景是核心密集还是主频密集的，主频密集的话这两个差不多买便宜的，核心密集的话买核心多的。

个人一直都觉得 UA 不可靠，支持使用可靠、安全的方式来检测兼容性，不过浏览器厂商有点不尊重开发者。

@Kagari 5G 基站是国家任务，这个不受市场经济的控制，反而 5G 基站的普及会促进 5G 手机以及相关生态的市场增长。
而 WiFi6 路由器的购买是个人交易行为，遵循市场经济供求关系的原理。

简而言之：运营商建 5G 基站是不在乎花多少钱的，但你买 WiFi6 路由器是在乎的；两者不能一概而论。

WIFI6 还没普及，最近 WIFI6E 就出来了。

网络设备的市场需求主要来源于相应通信技术的终端设备的普及程度，所以得看应用相应技术的手机、电脑、电视等终端设备什么时候成为市场主流。

现在手机厂商的主要精力是完成 5G 任务，5G 预计两年内完成普及，之后才会有精力搞 WIFI6 等其他技术，所以可能 WIFI6 的普及还要等 3-4 年。目前的情况是，华为、小米、Oppo 旗舰机还没有 WIFI6，iphone 仅 11 系有 WIFI6 ；等中端手机标配 WIFI6 的时候，相关网络设备的价格应该就比较便宜了。

Assembly 就是汇编，往往代表直接以机器码形式呈现的程序，你可以想想以往的汇编语言的特点是什么，WebAssembly 是在浏览器端（严格来说是引擎端）的一种具备汇编特点的技术。

举个例子：浏览器上往往只支持 JS、CSS、HTML 三种语言，这些都是以源码的形式由浏览器实时解释运行的语言，浏览器内部实现了这些语言的语法、API 的细节，对计算机底层机器码进行了功能上的封装，特点是人类友好、性能较差；而 WebAssembly 是直接运行机器码，虽然是在 VM 或沙盒上运行的，但开销极低，特点是人类不友好、性能较强。

实际上用 WebAssembly 来做开发也不是直接写 WebAssembly，依靠 LLVM 编译器的强大功能，可以将很多语言的程序编译成 WebAssembly，比如 C/C++、Rust、C#/.Net 、Java、Python、Go，以往 C 语言是直接编译成机器码跑在硬件或操作系统上，WebAssembly 可以让 C 语言编译成 WebAssembly、转化成 WebAssembly VM 或沙盒机器码运行、VM 或沙盒在硬件或操作系统上，由于中间 VM 或沙盒的开销极低，所以可以让程序的性能与直接跑在硬件或操作系统上相近。

既然是 Web 开头的技术，那么还有一个很大的特点就是可以和 JS 互操作。

应用场景基本就是在浏览器端有强性能需求的场景，比如 AI、视频编解码器、图形引擎，或者仅仅是想把桌面软件迁移到浏览器上（ AutoDesk 将 AutoCAD 迁移到了浏览器上）。

从目的出发，根据写日报的目的来决定怎么写。

1. 上级需要了解团队发生了哪些事情。工作往往是一线员工做的，在工作过程中可能会发生外部的、内部的事件，这些事件有可能会对团队里的人员、项目产生影响，而这些事件和影响又是领导必须掌握的信息，以这些信息支持领导对团队的管理工作。就像打即时战略游戏一样，玩家总得时刻注意所有单位的动态来实时调整决策。这时候可以重点描述当天发生的所有事件。
2. 项目管理。有的团队会使用一些员工半自治的项目管理模式，比如敏捷，当具体的目标或需求下达给员工的时候，员工需要自己根据难度、量级、优先级、预期完成时间等独立安排工作计划；此时领导的职责更多在于项目进度的跟进、疑难问题的解决、资源的调控。有些团队是用一些工作流软件来做的，如果用日报的方式来做的话，就重点写 Done\Doing\Todo，以及出现的问题、Delay 的风险。
3. 绩效评定。领导希望根据日报来判断哪些员工做的工作比较多，哪些员工效率太差（或者有摸鱼嫌疑）。这种只要你踏实工作，将工作内容、所花时间都写出来就可以了。
4. 搞形式。这种就看领导怎么喜欢怎么写就好了。
5. ……

Tor+Tox

个人感受 Go 是一个完全贴合工业化软件生产的语言，提供的特性精简、直达，让任何需求都有尽可能少的方案来实现（只有 1 种方案的话就不需要纠结了），让开发者将精力放在业务本身，把业务之外的问题都透明化解决。

所以某种角度上来讲，“简”是 Go 的设计哲学之一。

以上个人感受，不同人可能会有不同的感受。