最近刚看完 Rust 的教程 ，不知道以后能不能用 Rust 写微服务。

BFF 通常只对数据进行聚合和初加工，分布式事务确实也没见过在 BFF 里做的。

前端组长有责任出面跟后端小组商定架构划分规则，什么功能应该由前端来做，什么功能应该后端来做；前后端耦合严重的话，会极大提高维护成本。

最有名的引擎就是 Unity 和 Unreal ，挑个喜欢的直接上手就行了，碰到什么就学什么。

Go 是拿灵活性来换取生产效率的，特性少会使得实现方案少，当一个需求每个人的代码风格、实现方案都一样的时候，可以避免团队合作的很多问题。

Go 是一款用于精准解决企业生产问题的产品，不适合用于满足个人对技术方面的追求。

有没有价值不是看技术前景如何，主要看能不能盈利，还是得从公司经营业务方面去考虑。

从需求出发：
1. 用户不希望做每个操作都进行登录验证操作，所以需要让用户会话有一定的有效时间；
2. 用户不希望在长期不做操作的情况下，比如离开电脑前，甚至电脑交给他人使用的时候，会话仍然有效，以至于可以被他人操作，所以用户会话的有效时间不能太长；
3. 用户不希望自己正在使用的时候会话突然过期，所以需要在用户会话过期之前，如果用户还有操作的话，就对会话续期（刷新）。

题主疑问 2 里面说的“有人说”的观点是错误的，安全性都是相对的，没有网络通信安全和客户端安全作为保障，token 机制不管怎么用都是无法保证安全的。

数据库的查询和索引机制是跟 key 强相关的，你可以去直接问 MongoDB 官方试试看有没有什么隐藏方法可以实现需求，个人经验来说，大多数据库从原理上都不支持这么做。

没碰过混合硬盘，希捷酷鱼和酷狼用了很久，质量也还好，同期也用西数红盘，两者都挺耐用的（不过西数红盘是叠瓦盘），不知道希捷酷玩这个系列是不是本身就有质量问题，以及题主是不是遇到了假货，硬盘买到次品、翻新、假货应该也不罕见。

另外常规硬盘都是分普通、专业存储、监控几个大类的（企业级产品先不谈），监控没有容错不推荐非监控用途，大多家用 PC 用普通盘，用于 NAS 等对可靠性要求较高用专业存储盘。

希捷和西数类别对应大概是：
普通盘：希捷酷鱼、西数蓝盘；
专业存储盘：希捷酷狼、西数红盘；
监控盘：希捷酷鹰、西数紫盘。

其他的系列基本上都是根据这几个大类来做细分产品；比如题主用得不少的希捷酷玩，就是普通盘大类下的混合硬盘产品；西数绿盘也是普通盘大类下的节能型产品。

看题主的截图我比较纳闷，商品名同时出现了“酷鱼”和“监控”，不知道是不是拿监控盘冒充的普通盘，或者是残次批次有质量问题只能用作监控用途。

"key3":{$exists:false}

MongoDB 虽然可以插入任意结构的 document ，但是是在数据库操作本身不大关心 document 结构的基础上的，否则还是要有一个统一的 schema ，至少能清楚最多有哪些字段，你根据 schema 来梳理出不想要的字段，在查询条件里标明要求这些字段不存在的 document ，就可以了。

@libook #26 勘误：
JS 有个核心特性叫做原型链，对象值复制跟原型链的思想是矛盾的，前者希望尽可能复制代码，后者希望尽可能复用代码。这也就导致在 JS 里做深拷贝不那么方便。

JS 这种高度抽象的语言的设计初衷之一，就是让使用者不需要去考虑内存细节，所以赋值操作，对于简单类型是赋值，对于复杂类型是引用。

仅针对题主的例子，不考虑其他情况的话可以这样写：
let b = Object.assgin({},a);
这行代码的意思是把 a 里面的所有成员拿出来，一个一个地赋值给 b 的同名成员，这个赋值操作和等号的赋值操作一样，同样是简单类型赋值、复杂类型引用。因为 Num 是简单的数值型，所以执行了赋值而不是引用，导致修改 b.Num 不会让 a.Num 发生改变。

但如果 Num 的值是一个对象，因为 b.Num 和 a.Num 引用的是同一个 Num 对象，所以修改 Num 对象内的成员后，读取 a 和 b 内的 Num 对像会发现发生了变化，此时如果还需要进一步的值复制，就需要深拷贝。

如果对象是简单的、可以用 JSON 描述的对象，比如不含有 getter 、setter ，没用 Symbol 字段名、没用非 JSON 数据类型等，那么常用的方式是 JSON.stringify 序列化再 JSON.parse 反序列化，完成一个深拷贝。这个在本来就在上游使用 JSON 的场景用得很广泛，比如 HTTP 通信。

JS 有个核心特性叫做原型链，对象值复制跟原型链的思想是矛盾的，前者希望尽可能复用代码，后者希望尽可能复制代码。这也就导致在 JS 里做深拷贝不那么方便。

有不少第三方的 deep clone 库，可以拿来直接用。

普通需求场景下，基本只会用到几个核心指令；
有更复杂需求的场景下，基本都会用 alias 、写脚本、工具、shell 插件。

社区驱动的开源项目往往会朝着符合社区用户的需求方向发展，git cli 发展成这个样子，对社区来说是具有必然性的。
题主觉得不合理，可能题主的需求场景和社区用户的普遍需求不一致，那么可以考虑加入社区做提案，或者自己做一个新的 cli 。

因为文件夹本身没有大小，文件夹的大小取决于文件夹内的文件大小只和，如果有子文件夹，还要递归计算子文件夹内文件大小只和。

除非有一种文件系统可以对每一个层级的文件夹大小进行预结算，并缓存；否则当遇到包含很多文件的文件夹，实时计算大小将耗费大量的 IO 读取时间。

操作推荐 cli ，分析版本历史和 diff 推荐 gui 。

git 自带 gui 工具，分别是 git gui 和 gitk ，能应付大多使用场景了，其他的就是具体看团队 git 工作流方案是什么，然后再去看是否需要借助一些 cli 或 gui 的工具来提升效率。

如果是推广帖的话请发到推广栏目。

以前租房一年一搬家，基本都是直接用记号笔在箱子上写分类；或者提前规划物品摆放位置，按照预期摆放位置分类装箱，箱子上直接写放到哪。到目的地开箱，拿一件就现场规划摆放一件，直到箱子拿空，所以也基本也不需要搜索，只要打包没漏东西，就一定能在开箱后遇到。反而新摆放的位置更需要记忆。

要想细致也可以考虑拍照，每个箱子一个相册，物品先拍照再放进去，等找的时候直接就相册网格视图找。就是不能搜索；但是东西少就用不着搜索；东西多录入需要花很长时间和精力，也不一定高效。

当前的加密货币并没有真正发挥货币职能，更主要是用来作为金融工具，结合价格走势进行买卖操作，来赚差价（割韭菜）。

由此让加密货币具备了价格，通过购买电力和硬件来挖取加密货币，再将加密货币换成法定货币，当价格高于成本的时候，挖矿行为就具备了一定的利润价值。

简单来讲整套体系就是没有新的价值产生，资本从一部分人手里转移到另一部分人手里，代价就是消耗能源和硬件资源。

从个人来讲，挖矿、炒币不是目的，最终赚取法定货币才是目的，这点跟股票等其他金融工具是一样的。

从国家和社会来讲，挖矿消耗的能源和硬件资源，主要不是直接或间接地用于或促进生产资料的生产，可以看做能源和资源浪费，这点跟其他合法金融活动是不一样的。

光标大范围移动触控板也是可以胜任的，一个手指按住另一个手指移动即可；至于精确方面确实得看手感。

我用了五年 MacOS 了，到现在都觉得快捷键、文件管理、窗口管理都不如 Windows 符合我的直觉。

很多功能有快捷键，但没有相应的按钮。
比如文件的复制粘贴只能通过快捷键来实现，靠菜单按钮的话需要分好几步骤（复制为副本、移动、重命名删除“的副本”）；
窗口不直接提供“最大化”，经常在查看 PDF 的时候希望能有更大可视区域，同时又希望能随时观察到 Dock 和状态栏，就只能按住 Option 再点绿色按钮来实现“最大化”，有的软件还不支持这种最大化方案，只能用鼠标自己拖尺寸；

Windows 的快捷键有比较明显的分类逻辑，且应用程序的标准比较统一，Mac 下可能不同程序的标准不同；而且对我来说单词比图标更容易记忆，我现在记 Mac 下的快捷键也是得把图标翻译成按键名称再记的（可能我不擅长形象记忆吧）。

可能 MacOS 上也有些奇淫技巧可以根据使用习惯来优化，但毕竟不算开箱即用的体验。

不过 MacOS 触控板确实好用，不知道现在 Windows 超极本体验是不是也追上来了。

我们正式员工也没有生产环境的只读权限，顶多在 ELK 里看监控和日志。

而且数据安全法和个人信息保护法开始实施了，生产环境数据的访问限制只会更强。

安全和便捷从来都是矛盾的，企业到一定规模后，安全需求的优先级自然而然就提高了。

我所在的圈子有两大邪教，一个是 Go 吹，另一个就是 PG 吹，所以我们公司前两年时间被这帮人全面换技术栈了。

连捧带踩的这种宣传手段其实近几年挺多的，都是疯狂踩某项技术，然后引出要宣传的技术狂吹一番，制造恐慌。

我是觉得技术选型不是什么火用什么，撑到现在的关系型数据库在应付常规业务方面都是没问题的，所以什么顺手用什么就行，只有真正遇到了跟选型强相关的问题，再决定是否要转换技术栈，然而不同需求、不同情况下遇到的问题往往是不同的，在真正运营之前也是难以预测的，所以选型也没有银弹。