ansible变量未定义或渲染失败通常静默跳过或报undefined error，根源在作用域、时序、拼写或事实未收集；排查需用debug显形验证、确认时序、检查hostvars引用、变量优先级、facts启用及jinja2安全过滤。
Ansible 变量未定义或渲染失败，通常不会直接报错退出，而是静默跳过任务、输出空值、或在 Jinja2 模板中抛出 undefined variable 错误。问题根源多在变量作用域、定义时序、拼写错误或事实未收集，排查关键在于“显形 + 验证 + 时序确认”。
用 debug 模块实时查看变量真实状态
别等模板崩溃才查，主动在可疑位置插入调试任务：
- 查是否存在且有值：
- debug: var: my_var—— 若未定义，会明确提示"my_var is undefined" - 查类型和结构（尤其对 facts、register 结果）：
- debug: msg: "type={{ my_var | type_debug }}, value={{ my_var | to_nice_json }}" - 跨 play 或跨主机引用时，必须显式使用
hostvars['target_host']['var_name']，不能直接写target_host.var_name
确认变量是否被正确收集和覆盖
同一变量名可能来自 inventory、group_vars、play vars、set_fact 等多个来源，优先级不同会导致覆盖：
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 运行
ansible-inventory -i inventory/ --graph查看变量继承关系 - 加
-vv执行 playbook，观察日志中是否有"overridden by play vars"或"set by group_vars"类提示 - 对
set_fact定义的变量，必须在其后立即跟debug验证；不能在同个任务的vars:块里引用刚定义的变量（它尚未写入上下文）
检查事实（Facts）是否启用及可用性
很多 ansible_facts.* 变量（如 ansible_distribution_file_variety）并非默认总有，依赖 gather_facts: yes 和目标系统支持：
- 确保 play 中未设置
gather_facts: no；若关闭了，就无法使用任何ansible_facts相关变量 - 某些 facts 在特定系统或 Ansible 版本中才存在，可先用
- debug: var: ansible_facts全量输出，搜索确认字段是否存在 - 对不确定是否存在的 facts，统一加默认值：
{{ ansible_facts.get('distribution_file_variety', 'unknown') }}或{{ ansible_facts.distribution_file_variety | default('centos') }}
规避 Jinja2 渲染阶段的常见陷阱
模板文件（template 模块）或 msg 字段中的变量，会在渲染时才求值，错误常出现在这里：
-
failed_when或when:中引用未定义变量，整个任务会被跳过且无提示 —— 先用debug确认该变量已存在 - 过滤器如
| int、| upper遇到null或空字符串会报错，务必前置| default('')或| default(0) - 模板中避免裸写
{{ some_var.key }}，改用{{ some_var.get('key', '') }}防止 key 不存在时报错
