AWS CDK中Construct类的prepare()方法作用是什么？应当如何使用或规避？

核心作用 #

prepare() 是AWS CDK Construct 类的 protected 生命周期钩子，执行时机固定在所有子构造的全量生命周期流程完成后、CloudFormation模板合成前，设计目的就是给开发者留一个入口做最终的全局调整操作，不是用来做常规资源初始化的。

推荐使用场景 #

只有当你需要对当前构造及其所有子构造做批量统一调整时，才适合使用prepare()，典型场景包括：

• 批量给当前构造下的所有子资源附加统一标签、成本分摊标记
• 全局补全校验：比如检查用户传入的配置是否存在冲突，或者用户未传入可选依赖资源时自动补全默认配置
• 统一附加安全规则：比如给当前栈下所有Lambda、ECS任务自动绑定统一的权限边界、日志配置

需要严格规避的用法 #

禁止将资源初始化逻辑放到prepare()中 #

你猜测的把原本写在constructor里的子构造创建、权限配置等逻辑挪到prepare()的用法是完全错误的，主要风险如下：

• 破坏CDK的通用开发规范：所有CDK官方构造、社区公开项目默认都把资源初始化逻辑放在构造函数中，滥用prepare()写初始化逻辑会大幅降低代码可维护性，其他CDK开发者很难定位资源定义位置
• 生命周期断裂：prepare()的执行顺序是父构造晚于所有子构造，如果你在父构造的prepare()中新增子构造，这些新增子构造的生命周期钩子（包括自身的prepare()、参数校验逻辑）都不会被执行，会生成不符合预期的模板甚至直接报错
• 变更不可预测：prepare()在合成前的最后阶段执行，在这里修改核心资源配置会导致cdk diff结果不稳定，很难排查非预期变更的来源

非必要不使用prepare() #

绝大多数业务场景下的构造开发，都不需要用到prepare()，直接在constructor中完成所有资源定义、依赖绑定、参数校验即可。

官方提到的「影响」说明 #

官方文档没有明确说明的风险主要有三点：

1. 打破CDK的声明式特性：动态修改资源的逻辑会导致资源最终形态无法通过构造初始化代码直接预判，排查问题成本极高
2. 兼容性风险：CDK版本迭代过程中生命周期钩子的执行逻辑可能调整，依赖prepare()的代码更容易出现版本升级后的兼容问题
3. 可组合性变差：如果你的高阶构造使用了prepare()做隐式的资源修改，使用该构造的开发者无法直接感知这些修改，很容易出现配置冲突

内容的提问来源于stack exchange，提问作者Parzh