多线程向主UI文本框追加文本时InvokeRequired恒为False的问题

你遇到的InvokeRequired恒为False、采集的聊天内容不更新的问题，是WinForm跨线程更新场景下非常典型的踩坑，常见触发原因有三个：

• 最常见诱因：目标TextBox尚未创建有效原生窗口句柄。Control.InvokeRequired的判断逻辑完全依赖控件已经绑定到主UI线程创建的系统窗口句柄，如果跨线程调用更新时，目标窗体还没完成Load流程、控件没初始化出真实句柄，方法会直接返回False，跳过所有Invoke逻辑，直接执行属性赋值——但此时控件根本没处于可渲染的状态，修改的属性根本不会反映到实际显示的界面上，属于静默失败。
• 第二高频诱因：Form5实例引用错位。你代码里直接用类名Form5访问TextBox2，如果程序实际显示在屏幕上的Form5是通过Dim f As New Form5(): f.Show()手动实例化的，那你通过类名访问的是VB.NET自带的全局默认窗体实例，这个实例和你实际看到的窗口根本不是同一个对象，哪怕属性改成功了，也是改了个没被加载的闲置实例的控件，自然看不到变化。更关键的是，这个默认实例是在工作线程首次访问时才被触发创建的，它的控件创建线程根本不是主UI线程，InvokeRequired自然会一直返回False。
• 小概率匹配项：工作线程根本没独立运行。如果启动线程的代码写错，实际在UI线程上同步执行了FetchChats()逻辑，那InvokeRequired肯定返回False，但这种场景和你描述的新起独立采集线程的场景不匹配。

按下面的顺序调整，基本都能解决问题：

• 修正窗体引用逻辑，绝对不要在工作线程里直接用类名抓全局默认实例的控件。在主窗体完成初始化、实际显示后，把当前存活的Form5实例引用作为参数传入采集线程，从根源上避免引用错位。
• 补全跨线程更新的判断逻辑，不要只靠InvokeRequired做分支判断，规避“句柄未创建时InvokeRequired返回False”的坑，修改后的通用方法如下：

  Private Sub SetTextBoxWithInvoke(ByVal TB As TextBox, ByVal msg As String)
      ' 先过滤已经被销毁的控件，避免跨线程操作引发对象释放异常
      If TB.IsDisposed Then Return
      ' 控件还没创建有效句柄时，不直接执行属性赋值，等初始化完成后再触发更新
      If Not TB.IsHandleCreated Then
          AddHandler TB.HandleCreated, Sub() 
              TB.Invoke(New AddToMessageBoxDelegate(AddressOf SetTextBoxWithInvoke), New Object() {TB, msg})
          End Sub
          Return
      End If
      If TB.InvokeRequired Then
          TB.Invoke(New AddToMessageBoxDelegate(AddressOf SetTextBoxWithInvoke), New Object() {TB, msg})
      Else
          ' 用AppendText替代Text &=，长文本下性能损耗会低非常多
          TB.AppendText(msg)
      End If
  End Sub
  

• 调整工作线程的启动时机。不要在Form的构造函数里启动采集线程，把ChatQuery.Start()的逻辑放到Form5的Shown事件里执行——等窗口完全展示、所有控件的原生句柄都创建完成后，再启动后台采集逻辑，避免触发句柄未创建的判断逻辑bug。

内容的提问来源于stack exchange，提问作者Stavros