应使用强类型序列化而非字符串拼接生成CloudFormation模板，解析YAML需先转JSON或用YamlDotNet节点树处理，内置函数须按规范分支解析，跨平台需统一换行符与缩进，并通过validate-template最终校验。
用 C# 生成 CloudFormation JSON/YAML 模板时，别手写字符串拼接
直接拼 "{ \"Resources\": { ... } }" 看似快，实际维护性为零，且极易因转义、缩进、字段遗漏导致部署失败。CloudFormation 对 JSON 结构敏感，一个多余逗号或缺失的 Properties 就会让 CREATE_FAILED 报错卡在 ROLLBACK_IN_PROGRESS。
正确做法是用强类型对象序列化：
- 用
AWS.CloudFormation.Model（来自AWS.SDK.CloudFormation）仅限描述已有栈结构，不适用于模板生成 - 推荐用
Newtonsoft.Json或System.Text.Json配合自定义 POCO 类——但注意：CFN 模板有固定顶层字段（AWSTemplateFormatVersion、Resources、Parameters等），需严格对齐，不能靠自动推导 - 更稳的选择是引入
CloudFormationYamlDotNet（社区库）或自己封装一层TemplateBuilder类，把Resources建模为IDictionary<string resource></string>，避免键名拼错成"Resoruces"
解析 YAML 格式 CloudFormation 模板时，System.Text.Json 默认不支持
System.Text.Json 只能读 JSON；遇到 .yaml 或 .yml 文件会直接抛 JsonException，错误信息像 JSON value is not a valid JSON object，让人误以为模板内容损坏。
必须先转成 JSON 再解析：
- 用
YamlDotNet的YamlStream.Load()加载 YAML 流，再用其Save()输出为 JSON 字符串 - 别用
YamlDotNet.Serialization.Deserializer直接反序列化成Dictionary<string, object>——CFN 的嵌套结构（如Fn::Join、!Ref）会导致类型推断失败，出现InvalidCastException - 如果只关心特定字段（比如所有
EC2::Instance的InstanceType），用YamlDotNet.RepresentationModel解析成节点树更安全，可跳过无法映射的函数表达式
处理 CloudFormation 内置函数（如 !Sub、Fn::GetAtt）时，别当成普通字符串解析
这些不是占位符，是 CloudFormation 引擎运行时求值的指令。C# 层若把 !Sub "${MyParam}" 当作字面量读出来，后续替换参数就失效；更糟的是，若用正则去“提取变量名”，会漏掉 Fn::Sub: [ "Hello ${Name}", { Name: !Ref Param } ] 这种嵌套结构。
关键判断点：
- YAML 中的
!前缀（如!Sub）是 YAML tag，YamlDotNet能识别为YamlNode的Tag属性，值本身是YamlScalarNode或YamlSequenceNode - JSON 中的
Fn::Sub是 key，对应 value 可能是字符串或数组，必须按 CFN 规范分支处理——不能统一当字符串切片 - 若要做参数校验（比如检查所有
!Ref是否指向已声明的Parameters），得先完整解析出Parameters和Resources节点，再遍历所有函数调用，顺序不能颠倒
跨平台生成模板时，注意 Windows/Linux 下路径分隔符和换行符差异
用 File.WriteAllText("template.yaml", yamlContent) 在 Windows 上默认写 \r\n，而某些 CI 工具（如 AWS SAM CLI）在校验 YAML 时对行尾敏感，可能报 could not determine a constructor for the tag。
实操建议：
- 生成 YAML 时统一用
Environment.NewLine替代硬编码"\n"或"\r\n" - 保存前用
YamlDotNet.Serialization.Serializer的ForceIndentation和DefaultIndentation控制缩进，避免手动拼空格导致的格式错乱 - CI 流水线中，用
aws cloudformation validate-template --template-body file://template.yaml做最终校验——本地测试通过不等于部署成功，因为validate-template会模拟服务端解析逻辑
真正难的不是读写文件，而是把 CloudFormation 的语义规则（比如 DependsOn 必须是字符串数组、Metadata 可以是任意结构）映射成 C# 类型系统能守住的边界。稍不注意，类型定义松了，运行时就变成难以定位的部署异常。
