@cxtrinityy 因为 nodejs 在 windows 下问题很多，体验一言难尽，最不折腾的解决方案就是跑在*nix 里

@fy node 命令前加参数 NODE_OPTIONS=--max-old-space-size=8192 试试

@ruimz 幻 13 续航偏弱的，它的卖点是便携和性能，所以续航散热噪音就不行了，主力人群应该是经常出差的游戏玩家

m1 mba 刚出的时候，就是续航、便携、性能全方位碾压所有旧款

为什么要在 module 里定义依赖关系，因为依赖的是接口而不是实现，只不过一般图省事直接把实现类作为接口传进去了，就像 Spring 里面依赖项直接写了某个类而不是接口一样
可以看下这章 https://docs.nestjs.com/fundamentals/custom-providers ，providers: [CatsService] 只是 providers: [
{
provide: CatsService,
useClass: CatsService,
},
] 的简写，provide 属性是 IoC 容器用于寻找实例的 key ，不一定是一个具体的类，碰到需要多个实现的场景，一般定义个抽象类作为 provide ，useClass 就可以根据情况注入不同的实现类了

本质是要把依赖交给容器管理，让使用方不知道用的是哪个实现，如果直接 import 进来用就绑死了具体的实现了

个人项目我可能会去压榨这几十 KB ，毕竟服务器费用是自己出的
团队项目在已经大量使用 moment 的前提下，换 dayjs 产生的收益你真的算过吗，节省下来的费用能超过你一天的工资吗

react 那几条根本无关痛痒吧
package size 对于绝大部分企业项目来说是最不重要的，moment 相对用的人还是多
css 方案可以并存混用，怎么方便怎么来，只要团队成员都看得懂
导入导出无所谓，都是 IDE 自动补全，团队的话弄个规范就行

我们这也是有新项目 Vue2 的，主要是因为组件库迁不动，而且 Vue2 加上 composition-api 后逻辑复用能力不输 Vue3 的，TS 支持个人体验达到了 Vue3 的 80%了，写 any 是人的问题

不是我看不起宝塔，不过你拿宝塔作为高可用的例子，是不是搞错了什么
上面大佬都说了，除非有 bug 或漏洞，不然框架跟高可用没什么关系，单机环境也不用讨论高可用，机器出故障的概率都比程序崩溃概率高了
性能方面，laravel 妥妥垫底，不过 OP 肯定碰不到语言层面上的性能问题，可以忽略
部署运维方面，使用傻瓜面板当然觉得 php 简单，而对于习惯用容器部署的人来说，nginx+fpm 体验极差

原来 OP 说的可用性，是指对于新手的可操作性，而不是 SLA 的那个可用性？

springboot 默认不也是内嵌 web 服务器吗，你怎么给 springboot 配 nginx 的就怎么给 node 配，nginx 压根就不关心后面是 java 还是 node

pnpm 不服

middlewares = [fn1,fn2,fn3]
compose 展开后是这样
fn = () => fn1(() => fn2(() => fn3(() => {})));

暴力拼接法

function compose(arr) {
const fn = arr.pop();
let composed = () => fn(() => {});
while (arr.length > 0) {
const fn = arr.pop();
composed = ((next) => () => fn(next))(composed)
};
return composed;
}

@murmur 羡慕你能不开浏览器写代码

> 16GB 的内存在 INTEL 时代已经十分够用，我的 2017 年的 INTEL 的 16GMBP ，日常开 word ，powerpoint ，tg ，wechat ，QQ ，浏览器 15P ，Notion ，网易云音乐，onenote

隔行如隔山，你列的这些里面都没有编程软件，在这个程序员为主的社区有何参考价值？

2015 丐版 128g 的用了 5 年，去年换了 256g ，看了下目前使用 130g
纯编程用

才 30 个，全量省事