在 V2 上发这种入门级别的对比文可能会被喷惨，楼主保重。。。

如果希望讲技术差异，可以遵循 STAR 法则，讲具体的例子，这样更客观一些。

前端环境应始终是不受信任的，所以任何敏感信息不要放在前端。

完全不清楚你的 Token 是用来做什么的，为什么不用账号密码反而用 cleintid 和 clientkey，Token 和 clientid/clientkey 到底是什么关系，这些需求背景你得讲清楚，大家详细了解到你想做什么才能帮到你。

如果只是希望在前端存一个东西，且不希望别人知道内容，但同时希望服务端能知道内容，可以用非对称加密，加密后把密文存在前端，服务端解密后读取内容。但这个很可能不适用于你的安全场景，因为获取 Token 不需要知道密文的原文，只需要把密文发给服务端就可以拿到 Token 了。

没有强需求的话建议不要换平台，Mac 的触摸板是好用，但是如果你的工作不是重度依赖触摸板的话没必要因为这个换平台。因为长期用鼠标和笔记本的键盘，我有手腕疼痛，触控板对于我来说会加重手腕疼痛（因为手腕长时间吃力），所以至今为止用了很多年轨迹球，多桌面切换也是通过外接键盘的快捷键来实现的，除了拿电脑去会议室的场景，很少用触控板了。

我在 Mac 上的强需求一是 MacOS 的开发工具兼容性，二是续航，Mac 在这两个方面在 2016 年的时候是杀手级别的。

但如今除了底层开发以外，Windows 上的 WSL 也已经非常好用了，想在 WSL 上跑图形 Linux 软件可以参考这个：
https://github.com/libook/WSL-GUI

新款 XPS 据说续航也非常强，我觉得综合来看和 Mac 可以平起平坐，现在苹果的创新几近枯竭，差距已经远没有以前那么夸张了。

当然如果你经济条件比较好，愿意做新的尝试，也可以用一用 Mac 。

https://github.com/shimohq/chinese-programmer-wrong-pronunciation

英语发音其实没有真正的标准，不同口音可能听起来很不一样，当然最好的是跟各个口音的人用他们的口音交流，但即便是学会一种地道的口音都很难。。。

语言是用来交流的，只要互相能听懂就行了，但如果因为发音错误导致了误解，相互探讨一下发音问题也是可以的。

出现问题或确定会出现问题的时候再考虑优化，把精力放在当下最重要的事情，如果实在没有事情可做，就对自己的系统做压力测试、可用性测试、边界测试，提前发现些问题，再根据问题的影响排优先级，从高优先级的问题开始解决优化。

如果代码可读性上有问题，就适当调整代码结构、增加注释，少用些奇淫技巧，少偷懒。

ES 和传统意义上的业务数据库不同，它其实是个搜索引擎，存储功能只是其为了更好提供搜索功能而包含的附属功能，但在实时性和一致性方面远不如业务数据库。

比如 ES 写入数据后不能马上被查询出来变化，必须等 ES 的刷新周期对索引完成刷新后才能搜索出来变化，实时业务上通常无法接受这种不一致。比如用户一开始有 100 元钱，买了产品后向 ES 请求扣除 80 元钱，紧接着用户查询余额就还是 100 元，于是用户可能又购买了一次 80 元的产品。如果硬上 ES，肯定要做大量的工作在最终一致性上。

那么 ES 的用武之地在哪呢？全文检索。
举个例子，比如你有一个查询表单，里面有 20 个字段，功能需求是用户只需要至少给定任意多于等于 1 个字段就可以进行查询，如果使用业务数据库的话，查询性能完全依赖于索引的设计，但是对于上述功能需求来说，由于用户可能使用任意字段的组合来进行查询，20 个字段就需要设置从 C1,20 到 C20,20 的所有组合的和这么多的索引，由于多数数据库都是索引越多写性能越差，所以基本不可能使用索引来达到最佳优化。
ES 以其特殊的数据结构和查询算法能够非常轻松地解决这种问题。

所以看你们的使用场景是怎样的，对数据实时性是否有要求（只要是不查最新数据的场景都是可以的），如果仅仅是看重 ES 的横向扩展能力，虽然 ES 这方面做得确实很棒，但放弃其他指标的代价有点大，而且其他业务数据库合理配置也能达到同样的效果。
如果是清洗数据的需求（比如对数据格式进行转化或计算，再灌入数据仓库或业务数据库），可以考虑一些 ETL 方案。

最后就是也可以考虑业务数据库和 ES 同时使用，数据以业务数据库为主，复制一份放在 ES 里，根据查询需求的不同可以在不同的地方查询，当然肯定是需要确保 ES 和业务库的最终一致。

AMD 盒装自带散热器据说不错，所以玄冰 400 可以先不买，看看发热情况。

以后可以考虑再添置烘干机和洗碗机，个人使用觉得极大提升了生活品质。

电视本身就是比较贵重的电器，国产电视很多是走低价带广告路线的（看国内什么时候能完善监管吧），无广告的一般价格都比较高，看自己需求。

空调，一开始选了海尔，结果购物体验很差（预料中），经历了退货风波；后来换了美的，感觉所在地的售后服务不错，一级能效的也不贵。另外海尔和美的的空调基本上就是那几个模型，只是外观和附加功能可能有细微差别，所以基本上就按照匹数、能效确定了之后性能上不会有多大差别，其他的就看尺寸、功能、外观和价格了，需要说明的是一定要确定安装的地方尺寸足够，因为空调在本身尺寸基础上还要有一定的安装空间。

电视、冰箱、洗衣机我买的是进口货，一方面有明确需求，另一方面预算充足。

新房要想能住，最基本的洗衣机、热水器、冰箱是一定要有的，其次夏天需要空调，然后电视如果没有硬需求的话在预算不充足的时候可以延后。如果做饭的话前期也要考虑烟机和灶具（因为咨询线上销售的型号而受到了门店的歧视，“老板”果然店大）

热水器我个人对比了一下海尔和美的（史密斯太贵了），感觉海尔溢价过多，最终选了美的。

每个人有自己的选择，我说一下我的原因吧：
租房年年涨价年年搬，偶尔房东耍流氓卖房想提前收回（为了更容易卖），或者管家闯进来拍拍照啥的；
产检，以及小孩各种保健检查、上学和社交都大大提升了搬家的难度。

当然你如果租房租得很爽，也不打算生孩子，没必要买房。

贷款还 25 年，每个月还贷额度不能高于你申请贷款的时候的收入的一半，随着个人职业生涯的发展，你工资总不会一直不变吧，要是预期还不上人家银行也不会贷给你。剩下的就是保持健康、不失业。

有需求买就好了，没需求就不买。建议投机和需求分开，要投机就别想需求的事情，有需求就别老想着投机。
按照实际情况合理规划。

“账号不存在则自动注册”

@devcat 其实想想，是不是没必要整个 Desktop 都搞出来，Windows 上的 X Server 有一种模式是无缝的，就是让 X 程序界面像普通 Windows 窗口界面一样和其他 Windows 窗口混在一起用。

通常用第三方的轮子觉得有问题或满足不了需求会提 Pull Request，如果第三方轮子实现不了，或是阿里系的轮子，或没有对应的第三方轮子就自己造。

一个原则是：社区维护的轮子因为经受了更多的检验，通常比自己造的稳定、高效。

所以到现在自己造的轮子屈指可数，但是 Fork 和 Pull Request 比较多。

补充一下，当前技术是多元化发展的，而且在诸如云原生等概念的推广下，系统的非业务部分逐渐被各种中间件、基础设施来实现，如横向扩展、通信可靠性、服务容灾、削峰填谷、优雅降级、灰度发布等等，让代码更专注与业务逻辑，以提高企业变现能力。

如果一个架构师说架构只能用 Java 做，那基本上说明这个人还没有成为真正的架构师。

架构师的工作中有一项叫做技术选型，需要架构师具备广泛的知识储备，以及可靠的技术雷达，当遇到一项需求的时候，能够合理分析，选择适合需求的技术来实现。

所以当今只要是上了一定规模的系统，都是由多种技术栈组合而成的，举个例子：某企业业务逻辑部分用 Java，高性能组件用 C++，微服务是 Go，API 网关是 Node.js ，大数据分析是 Scala 和 Python 。物尽其用。

技术都是工具，虽然每个工具的功能都比较丰富，但是工具总是有其擅长的领域，所以得从实际需求出发，合理选择技术。

除了需求本身的特性以外，架构师还要考虑现有的技术包袱、人员的能力、管理成本以及未来的规划，比如如果团队里综合最熟练的只有 Java，而且用 Java 也不会带来高成本或高风险问题，那也是可以考虑整体全用 Java 的。

架构其实就是解决问题的思路，比如说 MVC，并不是特指的只能用 Java 来实现的架构，而是一种通过将系统抽象成 Model 、View 、Controller 三层来实现一种动态的程序设计，使后续对程序的修改和扩展简化。需要说明的是，MVC 是 1978 年提出的，而 Java 是 1995 年发行的。

所以可以说 Java 以其悠长的历史、广大的社区、丰富的案例储备，能让人了解到和学习各种架构。但是也并不是说离了 Java 就没法谈架构了，你看，前端工程师近几年也在架构上玩得 66 的（阿里云已经实现前端微服务架构了，用于解决云控制台大量模块和技术栈混合的问题）。

不管用啥，最重要的是防止凭据被伪造，不加密、弱加密不管用什么技术都有安全风险。

Token 的优势在于不依赖浏览器标准，任何非浏览器客户端也可以轻松使用，比如 App 端，处理 Cookie 的时候复杂度往往比较高，用 token 简单明了。

Cookie 的优势在于有浏览器标准的支持，很多功能不需要自己实现，只要浏览器按照标准设计，就能直接使用 Cookie 的特性。

Token 本身不包括存储技术，客户端希望保持会话的话是需要自己提供机制来存储 Token 的，在浏览器端可以用 Web Storage 来存储，在 App 端可以直接存在本地数据库或文件里。

传输方式上：Cookie 是封装好的、在 Header 里传输的方式； Token 可以自己封装用 Header 里的某字段来传，也可以直接在 URL 里传，比较灵活。

然后因为 Cookie 广泛用于用户数据追踪的技术，所以国际上通常要求在用户同意的情况下使用 Cookie 。

4 没用过，不知道性能是否提升到足够用于更多用途了。

个人基于 3B 的使用体验来看：尝试过 Nas 、办公电脑、电视盒子等，性能完全达不到使用需求；觉得还是只适合 RetroPie 和 GPIO 开发这两个用途，服务器方面只适用于极度轻量级以及对 ARM 兼容好的场景。

建议有需求再入，而不是入了再想找点什么需求，更别说大多认为有需求而入了树莓派之后最终还是很快吃灰。

我们在用，不过确实用得不多，主要是因为将成员私有化这个需求本身就比较少出现，而且利用局部变量往往也可以达到私有化的效果（比如闭包）。

这个就是个特性而已，没有需求就不用，有需求能想起来用就行。