根本原因是调用时机不当——VisualTreeHelper只能遍历已加载并完成渲染的可视化树，若在Window构造函数中调用，控件尚未生成Visual节点，故返回null。
VisualTreeHelper.FindChild 为什么总返回 null
根本原因不是函数写错了，而是调用时机不对——VisualTreeHelper 只能遍历已加载并完成渲染的可视化树。如果在 Window 构造函数里就调用，控件还没生成 Visual 节点，自然找不到。
实操建议：
- 把查找逻辑移到
Loaded事件或OnRender后首次触发的Dispatcher.BeginInvoke中 - 避免用
FindChild(parent, name)依赖Name属性——很多控件（比如ItemsControl生成的项）根本没设Name，改用类型 + 条件筛选更可靠 - 注意：
VisualTreeHelper.GetChildrenCount()返回 0 不代表没子节点，可能是尚未展开（如未展开的TreeViewItem）或被虚拟化（VirtualizingStackPanel下的隐藏项）
LogicalTreeHelper.GetChildren 返回空集合的常见场景
LogicalTreeHelper.GetChildren 遍历的是逻辑树，它反映的是 XAML 结构或代码中显式定义的父子关系，不包含模板生成的内容（比如 ContentTemplate 或 ItemTemplate 中的元素）。所以即使界面上看得见，逻辑树里也可能“不存在”。
典型问题与应对：
- 对
ListBox或ItemsControl直接调用GetChildren，返回的只是它的直接子项（通常是ItemsPresenter），不是列表项本身——得先拿到ItemsPresenter，再通过VisualTreeHelper往下挖 -
ContentControl的Content是字符串或数据对象时，逻辑树里没有 UI 元素——必须等模板应用后，才进入可视化树 - 自定义控件若未重写
GetVisualChild或未正确定义LogicalChildren，LogicalTreeHelper就无法穿透
用 VisualTreeHelper 遍历所有可视化子节点的可靠写法
别依赖递归深度优先硬刚，容易栈溢出或漏掉虚拟化容器里的项。更稳妥的方式是结合 VisualTreeHelper.GetParent 倒查，或用广度优先 + 显式跳过已知不可见/未加载节点。
一个轻量级遍历示例（查找所有 TextBox）：
