桌面只是个 Shell，现在大多发行版都是兼容多种桌面环境的，取决你装什么以及如何配置，当然也有官方调配好桌面环境的发行版，比自己折腾要省事。

迫于穷，没有高 DPI 4K 显示器，所以没法给建议，可能商业支持的发行版会稳一些？比如 Ubuntu 、Fedora 、Pop!_OS 、Deepin 。

Linux 发行版适合喜欢折腾的人用，这东西你是越折腾越好用，想要开箱即用的体验的话还是乖乖用 Windows 或 MacOS 吧。

如果只是开发应用程序的话，WSL 基本多能满足。

我觉得这个就是编译原理的知识范畴，我自己也没有完整学过编译原理，但是之前学 Rust 的时候为了理解 stack 和 heap 的作用专门去挑了编译原理对应的章节去学习，你可以看 B 站的这个公开课，只看 9.2 章节应该就能解决你的疑惑了 https://www.bilibili.com/video/BV11t411V74n?p=41

简单来讲就是编译完成后，机器码中可能就已经用 0x002 这个地址来替代 a 这个标识符了。
然后每个作用域都有个基地址，0x002 是在这个基地址基础上的相对地址，这样你不同作用域下的 a 实际上就在不同的地址上。
再然后值可能存在 stack 上，也可能存在 heap 上，这个取决于你目前用的编译器的设计，一种简单的设计是：stack 中 0x002 这个相对地址上存储的值是 heap 上的相对起始地址、长度，然后在 heap 的这个区域里存储 0x002 的值，可以很方便地修改；当然如果这是个常量，那么 stack 上 0x002 这个相对地址可能就直接存的值。

一个 branch 尽可能包含一个细粒度的 feature 或 fix，可以随时 commit 和 push，合并的时候可以用 rebase 把 branch 的所有 commit 合并为一个 commit 来合并到其他分支上。

@mxT52CRuqR6o5 #118 是，TS 和 JS+doc 都能自动改。

不了解具体什么需求，以前做类似的功能是在业务里判断，网关负责确定请求的人是谁，然后业务里用网关认证的身份信息来判断是否有权限。

如果业务里涉及鉴权规则的地方也比较多，可以在业务层塞入一个鉴权层，可以把权限简单划分为公开、已登录用户、自己等类别，然后业务返回这个属于哪种鉴权类别，鉴权层再直接套用通用逻辑鉴权。

@xd199153 #114 TS 重构的时候也是一样要改两个地方，一处类型声明、另一处代码声明，只不过这两个地方和 JS 的两个地方位置不一样而已。
工具都是有好用和不好用之分的，VSCode 的代码分析和提示功能跟一些商业 IDE 比起来还是很弱，在 WebStorm 里，JS 即便不写 doc 做类型声明也会通过代码分析来推断类型，然后给画波浪线，提交的时候还会提示代码可能存在问题建议去修改（也可以忽略），花的钱其实也值在这里。
无非是 TS 工具默认不忽略问题（你也可以 @ts-nocheck 忽略问题）；这个对于 JS 工具来说也可以配置不忽略潜在问题，让 CI 直接失败。在这个问题上，不得不说 TS 技术栈给出的是一站式方案，包装成了现成的产品，开箱即用，而 JS 技术栈则依然十分灵活，按配置来实现需求。

对象参数用 doc 来定义的话有多种方式，一种思路是直接在 saveUser 声明参数的时候写个对象结构声明：
/**
* Save a user.
* @param {{nickname: string, age :number}} userObject
* @returns
*/
function saveUser(userObject) {
return true;
}

另一种思路可以先声明对象类型，然后在 saveUser 声明参数的时候直接引用这个类型，同样这种方式可以给每个属性写描述：
/**
* @typedef {Object} User
* @property {string} nickname
* @property {number} age
*/

/**
* Save a user.
* @param {User} userObject
* @returns
*/
function saveUser(userObject) {
return true;
}
// 效果如此： https://imgtu.com/i/Wb9wY4


JSDoc 和 ESDoc 是两种 doc 标准，前者主要针对原型写法，后者主要针对 class 写法（这么说也比较笼统），不过很多工具都是会同时集成两者，都可以直接用，也确实有很多人不知道有这个东西，在 TS 出现之前 JSDoc 是解决文档和辅助语法检查问题的主要方式之一。

@kingwl #111 你的意思是说，在 TS 出现之前没有任何工具可以做到这个事情吗？ VSCode 使用的方案同时是其他所有编辑器和 IDE 使用的方案吗？讨论的问题是 JSDoc 、ESDoc 能否帮助达到 TS 一样的效果，这几张图不足以说明吗？


@xd199153 #110 仔细看我的图，用 doc 的方式除了能满足类型提示和检查以外还能加更多描述，很多时候团队协作为了写描述横竖都要写 doc，顺手写类型声明和 TS 的成本是一样的，也就只是写的位置不一样。

我前面的回复已经说明了，代码提示和类型检查都是工具带来的，TS 离了工具也没法出提示（用纯净的 Vim 试试看），面向 JS 的相关工具也都有，精确不精确取决于工具水平怎么样，WebStorm 上的高水平工具不写 JSDoc 靠推论也能做精准的类型提示。

工具链+语言，至少工具链方面 TS 并没有比 JS 多少优势，语言方面看你要约束还是要灵活，对于要灵活的情况来说，TS 的约束就是缺点。

技术栈选型从来都不是选一个最好的，而是选一个最合适的，任何技术都有优点和缺点，没有完美的。

@xd199153 #75 你这个例子不需要写 JSDoc，编辑器、IDE 能自己判断出有哪些属性或方法。https://imgtu.com/i/WH1KZF
任何编辑器、IDE 在没有 TS 插件的时候也都做不到 TS 的提示功能，相应的 JSDoc 带来的提示功能也是由插件实现的，和 TS 一样，很多编辑器和 IDE 自带了 JSDoc 的插件，甚至在 TS 出现之前就已经存在了。

其实更多区别还是在于类型声明上，这两张图就是个简单的对比，图一是 ESDoc 实现的，图二是 TS 实现的：
https://imgtu.com/i/WH3Ulq
https://imgtu.com/i/WH3Npn
你猜怎么着，ESDoc 还能给参数加描述。

建议看一下 JSDoc 和 ESDoc 的文档，在自己的编辑器或 IDE 上试试，花不了几分钟。

我觉得 TS 也就那样，没必要神化，项目适合就用，不适合就不用，TS 再怎么🐂🍺也不敢脱离 ES 的基本范畴，因为它就指着 ES 生态来维持用户群；除非某一天浏览器集体支持 TS 原生引擎，但只要 TS 还是微软主导的，就基本没可能。

以前 TS 火起来是因为比 JS 早先实现了 ES6 的语法，JS 是等 ES6 正式发布了之后才开始逐渐支持的。

但现在 JS 已经追上 ECMA-262 的所有 proposal 了，所以私以为 TS 的优势没那么大。

唯一比较有优势的是类型声明，然后做编译检查，但这些都是靠工具来完成的，同样靠工具也可以写 JSDoc 、ESDoc 然后用基于 doc 的代码分析工具来检查，效果差不多，我用 JetBrains 家的 IDE，在写的时候自动补全、类型提示、波浪线都很好用，体验就跟 TS 一样。

或许从 C#转技术栈过来的会用着很舒服？都是微软家的东西，思路也会有所相似。

任何一个技术都有好处也有坏处，有其最适合的场景，也有其不适合的场景，所以什么话都不能说死，因为除了会引战以外，过了一段时间回来看自己写的东西会很尬。

JS 是极其灵活的语言，灵活的代价就是对开发者要求很高，没有语法约束来规避各种坑，在水平不足的时候就很容易摔倒，TS 的存在恰好是为了让 JS 没那么灵活，对于 JS 水平较高的人来说，TS 可能会影响发挥。

但你猜怎么着，前端从来都不缺水平低下的人，对于团队协作来说，猪队友是十分致命的存在，那么 TS 的价值就出来了，能提升代码质量的同时提升开发效率。相应的 Go 火起来也是因为这个。

所以做个人项目的话，我通常不会选择 TS，但团队合作最好是 TS 。

终于有人讨论这个问题了。

原教旨主义上来说，有这么三个概念比较容易被混淆：Hacker 、Cracker 、Script kiddie 。

Hack 其实可以理解为钻研，特别是挑战一些无人能及的领域并有所成就，比如攻克了某技术难题。而且 Hacker 往往是有积极意义的，Hacker 的成果往往是为技术的发展做出贡献的。在计算机领域，Hacker 是对一个技术人员的最高评价。

Crack 是破解，Cracker 就是破解者，指的是任何突破限制或封锁的人，顶级的 Cracker 往往在技术上也是有一些无人能及的成就，所以这些人既是 Cracker 又是 Hacker，更多的 Cracker 其实是做着没那么关键的、重复性的事情。Cracker 有黑帽和白帽之分，分别对应消极意义和积极意义。

Script kiddie 就是拿着 Hacker 和 Cracker 的成果不做任何创新就直接用的人，特别是搞破坏，比如各种拿着现成破解工具来进行破解的人。

网络安全攻防相关的其实是和 Cracker 直接相关，跟 Hacker 关系不大。

Hack 是一种精神，Crack 是一种目的，Script kiddie 啥也不是。

早先其实有人建议 Hacker 翻译成黑客，Cracker 翻译成骇客，Script kiddie 翻译成脚本小子，但媒体常常搞混，以至于大众以为三者都是 Hacker/黑客。

除了计算机领域，Hacker 也可以用在其他领域，比如网上比较多的 Life Hacker 相关的内容，不得不说有一些还是很巧妙的。

当然比较有名的还有 Geek，和 Hacker 相比，个人认为 Geek 更多是体现一个人有着极强的学习和动手能力，并且能让自己的生活与众不同。当然，Geek 和 Hacker 的交叉地带也是存在的。

Hacker 在国外也是万中无一的，国内的 Hacker 也是存在的，在各个领域的科研先锋，比如山师的王小云，研究出了 MD5 碰撞算法。

JS 的问题其实不是奇葩，而是一方面自己不理解 JS 的一些基本原理，另一方面是 JS 是极其灵活的一门语言，特别是语法和类型上，语言不负责对开发人员的代码质量进行约束，对开发人员的水平要求很高。这个是类似于 C/C++的，不能说看不懂调不通就是语言本身的问题，比如也有人说 Java 的注解是奇葩语法，C/C++/Rust 的宏是奇葩语法，C#的委托是奇葩语法，Go 的异常处理是奇葩语法，但这些其实都是先入为主的问题。

后端知识比较成体系以及环环相扣，而前端知识非常分散，而且例外情况很多，这其实是与各技术栈受环境因素的影响程度来决定的，比如后端程序会跑在统一可控的环境中，前端程序会跑在不统一、不可控的环境中，所以造成了这种差异。

所以要学习前端技术，难以有速成方法，需要见多识广。

简单给几条学习建议 ，MDN 上关于 Web 基本原理、JS 、CSS 、HTML 、BOM 、DOM 的文档都看一遍，然后就是去看 vue 、react 、angular 等框架极其相关思想的文档。

@vindurriel #25 技术债也不是一定就要避免，或一定就要还清，这个还是得综合业务经营情况来看，有一些对于业务确实比较关键的节点甚至应该主动欠一些技术债务，来换取业务业务的保障，关键就是产品和技术双方达成一致。权责分离之后，出了问题该是哪边的责任就是哪边的责任，比如技术方已经通过正式的文档或邮件将成本和风险表达清楚了，产品经理在 ROI 低的时候一意孤行进行实施，那么最终的业务亏损要算在产品经理的头上。至于如何说服他人，这是一门学问，需要经验和技巧的。

这个可以通过职责拆分来直接解决。
将核心生产工作大体上拆分为技术和产品两部分：
产品部分负责做需求收集、业务评估、产品设计、产品验收；
技术部分负责做需求评审、技术设计、开发实施、质量保证。

其中两部分协作的关键环节是需求评审，产品经理提出方案，由技术评估可行性和成本（对于水平不高的产品经理，技术还要承担起合理性评估的工作），然后产品经理根据自评估的业务收益和技术评估的成本来评估 ROI，以及是否能达成 ORK/KPI 。产品经理为收益评估结果负责，技术人员为成本评估结果负责。

实施成本的评估是纯技术侧的工作，产品经理不专业也不该做这个事，而且需求评审阶段本来就是需要产品放和技术方互相沟通，在实施成本和收益上达成共识。
那么技术经理在给出成本评估的时候不能只包括短期成本，应该是涵盖短期、长期以及各方面的综合性的成本，技术债务也应该包含其中，这个其实也很好说得通，有了技术债务以后可能每个类似功能都要有更多的成本，而且系统的性能下降（运营成本上升）、可靠性下降，而解决或规避了技术债务之后每个类似功能会有更低的成本。

白群肯定爽，钱能解决的肯定就懒得折腾了。

所以我现在用 OMV……

企业的核心工作是赚钱，所以看 ROI，你要投入多少成本，预期能带来多少收益或节省多少成本。

低代码在适合的场景下投入的是工具本身的建设和维护成本，带来的是业务功能的开发和维护成本的显著下降；例如原本每个业务活动都需要技术团队设计、开发、测试、上线，而引入低代码之后可以由业务人员自己快速生产业务功能出来，那么技术团队就可以裁员到较小的规模，主要开发和维护低代码工具，这个整体上是降低了企业的运营成本的。

如果 ROI 低的话就是个赔钱项目，这个得根据你们的具体业务来评估，看是否符合低代码的特性。

任何技术都有一个 Hype Cycle，你可以看看低代码在什么阶段，可以去看看 ThoughtWorks 的技术雷达和 Gartner 评估报告。

我个人感觉低代码和无代码平台应该是处于开始炒作的阶段，企业如果有余力的话可以尝试，如果财政不允许的话可以等到冷静期再看。

如果一个域名就只有一个单页面应用，那么可以用 hash 或者拦截 path 变化来实现路由。如果希望一个域名用不同 path 来 host 多个单页面应用，可以用只用 hash 。

混合使用理论上也可以实现，但是得看具体什么需求，多数情况下为了方便管理和维护，还是建议使用一套方案。

红斑性狼疮是自身免疫疾病？
开过敏药其实已经很近了，只不过没深挖，有经验的皮肤科医生会建议再去看一下变态反应科，这个是专门针对过敏反应的科室，反正皮肤问题由过敏导致的也不少。

不过确实，医生和教师一样，都是分配很不公平的资源，这个是专业教育和市场决定的。

目前在用 Bitwarden，使用开源的 vaultwarden （原来叫 Bitwarden_rs ）来做自建服务器，用 Bitwarden 的官方 App 和浏览器插件，目前已经用了一年，感觉良好。

用过很多年的 LastPass，曾经是不错的产品，但后来不行了，各种 Bug，而且还彻底撤出了中国市场，连通性和汉化都不行，不推荐。

KeePass 好评不少，希望把控安全性的话可以自己拿源码编译，没用过，不评价。

1Password 用的人也不少，是 LastPass 的替代品，我也没用过，不评价。