Add-Content报‘stream not readable’错误，改用AppendAllText可行，求问题根源

问题背景 #

我有一个使用Add-Content记录进度的脚本，日志文件写入到网络共享目录，在部分网络环境下出现stream not readable错误。该错误虽不常见，但发生频率足以需要解决。

最初我参考相关方案实现了循环重试逻辑：

$isWritten = $false

do {
    try {
        Add-Content -Path $csv_file -Value $newline -ErrorAction Stop
        $isWritten = $true
    }
    catch {
    }
} until ( $isWritten )

之后我在重试间隔添加了1秒等待，并限制最多重试20次，后来又提升至60次，但在特定网络环境下依然无法成功写入。

改用[System.IO.File]::AppendAllText($file, $line)后，问题得到解决——20多次测试均未失败，而之前每10次尝试会有1-2次失败。不过该方法存在格式问题，可能需要设置编码。

我想了解：

• Add-Content出现该问题的根本原因是什么？
• 为何[System.IO.File]::AppendAllText()没有这个问题？
• 这是该地点网络/机器的潜在问题，还是PowerShell 5.1（Windows 10 21H2）的bug需要规避？
  另外，日志最多几百行，但错误常出现在前10行。

原因分析与解答 #

1. Add-Content出现stream not readable的根本原因 #

PowerShell 5.1中的Add-Content cmdlet在处理网络共享文件时，内部实现存在两个核心问题：

• 文件流复用导致状态异常：Add-Content会尝试复用已打开的文件流，在不稳定的网络环境下，共享文件的连接可能出现短暂中断，导致流的状态变为不可读/不可写，但cmdlet未正确处理这种临时异常，直接抛出错误。
• 缺乏网络友好的重试逻辑：该cmdlet内部没有针对网络抖动的自动重试机制，默认的文件操作超时设置对共享存储不友好，一旦出现网络波动就会触发错误。

错误集中在前10行，是因为脚本启动初期频繁调用Add-Content，短时间内多次建立/复用文件流，此时网络连接还未进入稳定状态，更容易出现中断。

2. 为何[System.IO.File]::AppendAllText()能解决问题 #

.NET的AppendAllText方法与Add-Content的实现逻辑有本质差异：

• 独立处理每次写入：该方法每次调用都会重新打开文件流，写入完成后立即关闭，不会复用之前的流。即使某次网络中断，下一次调用会重新建立连接，避免了流状态异常的问题。
• 更健壮的错误处理：.NET底层针对网络文件系统的操作有更完善的超时重试逻辑，能自动处理短暂的网络抖动，而PowerShell cmdlet的错误处理粒度较粗，无法捕捉并恢复这类临时故障。

关于编码问题，AppendAllText默认使用UTF-8编码（无BOM），而Add-Content在PowerShell 5.1中默认使用系统ANSI编码（取决于区域设置）。可以通过指定编码参数统一格式：

# 匹配Add-Content的默认编码（例如简体中文系统的GB2312）
[System.IO.File]::AppendAllText($file, $line, [System.Text.Encoding]::GetEncoding("GB2312"))
# 或使用UTF-8带BOM
[System.IO.File]::AppendAllText($file, $line, [System.Text.Encoding]::UTF8)

3. 是否是网络/机器问题或PowerShell bug #

这两者都有可能，但更偏向于PowerShell 5.1的设计缺陷：

• 如果是网络或机器的严重故障，AppendAllText也会频繁失败，但实际测试中它能稳定工作，说明只是Add-Content的实现不适应不稳定的网络环境。
• 该问题属于PowerShell 5.1的已知兼容性问题，在PowerShell 7+中已对Add-Content的文件流处理逻辑进行了优化，类似问题出现频率大幅降低。

如果必须使用PowerShell 5.1，建议长期使用[System.IO.File]::AppendAllText()替代Add-Content写入网络共享文件，同时根据需求设置正确的编码。

内容的提问来源于Stack Exchange，提问作者Gordon