Linux 发行版好比是攒 PC，可以根据需求选择不同架构、厂商、型号的组件进行组装；此外，你还可以对各种组件魔改，比如刷固件、短接飞线、替换元件、拆掉散热片改水冷、布置 RGB……

Linux 生态绝大多数项目都是在 GPL 许可之下的，开源可修改，人们基于不同的需求、使用习惯、技术观点，对内核、驱动、服务再到软件等等进行调整，最终形成各种各样特色的发行版。

实际上一种发行版到了用户手里，用户也是可以折腾替换和配置各个组件的，只不过维护团队不一定推荐这么做。

众多发行版中，有企业、基金会管理的，也有社区成员自发维护的，根据维护团队的规模、工作强度、技术水平，有很成熟可靠的发行版，也有不那么稳定的发行版。

@wellhome 这个不同项目都会有不同的情况，比如需要热插拔一些 Jar 依赖包，或者依赖一些系统动态链接库，再者就是需要特殊的定制的 JVM 和启动参数来运行 Jar 包，还有日志采集、性能监控、持续部署工具……不清楚是否都能打包到一个 Jar 里。

容器是一个工具，工具是为需求服务的，有需求就可以考虑用，没有需求就没必要用。

通常来说，商业用途必须用商宽，比如公司只能办理商宽。
商宽通常是上下行对等、独立 IP 。

具体参数得跟销售谈的，不同地区可能会不大一样。

GOG 就是蠢驴自家的平台，在其他平台可能还要给平台方分成，所以想支持蠢驴的话建议 GOG 上入。

当然，如果其他游戏都在某一个平台上的话，就都在一个平台上买就好了，好管理，不过 GOG 的客户端有管理多平台游戏的功能，就看你觉得怎么搞方便了。

绝大多数的职业，要想提升自己的专业能力，都是需要持续学习的；即便是种地，要想提高产量、降低风险、提高农产品经济价值，同样要涉猎植物学、生物化学、地理学、管理学、经济学……

只不过计算机相关技术发展比较快，像服装工艺上可能数年才会有新的技术出现，但计算机相关领域会把这个周期缩短到一周。

框架会帮你解决多数常见问题，但是用得深入了，遇到框架解决不了的问题了，你就得用基础知识去改造框架或者另辟蹊径。

基础知识和实践知识缺一不可的，当然一个人不可能把所有知识全学会，但可以有一棵知识树，从计算机组成原理出发，软件和硬件就可以分出两个分支，然后每个节点又可以继续分支；你学习的过程其实就是在不断为自己的这棵计算机知识体系的树添枝加叶。

所以过去的知识（基础知识）要不断地补，这些知识可以在你学习表层知识的时候更加得心应手；最新的知识也要了解，为你解决工作中的问题提供更多的思路。

有些知识，我知道有这个东西，也知道大体上是用来解决什么问题的，但我目前用不到就先不深入了解，等以后遇到问题了我能想起来有这么个东西可能可以作为解决方案，这时候再深入了解就行了。

如果你觉得你现在学的东西没有用武之地，那说明你自己的成长已经比工作业务成长要快了，这是个好现象，意味着你具有更多的主动权来换工作，总比有的人感叹的因为工作业务发展慢导致自己发展慢要强得多。

最后，既然看了很多东西，就要懂得归纳整理，学一个新的框架不只是学怎么用，而是要了解其思想，而思想是可以跨框架、跨语言、跨领域的，思想积累多了，很多同质的框架就可以看做一种了，而且可能也具备了解决框架解决不了的问题的能力。

只要设备上不安装公司的证书，你走 HTTPS 就不会受到中间人攻击。

小米那个事件是反向代理，即把公司内部端口映射到了公网，访问是从外发起到内部的，会使得内网资源遭到外网攻击；正向代理是从公司内网发起到外网，只要你的通道不会被用来从外网进入内网，就不会有这种风险。

规定就是规定，如果规定不合理可以提建议完善，但既然规定在施行就得准守。

直接返回 302 最简单。

先做个 MVP 方案出来，根据实际使用中遇到的问题再做优化就好。

JS 不只有 Array 一种数组，还有很多，比如 ArrayBuffer，虽然不一定满足你的需求，但是很多特殊场景都可以覆盖到了。

用 JS 写链表，就好比是在手枪上装了个高倍狙击镜，并不能达到预期的效果，所以如果团队内有人这样写，我会让他要么改回原生数据结构，要么拿 Rust/C++重写。

JS 跑在引擎上，引擎给 JS 语言提供给的内存空间是抽象的，真实反映在操作系统内存管理上可能是连续的也可能是不连续的。像 JS 的 Array 底层引擎实现可能是多种模式动态切换的。
操作系统给引擎提供的内存也是抽象的，真实反映在物理内存上可能是连续的也可能是不连续的。

在如此高级抽象的语言上考虑算法性能是不可能有定论的，因为可能每次运行的时候情况都会不一样，控制器芯片、操作系统、引擎也都会对一些常见情况做优化，这个是在语言层面无法把控的。要是真的在项目上要考虑性能问题，可以做宏观的压力测试，有问题要解决大多也都是在系统架构上优化，语法算法上的优化余地不多。

用 JS 不看性能，看性能不用 JS 。WebAssembly 以及 Node.js 的 N-API 主要就是用来解决这个问题的。

@wellhome 看项目情况吧，能打成 1 个仅依赖 JRE 的 Jar 部署就很简单；但是如果因为某些需求不能打成一个 Jar，以及涉及到复杂的环境配置，部署难度就有可能比较高。
传统的运维架构能满足需求的话可以不用容器，如果希望使用云原生带来一些好处的话（比如时效和成本），就可能得用容器。

比如 Go 完全可以编译成一个可执行文件，但如果希望使用云原生的方案来满足集群访问控制、优雅升降级、容灾等需求就还是得套个容器，因为云原生设施管理服务的最小单位就是容器。

如果对容器没有需求的话，就没必要用。

Go 的简单在于一种功能往往只有一种实现方式，可以将更多的经历放在业务上，而不是思考各种实现方案上，团队中有技术很烂的人也不至于写出太烂的代码。所以目前看来是比较适合企业团队生产的。

Go 出来这么多年，初期几年人们大多都在喊口号，说 Go 怎么怎么好，但真正学了、用起来的很少，也就是最近三年才有越来越的的企业项目用起来。新语言肯定不如老语言资料和轮子那么多、全，这方面 Java 几乎是无敌的，毕竟沉淀了二十多年了。用新技术你就只能多看官方文档、多提问、多看源码。

具体遇到了什么问题可以发出来让大家帮忙解决，只是抱怨的话不会有任何积极意义。

话说回来，用了很多年 Node.js ，因为都是 JS 技术栈的，所以对接前端、对接 MongoDB 都很顺滑，性能多数情况下表现也不错。现在微服务大行其道，一个项目也不一定完全使用一种语言来开发。

Java 项目部署普遍比较麻烦，容器是解决这方面问题的一个有效方案（简直为 Java 栈量身打造）。

学历问题不大，企业关键能不能按时保质保量出活，以及未来是否能出更多的活。

不过和所有非本科科班出身的人一样，我一般都建议把计算机基础打扎实，对你今后技术能力的提升会有很大帮助，你可以去看看本科计算机科学与技术专业都学哪些课程，然后看书自学，有一个计算机知识体系的宏观了解。

然后再根据自己从事的专业领域深入了解，比如 ECMAScript 标准、HTTP 标准、WebAPI 标准、各种后端架构思想、中间件、数据库、Linux 操作系统等等。

简历要用心写，不知道怎么写可以参考 STAR 法则，最好是能够按照不同企业的招聘要求定制简历投过去。

面试也要揣摩面试官的提问意图，有些东西不知道就说不知道，但要表现出有学习能力可以快速掌握。

最后招聘和求职是双向选择，很多时候没被录取不一定代表你很差，可能仅仅是因为不合适，但你自己要对每次面试的情况做反思，对自己进行查缺补漏，让下一次面试更加顺利。

任何技术都是有需求就用，没有需求不要硬用的。

建议先了解一下微服务可以解决哪些问题，有哪些使用的前提条件，如何解决问题；然后根据项目实际情况来决定要不要使用微服务思想。

微服务是一种思想，不是一种特定的代码结构、算法、标准，所以只要应用了微服务的特性来解决微服务擅长解决的问题，就可以称之为微服务。

就好比前端开发，我只想写一个没有任何交互的展示内容的页面，用 Vue 、React 是完全没必要的，至多用原生 JS 加些效果。

为了提升代码可读性，也为了让 IDE 更准确识别对象结构，可以考虑把动态添加的属性做成确定性的，比如声明的时候就包含这个字段。
用注释写好 JSDoc 、ESDoc，把具备哪些属性写清楚。
或者使用 TS 的*.d.ts 文件（ JS 项目也可以用），和上面方法一样都是让 IDE 知道对象有哪些属性。
如果是公共库的话，可以在 Preferences =》 Languages & Frameworks =》 JavaScript =》 Libraries 里添加相应库的声明文件，实际上和用 TS 的*.d.ts 是等价的。很多人用 idea 一开始写项目连 Node 内置 API 都会有波浪线（ WebStorm 可能不会有这个情况），需要在 Preferences =》 Languages & Frameworks =》 Node.js and NPM 里勾选 Coding assistance for Node.js 。