Invoke-WebRequest首次执行失败，二次执行正常的技术求助

针对首次调用Get-ProductCN返回302、第二次正常的问题，可按以下步骤逐一排查：

1. 确认会话变量的传递与作用域 #

PowerShell函数默认使用局部作用域，需确保会话对象被正确传递且未被意外覆盖：

• 检查函数参数定义，明确接收WebRequestSession类型的会话对象：

  function Get-ProductCN {
      param(
          [Parameter(Mandatory)]
          [Microsoft.PowerShell.Commands.WebRequestSession]$WebSession
      )
      # 调用请求时必须显式指定-WebSession参数，使用传入的会话对象
      Invoke-WebRequest -Uri $productApiUrl -WebSession $WebSession -Method Get
  }
  

• 避免对会话对象执行克隆操作（如$session.Clone()），克隆可能丢失关键的Cookie或会话状态数据。

2. 验证登录后的会话初始状态 #

登录完成后，立即检查会话对象的Cookie集合，确认是否包含认证必需的凭证（如SessionID、JWT等）：

# 打印登录后会话中的所有Cookie
$session.Cookies.GetCookies($urlLogin) | Format-Table Name, Value, Domain, Path, Expires

对比首次调用函数前、首次调用后、第二次调用后的Cookie变化：如果首次302响应中返回了新的Set-Cookie头，说明服务器需要通过重定向完善会话状态，第二次请求时会话已更新，因此能正常获取数据。

3. 分析首次请求的重定向目标 #

禁用自动重定向，查看302响应的Location头，明确重定向方向：

# 首次调用时捕获302响应
$firstRequest = Invoke-WebRequest -Uri $productApiUrl -WebSession $session -MaximumRedirection 0 -SkipHttpErrorCheck
# 打印重定向地址
$firstRequest.Headers['Location']

• 如果重定向到登录页：说明首次请求未携带有效认证Cookie，需检查Cookie的Domain/Path是否与产品接口匹配；
• 如果重定向到其他中间页：可能需要先请求该页面完成会话初始化，再调用产品接口。

4. 核对请求参数的完整性 #

对比首次与第二次请求的所有参数，排查是否遗漏关键配置：

• 检查请求头：部分网站会校验Referer、User-Agent等头信息，缺失可能触发重定向；
• 确认请求方法：确保函数内的请求Method（如GET/POST）与浏览器抓包的实际请求一致；
• 检查自动重定向设置：如果函数未指定-MaximumRedirection 0，首次302会自动跳转至HTML页面，而第二次请求时会话已更新，直接返回JSON。

5. 排查会话对象的意外修改 #

登录后保存会话快照，在函数内部对比传入的会话对象是否与初始状态一致，防止函数内操作意外修改会话属性：

# 登录后保存初始Cookie快照
$originalCookies = $session.Cookies.GetCookies($urlLogin) | ConvertTo-Json

function Get-ProductCN {
    param($WebSession)
    # 对比当前会话与初始快照
    $currentCookies = $WebSession.Cookies.GetCookies($urlLogin) | ConvertTo-Json
    if ($currentCookies -ne $originalCookies) {
        Write-Host "会话Cookie已被修改"
    }
    # 执行请求逻辑
}

6. 模拟浏览器的手动请求流程 #

用浏览器开发者工具（F12）抓取登录后首次请求产品接口的完整流程：

• 查看是否存在前置请求（如先GET主页获取CSRF Token）；
• 复制浏览器的请求头、Cookie，在PowerShell中模拟相同请求，验证是否能正常返回JSON。
  如果模拟浏览器请求能成功，说明脚本遗漏了某个关键步骤（如前置页面访问、特定头信息）。

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