3、YAML语法详解：YAML基本语法、锚点与别名、多文档支持、在ADAS中的应用
3.1 为什么ADAS工程师要学YAML？
说实话，我刚入行那会儿，配置文件格式五花八门。有的用XML，有的用JSON，还有团队自己搞一套INI格式。直到后来接触到YAML，我才觉得——嗯，这才是人类该读的配置文件。
YAML全称是"YAML Ain't Markup Language"，说白了就是一种数据序列化格式。它比JSON更易读，比XML更简洁。在ADAS系统里，我们用它来定义传感器参数、控制策略、标定阈值等等。你想想看，一个毫米波雷达的配置项可能有上百个，如果用XML写，光标签就占了一半篇幅。YAML就清爽多了。
核心优势：YAML用缩进表示层级关系，用键值对表示数据。没有尖括号，没有花括号，干净利落。
3.2 YAML基本语法
先看一个最简单的例子。我在做AEB（自动紧急制动）功能标定时，经常要定义这样的参数：
# AEB系统参数配置
system_name: "AEB_V1.2"
version: 1.2
enabled: true
sensors:
- type: "毫米波雷达"
position: "前向"
range: 150 # 单位：米
- type: "摄像头"
position: "前向"
resolution: "1920x1080"
thresholds:
ttc_warning: 2.5 # 碰撞时间预警阈值（秒）
ttc_brake: 1.2 # 碰撞时间制动阈值（秒）
deceleration: -6.0 # 最大减速度（m/s²）这里有几个要点，我一个个说：
- 缩进：用空格，别用Tab。我见过有人因为这个吵起来。建议统一用2个空格。
- 冒号：键值对用
key: value，冒号后面要加空格。 - 短横线：列表项用
-开头，后面也要空格。 - 注释：
#开头，这个和Python一样。 - 字符串：大部分情况不用引号。但如果包含特殊字符，比如冒号、#号，就得加引号。
我的习惯：所有字符串都加双引号。虽然YAML允许不加，但加了之后更明确，也避免一些奇怪的解析问题。尤其是ADAS参数里经常有版本号、单位符号，加引号更安全。
3.3 锚点与别名：别重复写同样的配置
这个功能我特别喜欢。在ADAS系统里，经常有多个传感器共用一套参数。比如前向雷达和侧向雷达，大部分配置一样，只有位置不同。用锚点可以避免重复：
# 定义雷达基础配置
radar_base: &radar_defaults
type: "毫米波雷达"
frequency: 77 # GHz
bandwidth: 1 # GHz
power: 10 # dBm
update_rate: 50 # Hz
# 前向雷达
front_radar:
<<: *radar_defaults
position: "前向"
fov: 90 # 视场角（度）
# 侧向雷达
side_radar:
<<: *radar_defaults
position: "左侧"
fov: 60这里&radar_defaults是锚点定义，*radar_defaults是引用。用<<: *radar_defaults表示合并所有键值对。这样写，改基础参数时只改一处就行。
避坑指南：我曾经在项目里用锚点嵌套了三四层，结果自己都搞晕了。建议最多嵌套两层，超过两层就考虑用模板或者脚本生成吧。
3.4 多文档支持：一个文件搞定所有场景
YAML允许在一个文件里放多个文档，用---分隔。这个在ADAS测试场景配置里特别有用：
# 场景1：城市道路
---
scenario: "城市道路"
speed_limit: 60
pedestrian_density: "高"
traffic_light: true
# 场景2：高速公路
---
scenario: "高速公路"
speed_limit: 120
pedestrian_density: "低"
traffic_light: false
# 场景3：停车场
---
scenario: "停车场"
speed_limit: 10
pedestrian_density: "中"
traffic_light: false
parking_mode: true解析的时候，程序会按顺序读取每个文档。我习惯在每个文档开头加一个scenario字段做标识，方便查找。
注意：多文档之间是独立的，不能互相引用锚点。如果你需要跨文档共享配置，建议用!include指令（需要解析器支持），或者干脆拆成多个文件。
3.5 在ADAS中的实际应用
好了，理论说完了，咱们看看实际怎么用。下面是我参与的一个LKA（车道保持辅助）项目的配置文件片段：
# LKA系统配置
lka_config:
version: "2.1.0"
# 车道线检测参数
lane_detection:
camera: "前向摄像头"
min_lane_width: 2.5 # 米
max_lane_width: 4.5 # 米
confidence_threshold: 0.85
detection_range: 50 # 米
# 控制参数
control:
steering_torque_max: 3.0 # Nm
steering_angle_max: 45 # 度
response_time: 0.1 # 秒
# 激活条件
activation:
min_speed: 60 # km/h
max_speed: 130 # km/h
lane_marking_visible: true
driver_hands_on_wheel: true
# 故障处理
fault_handling:
sensor_failure: "降级到LDW"
system_timeout: 5 # 秒
fallback_strategy: "声音警告+振动"你看，一个LKA系统的配置，用YAML写出来，结构清晰，一目了然。每个模块的参数都放在对应的层级下，改起来也方便。
我的经验：在ADAS项目里，配置文件往往比代码更容易出问题。代码有单元测试，配置文件没有。所以我建议：
- 所有配置文件都要做schema校验（用JSON Schema或YAML Schema）。
- 参数值要加注释说明单位和取值范围。
- 版本号一定要写，方便追溯。
- 不要用浮点数做精确比较，用范围判断。
3.6 小结
YAML语法其实不难，难的是怎么用得规范、用得顺手。我个人觉得，在ADAS领域，YAML比JSON和XML都更适合做配置文件。原因很简单——它更接近自然语言，工程师读起来不费劲。
最后说一句：别把YAML写成JSON。我见过有人用YAML写了一大堆花括号和方括号，那还不如直接用JSON呢。YAML的精髓就是简洁，保持缩进整齐，用好锚点，你的配置文件就会像代码一样优雅。
一句话总结：YAML是ADAS工程师的瑞士军刀——小巧、实用、用好了事半功倍。