采集卡？

此回复不讨论时事。

个人认为，有效的沟通是一件比较麻烦的事情，但在工作或生活中，为了达到自己的目的，不得不去思考如何表达才能按照自己的预期来影响他人，甚至要在沟通的过程中不断对对方当前的心理进行识别，并同步思考下一步如何表达可以推进沟通结果朝着自己预期的方向发展。

而互联网上讨论问题，大多不是些重要问题，所以对大多人来说，没必要投入过多精力去精心进行每一次沟通过程，那么剩下的就是简单的沟通方式，直抒胸臆，甚至不去求证自己是否正确理解对方要表达的意思，进行主观臆断。

当互联网上的讨论升级成了争论，在争论双方都认为自己站在真理或正义的一方的时候，做出攻击性行为会使得自己获得心理上的满足（可能是某种本能吧）；那么有时候争论的结果就变得不重要了，获得满足感成为了首要目的，达成目的后，维持这种“胜利”不被推翻的一个很低成本的方式就是拉黑。

造成题主所说的现象的，可能不是因为人们了解信息不够多和全面，因为遇到不了解的信息是可以自主去了解的；这些现象，更可能是因为人们在不重要的沟通中，不愿意承认自己了解的信息不够多和全面，实际上就是不愿意降低姿态承认自己的不足。回想起来，“三人行必有我师”这种观点还真是只有圣人才能以身作则的。

曾经有过笔记本厂商同时提供外接散热器产品，但这是小众需求，企业为了利润最大化通常不会在这些小众市场上投入太多资源。

外接显卡也是小众需求，所以相关产品并不多，而且显卡坞也并不是所有笔记本都兼容的。
外接显示器在办公领域需求还是很大的，而且技术成熟、成本较低，ROI 较高。
外接电源是提高笔记本裸机便携性的必然选择，之前也有大牌厂商做过可以接多个电源以提高功耗墙的笔记本产品，虽然这个需求也比较小众，但是无非是多卖一个原装电源而已，不需要对产品进行大改，不会产生较多额外成本，充其量是让备用电源的销路更灵活一些。

商业上从来都是看怎么来可以让利益最大化，而不是怎么让性能最好、适合最新的芯片、解决所有人的需求。

@leiuu #33 架构设计上都不是绝对的，而且随着一个项目的发展，系统架构会发生变化，一个组件的定位也可能会改变，叫法也随之改变。

叫啥取决于你们现在觉得它更贴近哪种功能，比如：

应用 BFF 的场景通常是这样的：一套后端服务同时被多个前端产品对接（如 QQ 和 TIM ），如果将多个前端产品的后端 API 都混合在一起，会增加接口的复杂度和管理难度，而且针对一个前端产品的修改会有更大的可能影响其他产品；那么就可以引入 BFF ，后端开发团队负责提供统一且灵活的 API ，由各个前端产品的开发团队负责在这些 API 的基础上针对前端产品对 API 进行组合、转换，同时添加一些仅本前端产品会用到的一些专用 API 。

应用 API 网关的场景通常是这样的：产品由多个后端服务提供功能，但每个服务都需要做相同的处理，如安全、认证与鉴权、监控，或仅仅希望使用统一的域提供这些 API 来简单解决一些浏览器的安全限制，这时候就可以引入 API 网关，主要作用是聚合多个服务的 API ，以及应用统一的中间件。

上一段提到了中间件，恩，这个地方也可能是个中间件，当然中间件这个概念的定义是有些争议或迁移引申的，这个主题里就不进行讨论了。我所遇到的情况通常是有个组件不大关心业务逻辑，提供可以用于任何服务的一些基本能力，比如你的前端是成千上万个智能硬件，每隔一段时间上报状态数据，为了削峰填谷可以在前后端之间放个消息队列中间件（可以是现成的产品也可以是自己实现的），后端匀速消费这些消息来处理业务。

还有一种情况，就是后端本身是可以分层的，比如多个业务的服务都可能调用同一个短信网关服务来给用户发短信，这个短信服务就在其他服务的底层。这种情况下都可以叫后端服务。

当然，也可能会存在一个组件同时具备多项功能的情况，或者多种组件排列的情况，又或者是由于项目本身特殊性而存在的特殊功能和特殊名称的组件。

已 star 表示支持

浏览器的支持情况： https://caniuse.com/?search=WebAssembly
GitHub 上一些项目的情况： https://github.com/search?o=desc&q=webassembly&s=stars&type=Repositories
官方建议的使用场景： https://webassembly.org/docs/use-cases/
Google 把 Google Earth 移植到浏览器上的实践： https://web.dev/earth-webassembly/
Autodesk 把 AutoCAD 移植到浏览器上： https://blogs.autodesk.com/autocad/autocad-web-app-google-io-2018/
一些应用情况： https://www.zhihu.com/question/265700379

不光是浏览器上的，已经有些商业项目开始利用 Webassembly 的兼容性和沙盒机制用在服务端上了，具体可以搜 server-side Webassembly

个人看法是挺成熟且广泛应用了。

没做过这种业务，不过有个脑洞，就是套个类似 CDN 的分布式反向代理，由代理服务运营商来给你优化世界各地的访问线路，可以综合对比一下是不是比自己做优化要便宜一些。

@ttshf #10 我是觉得 3 年后无论怎样横竖都不亏，可能比出来工作性价比高一些。

当然确实也分人和专业，像我这种读研就属于浪费时间（大概率也考不上），毕不了业还不如直接出来工作。

光盘系统通常不会自动挂载光盘系统以外的文件系统，你最好 df 看一下 /mnt/sysimage 究竟是哪个设备，大概率是你光盘系统本身的文件系统。

现在一般都叫 BFF 吧。

不过前后端是个相对概念，在不同范围内可以指不同的东西。比如可以把客户端视为前端，把服务器视为后端；但如果单看客户段范围内的话，负责用户呈现和用户交互的部分可以视作为前端，负责数据处理和与服务器通信的部分可以视作为后端；单看服务器范围内的话，BFF 可以被视作前端，中台等底层服务可以被视作后端。

想要尽可能提高群晖兼容性，最好就是参照群晖官方的硬件参数，比如群晖用的是什么规格的 U ，CPU 厂商相同代系的 U 有哪些。

可以去群晖的官网，查看产品的“规格”，里面有 CPU 的型号，如果是 Intel 的 U 的话可以去 Intel 的 ark 网站上搜一下参数，然后按照相同架构等参数搜一下，越相近，兼容性越好。

群晖到现在都在一些产品上用 J3355 的 U ，就足以说明这玩意不求硬件有多新，性能足够设计用途然后越稳越好，跟 PC 还是有一定区别的。

计算机行业不缺人，但缺人才，好不好就业看你自己是不是人才。

个人建议是经济不大好的时候深造，经济好的时候就业。

目前经济可能不是很好，所以建议读研读博，等完成学业的时候如果经济好了就可以高起点就业，如果经济不好也能有较强的竞争力。

基础方面可以把 MDN 关于 JS 的部分的教程、API 文档详细看一遍，虽然可能大多信息都是自己已经知道的，但很多时候能给你解决问题提供关键思路的信息就藏在一些不起眼的特性细节里。

如果学 JS 是打算重拾 Web 前端开发的话，还要看 CSS 、HTML 标签、DOM API 等文档，这些 MDN 上也有。

基础搞定之后想要用框架，就去看框架官方网站的 Get started/Tutorial/Guide 文档，很多官方文档已经写得很清晰、完备了，而且信息更新及时。

高阶可以了解一下新的架构思想（如微前端）、JS 引擎和渲染引擎的原理、ECMAScript 的 proposal 。

没有背景，没法评论。

但看标题这句话，我觉得没毛病，很多岗位，如技术人员的核心价值就是是否能解决问题，跟会什么语言、框架、库没有直接关系。

@kafkaonsea #28 我也都有，但因为我先有的居住证，所以并没有在这个问题上被难住，甚至公司 HR 给我办的时候都没强调住所问题。印象里只有跑税务局打缴税证明麻烦一些而已。

直接问自如办工作居住证他们肯定不管，而办工作居住证不一定非要房东协助。