ROS2 launch 文件参数覆盖混乱？从参数文件到命令行优先级

ROS2 项目一长大，launch 文件、参数 yaml、命令行参数三层叠在一起，经常出现“改了参数却没生效”的情况。查半天发现不是代码问题，是参数被另一层覆盖了。我的理顺方法是这样的。
第一，先把优先级说清楚。ROS2 里命令行参数优先级最高，其次是 launch 里显式设置的参数，最后才是参数文件里的默认值。调参之前先按这个顺序排一遍，看看自己改的那一层是不是被更高层压住了。
第二，参数文件要分层。不要把所有参数塞进一个 yaml：基础默认值放一份，机器人型号差异放一份，现场调试放一份，launch 里按顺序加载，后加载的覆盖先加载的，顺序写错就等于改了个寂寞。
第三，用 ros2 param list 和 ros2 param get 现场核对。节点跑起来后直接查实际生效值，别只信 launch 文件里的字面值。很多“没生效”其实是节点名或命名空间对不上，参数被设到了另一个节点上。
第四，命名空间和重映射要小心。多机器人同网时，参数如果没带命名空间，很容易互相覆盖；launch 里 remap 写错一个话题名，参数看起来都对，行为却全错。
第五，调参过程留记录。每次现场改动记下改了哪个文件、哪一层、改前改后的值，回滚时才有据可查。口头改完不记录，下次换人接手又要重查一遍。
大家在 ROS2 里调参时，有没有被参数覆盖坑过？你们是习惯用参数文件统一管理，还是 launch 里显式写死？

优先级「命令行 > launch 显式 > yaml」说清楚就能少踩一半坑。补充：带命名空间/组件化 launch 时，参数常被设到错误的节点全名上，所以应用 ros2 param dump 对实际节点名核对，不要只信文件字面量。多份 yaml 叠加时把加载顺序写进注释并做一次「故意改错值看谁生效」的探针测试。CI 里对关键参数做启动后断言（期望值与 get 一致），能把「改了没生效」挡在合入前。

探针测试的关键是选一个安全且可观测的参数，例如日志级别或发布频率的默认值，故意改成一个极端但无运动风险的值，启动后用实际生效值反推它来自哪一层，这样比逐行读 launch 更直接。组件化场景还要区分容器内节点与独立节点：同一个节点名在不同命名空间下会生成不同的全名，参数文件里写的相对名一旦被命名空间改写，实际落点就变了，所以核对时必须以运行时的完整节点名为准。CI 断言也建议分层做：先在不带命令行覆盖的基线启动下断言默认参数，再单独断言命令行覆盖是否生效，两组结果分开记录，混在一起时一旦失败很难判断是哪一层出了问题。最后把每份参数文件的加载顺序、覆盖关系写进 launch 注释，改动参数时只改一层并重新做一次探针验证。