Linho1219

分母+1

GZ28E9XRGNX7LUQG68H5GTY 已用，感谢！

@cmdOptionKana 照此逻辑毒品也应该放开对吗

用的小星记账，几乎刚开始用就充了永久，现在 803 天

堆屎山嫌太慢了，上抽粪车还嫌贵

@n2l 忽略运存和存储占用，还真挺干净的

> 这些要求或多或少可能存在合理之处吧？但是没有设备，没有经费，甚至没有人，就是在某一个风和日丽的下午，领导找到我，然后许下一个千年的约定。

好句🇰🇷了

以及同意上面说的楼主可能对 node ，跨平台这些不太熟悉。cross-env 算比较基本的工具了，问 AI 或者上网搜肯定一下子就出来了，怀疑楼主不仅不熟悉这些，prompt 水平也有限。

还有一点是我遇到兼容性问题的话第一反应是先找有没有替代的包，实在不行去尝试 patch 出问题的包。因为如果只是小问题的话 patch 一下是最方便的，而且如果后续包更新了，patch 也会在第一时间抛出错误要求人工介入，可维护性优良。npm 下使用 patch-package ，pnpm 下自带了。像命令行开关这种依赖 node 版本的，尤其是这种和 legacy 相关的指不定后面就移除了（不是指此例，而是指一般思路）。

针对这个问题我查了一下，实际上这个命令行开关对应 OpenSSL 的 OSSL_PROVIDER-legacy ，文档描述如下：The OpenSSL legacy provider supplies OpenSSL implementations of algorithms that have been deemed legacy. Such algorithms have commonly fallen out of use, have been deemed insecure by the cryptography community, or something similar. 那，本质是楼主的部分代码，或者依赖的代码使用了过时、不安全的密码学算法。如果是自己的代码，应该换用更安全的加密；如果不是自己的代码而是某个依赖，那这个依赖绝对会报 deprecated ，应当更换或者 patch 掉，这才是根本路径，用这个命令行开关不过是掩耳盗铃，把安全性问题埋起来了。如果你说安全性无所谓，如果不是密码学安全问题那用什么 OpenSSL 呢？

还有一个点，楼主疑似有点半桶水了，自己学得并不算特别怎么样却在那里说全世界都是烂的。所有回答都是社区共建共享的，每个回答都有局限性，有些是临时解法，有些是针对特定环境。如果你觉得 StackOverflow 或者其他论坛上的回答不好，你应该在下面回帖，而不是抱怨完拍拍屁股走了。如果楼主觉得这些和自己无关，那可能更适合去贴吧微博小红书发泄情绪，V2EX 都不太适合干这个

写 .npmrc 不一定是好方案，因为会影响整个项目。大多数情况下都是某个命令碰到问题专门做设置。你对整个项目应用设置之后，要是影响到其他命令，排错会把你搞疯掉（因为你改动默认行为了）。此外如果这部分代码改动了没这个问题了，留在 .npmrc 里后续鬼知道这个选项为什么要放着。最佳实践应该还是 cross-env