javascript - 在云功能冷启动期间，node_modules 文件夹的大小是否重要？

我知道您应该只在索引文件的全局范围内导入所需的模块，以减少冷启动的时间。

但是我还没有发现 node_modules 文件夹的大小（或 package.json 文件的 dependencies 属性的长度）是否对云功能的冷启动很重要，或者只计算导入的模块？

标签： javascriptnode.jsgoogle-cloud-platformgoogle-cloud-functionscold-start

大小无所谓！当您发布代码时，会构建一个容器（使用buildpacks）。这个容器是缓存的，所以当函数启动时，容器不必被下载。

在那里，大小不会影响启动时间（因为没有下载）。

然而，一个大的 node_modules 文件夹（更一般地说，在任何语言中，大量的依赖项）可能意味着在启动时初始化了很多东西（服务、与数据库的连接......）。如果它处于急切模式，则会增加启动持续时间。

更喜欢组件的延迟初始化，甚至是全局组件。也更喜欢轻框架（或无框架）而不是大伯塔！

编辑

函数版本没有缓存策略管理。当一个版本被构建并激活时，图像被缓存，仅此而已。当一个新的建成时，前一个将被驱逐，一天。你无法管理它，它是无服务器的！

为了坚持大小无所谓，我找到了 2 个关于 Cloud Run 的链接。是的，云跑！！实际上，Cloud Run 和 Cloud Functions 共享相同的后端和相同的行为（您的函数被打包在一个容器中（如前所述）并使用与 Cloud Run 容器相同的逻辑提供服务）

因此，这里是由 Cloud Run 的一位大师（Ahmet，Cloud Run 上的 Dev Advocate @Google）维护的官方 Google 文档和非官方常见问题解答

最终，大小无关紧要，但我发现语言很重要！在这篇也是谷歌人写的文章中，有对NodeJS启动行为的解释

当一个模块启动时，node.js 使用同步 I/O 解析来自入口点的所有 require() 调用，如果依赖的数量很大，或者内容本身需要大量链接，这可能会花费大量时间.

因此，与其说是平台问题，不如说是语言问题和执行优化（延迟加载？）。文章提供了很多优化代码的方法！