我也不明白脚本的下面部分是做什么的：
[System.GC]::Collect()
它强制 * 同步 * garbage collection，即。即回收由不再被任何应用程序引用的对象所占用的存储器。

这样做与您的脚本无关**，因为没有明显的理由这样做：没有积累不再被引用的对象，这些对象可能会导致需要缓解的内存压力。

$appContext = New-Object System.Windows.Forms.ApplicationContext
[void][System.Windows.Forms.Application]::Run($appContext)
为了让您的通知区域（系统托盘）图标处理 （WinForms）GUI事件**，此代码是必需的，以便与相关上下文菜单的交互按预期工作。
具体来说，它通过[System.Windows.Forms.Application]::Run()启动一个阻塞的windows消息循环，该循环一直运行到$appContext中存储的应用程序上下文对象（[System.Windows.Forms.ApplicationContext]通过调用.ExitThread()发出退出的信号）。
这类似于在更典型的WinForms场景中对.ShowDialog()的调用，其中 form 将以模式显示;在这种情况下，阻塞调用在表单 * 关闭 * 时结束。
除非显式创建其他线程，否则脚本将在单个线程中运行，包括作为事件委托服务器的脚本块。
您提到最终使用Start-ThreadJob来执行周期性任务，这实际上是*更好的 * 解决方案**，因为它使您能够并行执行长时间运行的任务，而不会干扰UI的响应能力。
实际上，正是原始脚本的单线程特性导致了这个问题：您在$Menu_key.add_Click()事件处理程序中的sleep 5（Start-Sleep -Seconds 5）调用 * 阻塞 * UI事件处理，导致您看到的症状。
有一些方法可以避免这种情况，但是创建一个单独的线程会给你带来更大的灵活性。
也就是说，在您的特定情况下-每N秒运行一个快速操作-使用WinForms计时器对象可能是最简单的解决方案。
以下自包含的示例代码演示了在WinForms应用程序上下文中定期运行操作的三种方法：

• 使用Start-ThreadJob的线程作业在单独的线程中运行操作。
• 使用WinForms定时器对象（System.Windows.Forms.Timer）每N秒自动调用一个脚本块。
• 通过System.Windows.Forms.Application.DoEvents使用嵌套的手动事件处理循环，该循环在必要的短时间间隔内调用处理UI事件，同时在其间执行其他操作。

注意：这在单表单、单通知图标的场景中效果很好，但在其他情况下应该避免。

• 避免 nestedDoEvents()循环的一种方法是完全放弃使用应用程序上下文和[Application]::Run()，而是在主线程中实现单个DoEvents()循环（参见this answer）。

注意事项：

• 这段代码构建在您的代码之上，在几个方面都得到了简化，包括语法方面的简化，以及通过使用System.Windows.Forms.ContextMenuStrip和System.Windows.Forms.ToolStripMenuItem来替换过时的System.Windows.Forms.ContextMenu和System.Windows.Forms.MenuItem类，这两个类都在中不再可用。NET（Core）3.1+。
• PowerShell窗口隐藏代码被注解掉，以保持会话可见，因为周期性操作是通过Write-Verbose模拟到控制台的输出的。
• ApplicationContext.ExitThread()用于退出消息循环，以便有序关闭，这是通过Stop-Process杀死当前进程的更好替代方案
• 详细信息请参见源代码注解。

Add-Type -AssemblyName System.Windows.Forms

Write-Verbose -Verbose 'Setting up a notification (system-tray) with a context menu, using PowerShell''s icon...'

# Create the context menu.
$contextMenuStrip = [System.Windows.Forms.ContextMenuStrip]::new()

# Create the notification (systray) icon and attach the context menu to it.
$notifyIcon = 
  [System.Windows.Forms.NotifyIcon] @{
    Text        = "WinForms notification-area utility"
    # Use PowerShell's icon
    Icon        = [System.Drawing.Icon]::ExtractAssociatedIcon((Get-Process -Id $PID).Path) 
    ContextMenuStrip = $contextMenuStrip
    Visible     = $true
  }

# Add menu items to the context menu.
$contextMenuStrip.Items.AddRange(@(
    ($menuItemExit = [System.Windows.Forms.ToolStripMenuItem] @{ Text = 'Exit' })
    ($menuItemDoPeriodically = [System.Windows.Forms.ToolStripMenuItem] @{ Text = 'Do something periodically' })
  ))

# How frequently to take action.
$periodInSeconds = 2

# Set up a WinForms timer that is invoked periodically - to be started later.
$timer = [System.Windows.Forms.Timer] @{ InterVal = $periodInSeconds * 1000 }
$timer.Add_Tick({
  # Sample action: Print a verbose message to the console.
  # See note re need for the action to run quickly below.
  Write-Verbose -vb Tick
})

# Set up the context menu-item event handlers:

$menuItemExit.add_Click({
    # Dispose of the timer and the thread job and set the script-scope variable to signal that exiting has been requested.
    $timer.Dispose()
    if ($script:threadJob) { $threadJob | Remove-Job -Force }
    $script:done = $true
    # Tell the WinForms application context to exit its message loop.
    # This will cause the [System.Windows.Forms.Application]::Run() call below to return.
    $appContext.ExitThread()
    # Dispose of and thereby implicitly remove the notification icon.
    $notifyIcon.Dispose() 
  })

$menuItemDoPeriodically.add_Click({

    Write-Verbose -Verbose "Starting periodic actions, first invocation in $periodInSeconds seconds..."

    # Best solution, using a thread job.
    # Since it runs in a *separate thread*, there's no concern about blocking the
    # main thread with long-running operations, such as extended sleeps.
    $script:threadJob = Start-ThreadJob {
      while ($true) {
        Start-Sleep $using:periodInSeconds
        # Sample action: print a message to the console.
        # Note: [Console]::WriteLine() writes directly to the display, for demo purposes.
        #       Otherwise, the output from this thread job would have to be collected on
        #       demand with Receive-Job 
        [Console]::WriteLine('Tock')
      }
    }

    # *Single-threaded solutions* that rely on whatever runs periodically
    # to run *quickly enough* so as to not block event processing, which
    # is necessary to keep the notification icon and its context menu responsive.

    # Solution with the previously set up WinForms timer.
    $timer.Start()

    # Alternative: A manual loop, which allows foreground activity while waiting
    # for the next period to elapse.
    # To keep the notification icon and its context menu responsive, 
    # [System.Windows.Forms.Application]::DoEvents() must be called in *short intervals*,
    # i.e. whatever action you perform must run *quickly enough* so as to keep the UI responsive.
    # This effectively makes *this* loop the UI event loop, which works in this simple case,
    # but is generally best avoided.
    # Keep looping until the script-level $done variable is set to $true
    $sw = [System.Diagnostics.Stopwatch]::StartNew()
    while (-not $script:done) {
      if ($sw.Elapsed.TotalSeconds -ge $periodInSeconds) { # Period has elapsed.
        $sw.Reset(); $sw.Start()
        # Sample action: Print a verbose message to the console.
        Write-Verbose -vb Tack
      }
      # Ensure that WinForms GUI events continue to be processed.
      [System.Windows.Forms.Application]::DoEvents()
      # Sleep a little to lower CPU usage, but short enough to keep the
      # context menu responsive.
      Start-Sleep -Milliseconds 100
    }
  })

# Activate this block to hide the current PowerShell window.
# For this demo, the window is kept visible to see event output.
# # Hide this PowerShell window.
# (Add-Type -PassThru -NameSpace NS$PID -Name CHideMe -MemberDefinition '
#     [DllImport("user32.dll")] static extern bool ShowWindow(IntPtr hWnd, int nCmdShow);
#     public static void HideMe() { ShowWindow(System.Diagnostics.Process.GetCurrentProcess().MainWindowHandle, 0 /* SW_HIDE */); }
# ')::HideMe()

# Initialize the script-level variable that signals whether the script should exit.
$done = $false

Write-Verbose -Verbose @'
Starting indefinite event processing for the notification-area icon (look for the PowerShell icon)...
Use its context menu:
 * to start periodic actions
 * to exit - do NOT use Ctrl-C.
'@

# Create an application context for processing WinForms GUI events.
$appContext = New-Object System.Windows.Forms.ApplicationContext

# Synchronously start a WinForms event loop for the application context.
# This call will block until the Exit context-menu item is invoked.
$null = [System.Windows.Forms.Application]::Run($appContext)

# The script will now exit.
# Note: If you run the script from an *interactive* session, the session will live on (see below)
#       In a PowerShell CLI call, the process will terminate.
Write-Verbose -Verbose 'Exiting...'

# # Activate this statement to *unconditionally* terminate the process,
# # even when running interactively.
# $host.SetShouldExit(0)