PowerShell中Foreach循环内Log-Write未触发执行问题排查

第一步：确认循环体末尾的Log-Write是否真的被执行到 #

在Log-Write调用行的最前面加一行无依赖的标记输出：

Write-Host ">>> 已走到循环末尾Log-Write位置，当前时间$time"

运行脚本观察：

• 如果控制台没有打出这行标记，说明根本没执行到Log-Write：问题出在循环前置的三个函数New-bhReportToGroup、Get-bhDReports、Set-bhRTGmembers上。这类问题的典型特征是：函数内部的Log-Write调用可以正常写日志，但函数执行完内部日志步骤后，触发了静默的终止性错误，直接中断了当前循环的执行流，根本轮不到跑循环末尾的Log-Write。常见诱因包括：
  • 函数内部临时将$ErrorActionPreference设置为Stop，碰到非终止错误直接终止当前作用域
  • 函数内部执行的AD操作、文件操作碰到权限不足、对象不存在的问题，未做错误捕获直接抛终止错误跳出代码流
  • 函数内部残留了break、return这类会跳出当前循环块的语句，导致后续代码不执行
• 如果控制台打出了这行标记，说明Log-Write确实被执行了，问题出在Log-Write本身的写入逻辑上，继续往下查。

第二步：排查Log-Write执行时的参数和环境问题 #

既然代码走到了Log-Write，但日志没写进去，结合你提到的“开$Global:DebugPreference = Continue时控制台能看到对应Debug输出、但日志文件无内容”的现象，重点查这几个点：

• 参数值是否有效：在Log-Write调用前加一行打印实际传入值的语句：

  Write-Host "当前循环作用域的日志路径值：[$sLogFile]"
  

  对比函数内部成功写日志时用的$sLogFile值，排除变量作用域冲突导致的路径为空、路径指向无效位置的问题——这类问题会导致Add-Content静默报错，不会中断后续的Write-Debug执行，刚好匹配你现在看到的现象。
• 全局偏好设置干扰：Log-Write本身带了[CmdletBinding(SupportsShouldProcess)]，如果全局作用域设置了$WhatIfPreference = $true，Add-Content会直接走模拟执行分支，不会实际写入文件。可以临时把Log-Write调用改成显式关闭WhatIf：

  Log-Write -LogPath $sLogFile -LineValue "========================[ $time ]===============================" -WhatIf:$false
  

  测试是否能正常写入。
• 文件句柄占用冲突：如果前置的Set-bhRTGmembers函数内部持有了日志文件的打开句柄没释放，会导致Add-Content因为文件被占用抛错，且因为没有设置错误停止，错误被静默吞掉，继续执行后面的Write-Debug步骤。这时候可以给Log-Write加临时的错误捕获，定位真实报错：
  把Log-Write的Process块临时修改为带错误捕获的版本：

  Process{
      try {
          Add-Content -Path $LogPath -Value $LineValue -ErrorAction Stop
      }
      catch {
          Write-Host "日志写入失败，错误详情：$_，传入路径：$LogPath"
      }
      Write-Debug $LineValue
  }
  

  重新运行脚本即可看到具体的失败原因，不需要靠猜测排查。

核心逻辑提醒：你看到Debug控制台有对应行的输出，不代表Add-Content执行成功了——因为Write-Debug是跟在Add-Content后面的语句，只要Add-Content抛的是不中断流程的非终止错误，PowerShell就会继续往下跑Write-Debug，给你一种“命令正常执行、只是日志没写”的错觉，实际是Add-Content早就静默失败了。

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