我之前也碰到过一模一样的问题！CDK这种“不管部署哪个Stack都会执行所有代码”的机制确实坑了不少人，尤其是在CI环境里只想部署单个服务的时候。下面给你几个实用的解决方案：

1. 用环境变量控制Stack的实例化（最推荐） #

核心思路是让CDK入口文件只加载你要部署的那个Stack，这样其他Stack的代码根本不会被执行，自然不会触发它们的Lambda打包逻辑。

修改你的CDK入口文件（比如bin/app.ts）：

import { App } from 'aws-cdk-lib';
import { Stack1 } from '../lib/stack1';
import { Stack2 } from '../lib/stack2';

const app = new App();
// 从环境变量获取要部署的目标Stack
const targetStack = process.env.TARGET_STACK;

if (!targetStack) {
  // 本地开发时默认创建所有Stack
  new Stack1(app, 'Stack1');
  new Stack2(app, 'Stack2');
} else {
  // 只实例化目标Stack
  switch (targetStack) {
    case 'Stack1':
      new Stack1(app, 'Stack1');
      break;
    case 'Stack2':
      new Stack2(app, 'Stack2');
      break;
    default:
      throw new Error(`Unknown target stack: ${targetStack}`);
  }
}

然后在CI里部署的时候，先指定环境变量再执行CDK命令：

# 部署Stack1时
TARGET_STACK=Stack1 cdk deploy Stack1

# 部署Stack2时
TARGET_STACK=Stack2 cdk deploy Stack2

这样一来，CDK只会加载对应Stack的代码，完全不会碰另一个Stack的Lambda打包逻辑，也就不会因为依赖缺失报错了。

2. 手动控制Lambda打包，跳过CDK自动构建 #

如果不想改Stack的实例化逻辑，你可以把每个Lambda的构建流程从CDK里抽出来，手动在CI里只构建需要的Lambda，然后让CDK直接使用预构建好的产物。

比如，给你的NodejsFunction配置加上bundling参数，跳过CDK的自动打包：

const function1 = new NodejsFunction(this, 'lambda-function-1', {
  ...commonProps,
  entry: `${resolve(__dirname)}/../../functions/lambda1/dist/index.js`, // 直接用预构建的产物
  handler: 'main',
  functionName: 'Lambda1Main',
  description: 'Function 1 Main method',
  environment,
  layers: [/* 你的层配置 */],
  // 告诉CDK不要自动打包
  bundling: {
    command: ['echo "Using pre-built bundle"'],
    image: DockerImage.fromRegistry('node:18'), // 随便指定一个镜像，因为命令只是占位
  },
});

然后在CI里，先进入对应Lambda的目录执行依赖安装和构建：

# 部署Stack1前，先构建它的Lambda
cd functions/lambda1
npm install
npm run build
cd ../..
# 再部署Stack1
cdk deploy Stack1

这个方法需要你自己维护每个Lambda的构建脚本，但好处是完全掌控构建流程，适合对打包有特殊需求的场景。

为什么你的existsSync方案行不通？ #

你提到用existsSync('node_modules')来条件创建Lambda，但后面用到function1.functionArn时会报错——这是因为如果条件不成立，function1变量根本没被定义，后面的代码自然会崩溃。要让这种方案生效，你得把整个Stack里依赖该Lambda的逻辑都包裹在条件里，但这样代码会变得非常混乱，不如直接用环境变量控制Stack实例化来得干净。

关于CDK的机制补充 #

你说得没错，CDK确实是先执行所有Stack的构造函数，生成完整的云架构模板后，再决定部署哪些资源。这是因为CDK需要处理跨Stack的依赖（比如importValue），所以它必须先了解整个架构。但这也导致了“部署单个Stack却跑了所有代码”的问题，这算是CDK作为基础设施编排工具的一个特性（或者说局限性）。

备注：内容来源于stack exchange，提问作者ricardosmg