如果使用 Terraform 或 OpenTofu 维护云基础设施（例如使用 Terraform AWS Provider），重新应用配置如何影响未明确指定的资源属性？
在编程语言设计和使用风格中，默认值似乎略有争议（与对显式性的偏好相冲突），但是对于设计模块以具有合理的默认值然后采用编码风格存在争议（偏好约定）在大多数地方，未指定配置（隐式采用任何“合理”默认值）。
我的问题的第一部分是如何将其延续到 HCL，即未指定字段是否完全等同于显式指定与当前默认值相同的值，或者未能显式设置是否会损害 Terraform 的能力检测并修复带外定制（即点击操作更改）？我的问题的第二部分是，这如何与 Terraform AWS Provider 和/或 AWS 服务 API 等默认行为的更新进行交互？
云服务提供商通常会提供 API Web 服务，用于申请、描述、操作和放弃资源 (CRUD)。云提供商定期宣布对其默认设置的更改（例如，AWS 最近宣布更改创建存储桶时应用的默认安全策略）。相应的 Terraform Provider 插件最终可能会也可能不会更新（例如，AWS Terraform Provider 的更改说明包括几个更改的默认值，最有动力与上游云服务 API 保持一致）。在什么时候重新应用相同的配置会导致云资源被修改以符合新的默认设置（或者在什么情况下重新应用确保或不产生与拆除并重新部署相同的结果）？
Terraform 如何处理显式配置中省略的属性？
Terraform 协议/API 为提供商提供了丰富的机制来处理此类情况。
在最简单的情况下，可选的架构属性可以有一个默认值，尽管如果提供程序版本升级，结果解释值可能会发生变化。该模式还可以指定任意函数来确定属性应默认的值，甚至可以在每次运行计划时发生变化。或者，可选属性也可以被视为“计算的”属性。如果从配置中省略，这些计算值通常会保留其当前状态（而不是重置为特定值）。该值被有效地标记为“应用后已知”，通常用于云提供商将生成自己的默认值的情况。但提供商也有更多机会修改计划中未指定的值，因此这实际上取决于提供商附加组件的实现方式。
https://developer.hashicorp.com/terraform/plugin/sdkv2/schemas/schema-behaviors
https://developer.hashicorp.com/terraform/plugin/framework/resources/plan-modification
涉及的API更新如何与隐式值交互？
无论计划最终结果如何，应用通常涉及对云服务提供商的专有 API 调用。这些 API 调用可能具有默认值，这些默认值可能会独立于 terraform-provider 升级周期而更改。根据 TF 提供程序的实现方式，云 API 调用可能是完全显式的，也可能会留下隐式的任何属性，其中预期值与假定的云 API 默认值相匹配（正如 TF 提供程序版本发布时所预期的那样）。隐式可能会导致实际结果与显式配置不同的错误，特别是在不保持库最新的情况下。如果 TF 提供商在其云 API 调用中明确，那么云提供商宣传的任何默认值都不太可能有机会展示，并被 terraform 覆盖。