问题描述
我知道您应该只在索引文件的全局范围内导入所需的模块，以减少冷启动的时间。
但是我还没有发现，如果有云功能或仅导入的模块计数，node_modules文件夹的大小（或package.json文件的依赖属性的长度）是否对冷启动很重要？
解决方法
大小无关紧要！发布代码时，将构建一个容器（带有buildpacks）。此容器已缓存，因此，在函数启动时，不必下载该容器。
在这里，大小不会影响启动时间（因为没有下载）。
HOWEVER ，一个大的node_modules文件夹（更常见的说，在任何一种语言中，都有大量的依赖项）可能意味着很多事情在启动时就初始化了（服务，与数据库的连接，... ）。如果它处于急切模式，则会增加启动时间。
最好延迟组件的初始化，即使是全局的。更喜欢轻框架（或没有框架），而不是大的Berta！
编辑
该功能版本没有缓存策略管理。构建并激活一个版本后，便会缓存图像。建造新建筑时，前一天将被驱逐。您无法管理，它是无服务器的！
要坚持大小无关紧要，我找到了两个有关Cloud Run的链接。是的，Cloud Run！实际上，Cloud Run和Cloud Functions共享相同的后端和相同的行为（您的功能打包在一个容器中（如前所述），并与Cloud Run容器具有相同的逻辑）
因此，这里的official Google documentation和unofficial FAQ由Cloud Run专家（Ahmet，Cloud Run @Google的开发倡导者）维护
最终，大小无关紧要，但是我发现语言很重要！！在this article also wrote by a Googler中，有NodeJS启动行为的说明
模块启动时，node.js使用同步I / O解决从入口点开始的所有require（）调用，如果依赖项数量很大，或者内容本身需要很多链接。
因此，执行（延迟加载？）要比平台问题更多是语言问题和优化。本文提供了许多优化代码的方法！
,在部署云功能时，Google会根据您位于GCS中的代码源创建一个图像。该映像将嵌入源代码运行所需的所有运行时库。每次您需要函数的新实例时，Google都会从该图像启动一个容器。
现在，容器“物理”将启动时间与图像大小直接相关。映像越薄，启动时间越短。是的，这很重要：）
official GCP page中的更多信息。